Multiple public/private key pairs for the same user

sftp

First, sorry if this question has already been asked/answered – I've searched but perhaps I haven't recognised the answer….

What we have is a cluster of servers which need to access a single remote server using sftp.

We are migrating from one remote server to another at the same (remote) location.

We also want to refresh the public/private key pairs on the configuration as part of an ongoing security review.

My question is – can we have multiple public/private key pairs for the same user between server A and server B?

I want to do this to allow for cutover testing – but am concerned that the software checking keys may only try one of each type (rsa/dsa?) before rejecting the connection method and moving to the next type of key.

Hope it's a straightforward question – please let me know if I need to supply more details.

Best Answer

Yes you can have multiple keypairs for a single user. On the remote site put all of the public keys in the users ~/.ssh/authorized_keys file.

On the local site have each private key in a separate file and then use the -o IdentityFile=/path/to/privatekeyfile to specify which private key to use. You could use

sftp user@remote.tld ...

to use the default (current ?) private key and

sftp -o IdentityFile=/home/user/.ssh/usernewkey user@remote.tld ...

to use the new key.

Related Solutions

Linux – Enabling DSA key authentification for SFTP while still keeping password login as optional (Ubuntu 12.04)

The permissions in the /root/.ssh directory are wrong if StrictModes yes is set in /etc/ssh/sshd_config. You can check if this is the case by enabling LogLevel DEBUG, restarting the server and watching the logs (/var/log/auth.log for Ubuntu, if you have not changed the stock syslog configuration)

Correct them issuing:

chmod -R go= /root/.ssh

and try again.

Having both PubKeyAuthentication and PasswordAuthentication allows to do what you want, i.e. for those users who present a public key, their access will be passwordless (provided their public key exists in the authorized_keys file); and those who don't, will be prompted for a password.

And RSAAuthentication is used only with version 1 of the protocol, which, hopefully, you are not using, as it is insecure.

Don't forget to read the SSHD_CONFIG(5) manpage.

Linux – What could cause an SFTP host key fingerprint mismatch

If it is the first time they connected, it doesn't matter if there's a mismatch... the client just had some unrelated old entry that happened to have the same host name or ip address associated with it. Just clear it with:

ssh-keygen -R $name_or_ip

After you do that, it should certainly say whether it is RSA, ECDSA, etc. the next time you connect. If not, try using a proper client like the OpenBSD OpenSSH client which is standard on Linux, or trying -v (or -vvvv, etc. verbose options). And then verify and accept the new key. The key fingerprint format in old clients is md5 (and in new ones is sha256, in some weird base64 format instead of ascii-hex), and the right way to get the fingerprint on the server side is:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Best Answer

Related Solutions

Linux – Enabling DSA key authentification for SFTP while still keeping password login as optional (Ubuntu 12.04)

Linux – What could cause an SFTP host key fingerprint mismatch

Related Topic