I’m wondering why your plugin (which seems to be rated or reviewed as the only/or best SFTP utility) requires the server private keys vs public key.
That’s just how SSH public key auth works.
So let’s say you have an SSH server and an SSH client. You generate the public / private keypair and put the public key in the SSH server’s authorized_keys file.
To login the client first sends the public key corresponding to the private key to the server. The server either says yay or nay in response to that. If the server says yay then the session id is then signed by the private key and sent to the server. The server verifies the signature with the public key it has on file and lets you in if it succeeds in verification.
So the SSH client absolutely needs the private key. That’s just how SSH works.
The reason SSH was designed this way is so that the server doesn’t ever have to see the private key. If you just used the public key and didn’t do any signing with the private key it’d be analogous to a poorly protected password. ie. at least passwords are in theory shadowed / hashed / salted / whatever. authorized_keys aren’t.
If a malicious server were setup or the server compromised password auth would result in your password being compromised when you send it. With public key auth the private key is not compromised when you send the public key (and the public key is all you send anyway).
Now, in the case of this plugin, the SSH client and SSH server are on the same machine. There’s not much that can be done about that so long as you want WordPress to be able to update itself. To accommodate that the plugin doesn’t save the key to the filesystem or require the key live on the filesystem.
I suppose that’s not a perfect approach but a perfect approach would be… difficult.
Host key verification could be utilized. Maybe the host key could be stored in the SQL DB and checked every time you try to connect but an attacker could just update the DB.
And maybe the signature could be generated via the browser with JS instead of by the WordPress plugin but that presents it’s own problems as the session id is unique per SSH session. You create an SSH session, get the session ID and then to give the session ID to the browser you’d have to pretty much end the SSH session. Then when you reconnect to send the signed session id it won’t work because the session id of the new session will be different.
So if we were to establish a hierarchy of secure approaches it’d look something like this (weakest to strongest):
FTP
SFTP + auto updating wordpress
SFTP
nothing
Of course, this hierarchy doesn’t take into consideration the fact that an out-of-date wordpress is a security issue unto itself and hard-to-update WordPress’s will likely just not get updated.