My company is serious about security and willing to move to SSH key-pairs. Users can generate their SSH key pairs independently and I worry if they set a pass-phrase. Can I enforce this? Does signing with ssh-keygen help?
2 Answers
No. You can't enforce on the server side that the key has passphrase. Key is always on the client side and the server sees only the signature of challenge and public key. Certificates (aka signed keys) will not help either, because the public keys are signed.
I propose you to have a look at some kind of two factor authentication or smart cards if you want to go this way in security.
Since we cannot enforce the usage of a passphrase server-side, we have to mitigate the risk by education of the users.
Private ssh-key files are sensitive data that could lead to compromised systems if not managed properly. One way to ensure that a passphrase is used is a formal policy with a penalty for keys found unencrypted. But it is not hard or inconvenient to use ssh-keys properly.
Using ssh-agent
and ssh-add
on a daily basis provides the same convenience of password-less logon during the shift:
eval $(ssh-agent -s)
ssh-add
Note: The Gnome Keyring can store the passphrase for you.
Note: on the Mac you can even store the passphrase in your Keychain:
ssh-add -K
An extra control is the use of a newer file format and key type that will provide protection for brute-force attacks on the file, if the keys have a passphrase it take a few seconds to load in ssh-agent (brute-forcing will take forever).
ssh-keygen -t ed25519 -a 500
-
OpenSSH 7.8 up (since 2018) uses new-format file for all keytypes, and before that you could get it for types other than ed25519 with
-o
(lowercase oh). Although using ed25519 is a good idea in its own right if (all) your servers support it. Commented Feb 9, 2021 at 4:13 -
RHEL6 doesn't seem to support ed25519 keys, but RHEL6 is supposed to be End-of-life since November 2020. Commented May 21, 2021 at 20:36
-
ed25519, and new-format, were added upstream in 6.5 in 2014. Although until IIRC 2018 RedHat removed ECC code from its builds, apparently due to patent concerns; I don't know if they extended this to the Bernstein variants, since I encountered it mostly with OpenSSL versions that only did X9-type (that's why OpenSSH originally forced new-format only for ed25519) -- and in CentOS not actual RHEL. Commented May 22, 2021 at 4:49