800+ IT
News
als RSS Feed abonnieren📚 Best and Easiest way(s) to Secure OpenSSH authentication on your personal systems.
💡 Newskategorie: Linux Tipps
🔗 Quelle: reddit.com
There are two ways that I like nowadays and both of them involve 2FA and hardware keys. Specifically Yubikey in my case, but other ones will probably work as well.
The traditional approach to securing OpenSSH authorization involves several approaches:
- Traditional SSH Keys - A very good and robust approach for managing access on personal systems. In large organizations the problem of key management is hairier then it seems at first glance.
- SSH Keys signed with OpenSSH built-in CA support - A intermediate approach that most people are unaware of that are a good match for many businesses and other organizations. With this approach you are using SSH keys that are signed by a CA. This way you can do things like revoke system access quickly in case of a compromise.
- Kerberos - A great approach if you are using AD or FreeIPA already. But the overhead of managing it is pretty high and relatively minor issues with network configurations can cause massive headaches, which makes it detrimental for personal use.
So for personal use just old fashioned SSH keys are the way to go. However We can make OpenSSH auth even more secure with hardware tokens.
Now the older way to do it is to enable 2FA using OTP (one time password) approach. This generally involves adding additional login requirements in the form of PAM modules. This is going to be the most common search result as it's been in use for years now. It can take advantage of your own TOTP infrastructure or tie into Google's or other providers. This is fine, but I really despise working with PAM. If I can use something OpenSSH supports natively then that is the way to go, IMO. Especially when you can avoid additional infrastructure dependencies.
The two "new" ways I have discovered as of late are:
- Take advantage of OpenPGP/Smartcard support available on some hardware cards. Most notable Yubikey 5 series, but there are others. With this approach you use GPG and gpg-agent to manage your private keys. Access is protected by a card PIN (can be up to 127 ascii characters).
- Take advantage of FIDO2. Since version 8.2 OpenSSH has supported FIDO2 authentication natively. Which is freaking fantastic. You should use a password encrypted private key for additional security. Make it more 2FA-ish.
Pros of OpenPGP/Smart card approach:
- Can work with older versions of OpenSSH
- gpg-agent support is built into proper Linux desktops
- All the private keys are managed via hardware token.
- Can use hardware token with a wide variety of other software.
- More single-sign-on-like You don't have to keep fingering your key for things like ansible.
Cons:
- A lot of hardware tokens don't have OpenPGP/Smartcard support.
- Can be a pain to migrate secured (password disable) systems from old key to GPG key. You end up doing things like running one shell with SSH_AUTH_SOCK ssh-agent and another with gpg-agent, or setting up aliases to help copy over new keys and remove old ones.
- A lot of work is required to setup your card. Need to setup subkeys and such things.
- You really need to have a second hardware key as backup in case your main key gets lost or damaged.
- By default gpg deletes private keys from your ~/.gnupg keyring after copying to the card, so you have to back up your keyring prior to that if you want to have backups.
- Need to configure ssh client to look to gpg-agent instead of ssh-agent.
- Can't use cool ed25519 keys.
Pros of FIDO2 approach:
- Minimal additional configuration. Pretty much all you need to do is use ssh-keygen. It's exceptionally easy to setup.
- ssh-agent is integrated by default in decent Linux desktops.
- Uses separate encrypted private key (recommended) for additional password protection.
- easy migration to new keys.
- Fido2 works well with many websites.
Cons:
- Can't backup your hardware token. You need a second token if you want backup.
- If you want backup token you have two sets of keys to manage.
- Need to finger the device for each SSH usage (can mitigate with OpenSSH ControlMaster feature. May not be true for all hardware tokens.
- Needs very new (>8.2) version of OpenSSH to work. So no-go on LTS installs like vanilla CentOS 8.
As you can see the Fido2 approach is the slicker and newer of the two approaches. Probably slightly more secure as well.
With the FIDO2 all you have to do is:
- Purchase a hardware token that has U2F/FIDO2 support.
- Setup the FIDO2 PIN (recommended) (for yubikey use yubiky-manager command "ykman set-pin")
- And then run ssh-keygen:
ssh-keygen -C "nice name for key here" -t ed25519-sk -O resident -f ~/.ssh/mynewkey And it should prompt you for your fido2 pin and that's it. You can begin copying around the key with ssh-copy-id.
If you do get a hardware token and it does have OpenPGP support then you really are going to want to use it for other stuff. It can tie into Pass password store, secure communication with email and other protocols and a whole bunch of other stuff. If you are already doing that stuff adding OpenSSH support is fairly trivial.
The approach to properly setting up OpenPGP support using GNUPG is significantly more involved. The best guide I know of is this one:
He has you go full-paranoid with offline encrypted creation and backup of the keys among other things. Highly recommended. If you are doing it you might as well do it right.
After that you just need to make sure that you have "enable-ssh-support" set in your ~/.gnupg/gpg-agent.conf. (maybe restart your gpg-agent or log out and log back in, whatever works best for you).
And then tell OpenSSH to use the gpg-agent socket. Set the equivalent of
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket) If your .bashrc or whatever is appropriate for your setup.
After that you can run:
ssh-add -L to list your public key. Which then you can copy around manually. Or just use ssh-copy-id, it'll do the right thing even though there is no pub file in ~/.ssh for it.
After that then pick a standard OpenSSH hardening guide. All the same things apply. Just don't go nuts. No need to make it easy to trivially trigger a denial of service on yourself using silly things like fail2ban. Remember with passwords disabled brute force attacks are worthless. Failed logins are just OpenSSH doing it's job and are about as interesting as logging pings. Successful logins are what you should be monitoring for and be paranoid about!
In /etc/ssh/sshd_config do things like:
PermitRootLogin no PasswordAuthentication no ChallengeResponseAuthentication no
[link] [comments] ...