In OpenSSH prior to version 3, the sshd man page used to say:
The $HOME/.ssh/authorized_keys file
lists the RSA keys that are permitted
for RSA authentication in SSH
protocols 1.3 and 1.5 Similarly, the
$HOME/.ssh/authorized_keys2 file lists
the DSA and RSA keys that are permitted
for public key authentication
(PubkeyAuthentication) in SSH protocol 2.0.
The release announcement for version 3 states that authorized_keys2 is deprecated and all keys should be put in the authorized_keys file.
One really good reason to use authorized_keys2 is if you have a VPS with Arvixe where the tech support team continually overwrites your authorized_keys file.
I also liked that there was a second authorized_keys file.
I use and distribute my authorized_key file to multiple computers, limiting my access so only my primary home is allowed to login to other accounts. But that generally means it is the same on all my accounts, and is overwritten if it is different. I have also seen other computer configuration programs overwrite it continuously (Puppet).
However when I login to the front node of a large cumputing cluster, I like to put the keys in authorized_keys2 file, so that the front node can access the other nodes of the cluster, but does not have access to any other machine. that is I used it as a 'local authorization file', as separate to a 'distributed authorization file'.
It becomes especially important when shared homes are used (as they generally are on a cluster).
It is a real shame it is now depreciated.
An alternative that would be nice would be a include mechanism, or a "authorized_keys.d" sub-directory, or a 'use these keys for this host'.
In OpenSSH prior to version 3, the sshd man page used to say:
The release announcement for version 3 states that authorized_keys2 is deprecated and all keys should be put in the authorized_keys file.
The use of authorized_keys2 for protocol 2 has been deprecated since 2001.
[via]
Originally the difference was for version differentiation.
But don't bother any more, as now the
2
can be ignored.One really good reason to use authorized_keys2 is if you have a VPS with Arvixe where the tech support team continually overwrites your
authorized_keys
file.I also liked that there was a second authorized_keys file.
I use and distribute my authorized_key file to multiple computers, limiting my access so only my primary home is allowed to login to other accounts. But that generally means it is the same on all my accounts, and is overwritten if it is different. I have also seen other computer configuration programs overwrite it continuously (Puppet).
However when I login to the front node of a large cumputing cluster, I like to put the keys in authorized_keys2 file, so that the front node can access the other nodes of the cluster, but does not have access to any other machine. that is I used it as a 'local authorization file', as separate to a 'distributed authorization file'.
It becomes especially important when shared homes are used (as they generally are on a cluster).
It is a real shame it is now depreciated.
An alternative that would be nice would be a include mechanism, or a "authorized_keys.d" sub-directory, or a 'use these keys for this host'.