SSH uses a public/private key pair. The public key is configured on the SSH/SFTP server for the account assigned to you. The private key, which you use here, confirms who you are as a client to the SFTP server.
This not a “webMethods server private key.” This is your “SFTP client account private key”, which you can use as you see fit with any software. wM IS needs access to this private key because it is authenticating to the SFTP server.
The screen shot you shared is for webMethods Integration Server to perform activity as an SFTP client to a remote SFTP server. You enter the location of your private key here. [Edit] This location is on your wM IS file system. Not on the SFTP server. [/Edit] Never share this with any client. And a client will never share their private key with you. You do not need it.
YOU are the client in this screen, not the SFTP server you’re connecting to. This configuration screen is for you, as a client, to connect to someone’s SFTP server.
On that SFTP server, they will place your public SSH key on it, associated with your account. The SSH handshake performed when you connect to their server will use the public and private key to confirm to the SFTP server that you are who you say you are.
Screen shot is correct. Is there still a question/concern?
Perhaps this diagram helps.
The Key Authentication section at What is SSH? describes the interaction in the diagram. In this diagram wM IS is the SSH client. Step 1 indicates that the public key is given to the SSH server in some way and stored there. This is typically manually done by the SSH server owner – you email them the public key and they put where the SSH server needs it.
Then when you run a wM IS service that uses that SFTP alias it will connect to the SFTP server using key authentication.
Note: the “Client public key” and “Client private key” are your keys, not any key that the SSH server provides. For client authentication, it is just your public/private key pair involved.