Linux SSH Key KB ID 0001928
Problem
Having a comms background, SSH connecting to something is a procedure I’m very familiar with. You SSH to something, it asks you for a username and password, and providing that they are correct, you’re connected. Also, because the client and server negotiate the encryption of the password, the information sent over SSH is protected from being sniffed or captured. Which is great until an attacker knows the username and password, or someone compromises your social media and finds you use the same password for everything!
Solution : Linux SSH Keys
Disclaimer: Before I get messaged, you can also deploy fail2ban, which analyses the /var/log/auth.log file for patterns of attack (like multiple failed logons from the same IP address). It then stops any further attempts (from that IP address for a period of time.
SSH keys work very simply, you generate two keys, a PRIVATE KEY and a PUBLIC KEY, the private key you keep secure and NEVER SHARE it, as if it were a password, like so.
You can take the PUBLIC KEY and place that on the server you want to connect to, and (because you retain the private key) you can connect seamlessly over SSH, without the need to enter a password.
Generating a Linux Key Pair (macOS & Linux Clients)
Note: I’m not getting into a debate about whether or not macOS is Linux (it isn’t). But the procedure assumes you have OpenSSH installed; most client Linux distros have it installed by default, and on most servers, you have to add it. But I will assume that’s already installed and running on your CLIENT machine.
Generate your keypair with the following command.
ssh-keygen -t rsa -b 4096 -C "your_email@petenetlive.com"
Note: rsa is still widely supported, but you may want to use ed25519 for more modern Linux targets as it’s considered faster and more secure. 4096 defines the key length, and the -C just adds a comment (in this case, your email address).
You will be asked to select the location for the keys to be saved, and also asked for a passphrase (which you can leave blank; if you use one, you will need to enter it each time you log on, see below).
What’s the passphrase for? The passphrase for an SSH key is like a second layer of armour for your private key; it encrypts the key itself, so even if someone gets hold of the file, they can’t use it without the passphrase.
Warning: Be careful if it says the keys already exist, and ask you if you want to replace them. If those old keys are required, you’re about to trash them. (I’d suggest moving them to another folder first, to be on the safe side.)
That has generated the PUBLIC and PRIVATE Keys for you.
File | Purpose |
---|---|
id_rsa | Your PRIVATE KEY (keep secure!) |
id_rsa.pub | Your PUBLIC KEY (share freely) |
Send Your Linux SSH Key to the Remote Server
Now all you need to do is place the PUBLIC KEY on the server YOU WANT TO CONNECT TO this is pretty simple, there’s another OpenSSH command that you can use (ssh-copy-id).
ssh-copy-id username@remote-server
This will connect to the remote server, appends you PUBLIC KEY (currently stored locally on YOUR machine, (in ~/.ssh/id_rsa.pub) to ~/.ssh/authorized_keys on the REMOTE SERVER.
For the Non-Linux types, the tilde symbol ‘~’ just means home directory; it saves you typing /home/username (you’re connecting with your username, so it knows which home directory to use.
Above its the first time I’ve connected to this host, so it asks me to accept the remote servers certificate (if you’ve connected before you will not be asked this), I say yes (or press y and enter), then I have to enter the username for the user I’m using to connect (which needs to exist on the remote server, and the SSH key is imported.
THE NEXT TIME I connect, it won’t prompt for a password, BUT if I set a passphrase earlier, it WILL ask me for that, like so.
If you HAD NOT SET A PASSPHRASE, then it will simply log you on straight away like so.
Optional – Enforce the use of Linux SSH Keys and STOP the Use of Passwords.
You may wish to depreciate the use of passwords and solely use SSH keys for connections to your server. If so, make sure you have at least one user setup, (and tested) or at least have terminal access if you are NOT at the same physical location as the remote server before proceeding.
Firstly, we need to edit the sshd_config file. To do that, run the following command.
sudo nano /etc/ssh/sshd_config
Locate the following entries, and set them accordingly
- PasswordAuthentication no
- ChallengeResponseAuthentication no
- UsePAM no
Note: You may want to consider adding ‘PermitRootLogin prohibit-password‘, but most modern Linux distros have the root account disabled anyway, this will force you to use SSH keys if you HAVE TO have root enabled for remote SSH access, (please don’t, but I know in the real world there’s many reasons why this happens).
Exit and save the file (‘CTRL + X’, then ‘Y’ to save).
Then restart the SSH service.
sudo systemctl restart sshd
Real World Tip: On some systems like Ubuntu with cloud-init, you may also need to check /etc/ssh/sshd_config.d/50-cloud-init.conf and remove or modify any conflicting PasswordAuthentication yes entries
Linux SSH Key Related Articles, References, Credits, or External Links
NA