SSH keys are really just a pair of long randomly generated character strings that are linked together sort of like a key and a lock are linked together where only one key can be used to unlock a single lock. It sounds simple enough, however, since they are so flexible in their uses, the methods of generating key pairs and actually implementing them for authentication can be a bit obscure if you haven't done it before. I had a need to make this work because of a desire to set up a secure public facing SFTP server. Using only password authentication for a public facing server isn't necessarily bad if you do it right, but by eliminating the use of password authentication altogether, there's no way anyone can guess your password.
get puttygen.exe for your architecture from the site below
when you open it up it will look like the image on this page but it will be blank.
adding a passphrase is optional, but recommended. Only users who know the passphrase can use the private key file for authentication. This passphrase will decrypt the key LOCALLY without any transfers of plaintext passwords over the internet. Once your SSH client verifies the passkey is correct, it then uses the key contained in the file to authenticate over the internet. Make sure not to make the passphrase the same as the Linux user you are logging in as in your ssh session. The passphrase should be unique to the key itself.
Click "generate keys" and it will create a key. I always keep the defaults and use RSA parameter at the bottom. Not sure what the others are for because I haven't needed them.
before saving the keys out to a file, make sure to update the comment section. This text is saved in the key itself so you can identify which public keys on your server belong to which devices or individuals.
in some cases you might need an older version of the private key file depending on how hold your ssh client is. I had to use v2 for an old version of PuTTY that was still on a machine I occasionally use. In the PuTTY Key Generator menu choose "Key" and then "Parameters for saving key files..." (see image).
In the Parameters window (see image with highlighted line) you'll find PPK file version. Here you can select 2 or 3.
You can also load existing ppk files originally saved as one version and then re-save them as a different version without modifying the key itself. This allows to change file versions without having to generate a new key pair.
When saving the key files, I didn't have a need for the "public" file, since I was using OpenSSH I copied the key right out of the puttygen textbox and pasted it right into the authorized_keys file. You MUST save the "private key" file. It contains the private and the public key and is the file you would load into puttygen to make changes or view the OpenSSH string.
Once you have generated a private/public key pair, you have to put the public key from the pair you just generated on your server. I have only ever done this on a raspberry pi running raspberry pi os, so my instructions will be Linux based, but it will be very similar in any environment.
Create the following file either by using touch or vi:
~/.ssh/authorized_keys
Change permissions (I'm not sure why, but it was pretty clear this was a necessity)
chmod 600 ~/.ssh/authorized_keys
modify the file and add your public key portion of your string into it. You'll notice in the first "PuTTY Key Generator" image on this page a box at with a description of "Public key for pasting into OpenSSH authorized_keys file:". Just highlight everything in that box and paste it into the authorized_keys file. You can load existing ppk files and use the same method. It appears to add something to the beginning and also the comment to the end, which you can probably replicate manually, but I haven't tried it
Separate keys by an empty line within the file. You can have multiple public keys in the same authorized_keys file so more than one ppk can access the server. Copying the same ppk file to multiple devices is not ideal. If one is compromised, you have to generate new keys and update the ppk on all your devices. If you limit it to one key pair per device, you just de-authorize the compromised key by removing it from the authorized_keys file and no other devices are affected. Notice the comment tacked on to the end of the public key. If you keep your key comment descriptive enough, you can use that to identify which public key needs to be removed.
So now you can gain access to your SSH connection using your private key, but, the server still allows password authentication. Here's how you disable password authentication.
CAUTION: During this process there is a chance you can lock yourself out of your device. Since the config changes you make are only applied to future open sessions, and restarting the sshd service will not reset your ssh connection, it's a good idea to keep an ssh session open and create new sessions for testing... of course this only applies to headless pi configs. If you have a keyboard and monitor attached to your pi, you should be fine.
Now let's modify the sshd config file:
vi /etc/ssh/sshd_config
This setup is already pretty secure. If you only care about security while coming in from a public ip address, just disable password authentication by uncommenting the following line and setting the value to no
change
#PasswordAuthentication yes
to
PasswordAuthentication no
the config file includes the default values, but they are commented out to show that they are the default. By doing this, you can see what the defaults are and what your options are to make changes... pretty cool
save and close the file then restart the sshd service with the following command:
sudo service sshd restart
it appears restarting "ssh" and "sshd" do the same thing. I think they're aliased, so if one doesn't work try the other.
now, you can't use a password to log in... hopefully you have some other way of accessing your pi besides ssh or you left a session open.
No more passwords is definitely secure, but if you're changing client PCs or phones a lot on your local network, it can be a pain creating new keys for a device you might use only one time. After some research I found there is a method to allow passwords, but only under certain circumstances. The following will allow you to use password authentication, but ONLY if you are connecting from either a 10.* network or a 92.168.* network. This guarantees you are on the same local network as the pi and will allow you to connect from anywhere within your LAN (or VPN) using password authentication. For reference, here is a site that shows some good examples of utilizing this config file feature of sshd: https://thelinuxcluster.com/2020/11/09/allow-ssh-root-login-from-selected-ip-addresses/
According to the site, these exceptions to the rest of the config file must be at the very end of the config file. I'm not sure of the actual limitations, but the following text at the end of the /etc/ssh/sshd_config file accomplished exactly what I was looking for:
# Password use override
Match Address 192.168.*,10.*
PasswordAuthentication yes
Restarting sshd made it work as expected. Passwords were accepted while on local network, but connections from the internet were denied.
Now you got your keys created and your server all set up, so let's see how to use this ppk file to get into your server.
While creating or modifying an existing connection in PuTTY, make sure "SSH" is selected as the connection type on the main window.
Then go to the tree on the left and under the "Connections" section, expand "SSH". Highlight "Auth" without expanding it.
You'll see a window like the one shown in the image on this page.
In the highlighted box, browse and choose your ppk file from your computer.
Click "Open" or go back and save that profile for future use.
When you try to connect, you will get a user prompt, which is the user you set up the keys in, and instead of a password prompt, you will get a "passphrase" prompt. That is the passphrase you set up when generating that specific set of keys.
That's it. The rest of the settings work with the defaults. I'm not sure what the rest of them do, but I know this worked. If I need to know more for some reason, I will add that info here.