On one of my servers once I got it set up right and working smooth there was rarely a need to log into via SSH remotely. So I left the SSH port 22 closed down in the router. When I really needed to log into it, I would log into the router and hit the DMZ button and open up all the ports to the server briefly. Then I would SSH into it using the normal username and password combo do my business and lock down the ports again.
I learned about SSH Keys a few years back while I was doing some volunteer work on a site. The owner of the server had SSH Keys setup on it so that I could use WinSCP to move files up to it. He believed, rightly so in keeping the security beefed up and didn’t bother with FTP at all. Recently (February 2015) I purchased a Raspberry Pi. Eventually it will replace one of the servers I run. For now, it is a test bed and I would like to be able to log right in, no fiddling with the router! Plus why not make it more secure, that is where SSH Keys come in.
I hunted down the method to set up SSH Keys online. Not hard at all. I followed one article that helped set up the keys and it logged in great. But, I still could also still login via username and password, so I had to apply another step beyond what the article explained.
Finally, once you open up port 22, many attempts to login will occur on the port and you can see this in your router log. Mine is setup to email me the router log and I quickly noticed that I was being emailed logs one after the other. I decided to change the default port 22 to map to an obscure number higher than 1024 by adjusting the port forwarding in the router.
Installing SSH Server
In case you haven’t installed the server part of SSH on your machine here is the command line directive…
sudo apt-get install openssh-server
Setting up SSH Keys (Public Key Authentication)
These are examples of the commands that I used to set up the keys while on the client machine. It is best to try this while you are not too far from you machine physically, just in case something goes wrong and you need to get on the machine physically.
Create the RSA Public/Private Key on the client machine
You will be asked where you want the key stored the default is the .ssh directory under your home folder with a filename of id_rsa. Then you will be asked to provide a passphrase, hit enter if you do not want a passphrase. A passphrase provides an extra level of security. If someone gets a hold of your machine or private key, they still need the passphrase to get anything going.
ssh-keygen -t rsa
You will get the following message. Depending on the machine, it may take a few seconds after the first line, while the machine is doing the calculation before you see the second line. The Raspberry Pi took about 3-4 seconds to spit out the second line.
Generating public/private rsa key pair. Enter file in which to save the key (/home/pi/.ssh/id_rsa):
The file is alright by default, hit enter, unless you have another place that you need it and know what you are doing. I assume some config file in the system expects the key in the .ssh folder.
Next comes the passphrase question…
Enter passphrase (empty for no passphrase):
…and again….
Enter same passphrase again:
Finally the key is generated and a randomart image is generated, interesting looking but nothing we need for this operation…
Your identification has been saved in /home/pi/.ssh/id_rsa. Your public key has been saved in /home/pi/.ssh/id_rsa.pub. The key fingerprint is: d7:33:ed:91:ab:00:a7:bd:15:8d:15:21:fe:ed:6b:df pi@raspberrypi The key's randomart image is: +--[ RSA 2048]----+ | . o. | | . . . | | . . | | . * o | | S o * * .| | * = + | | . o . o .| | + . .o| | . . ..E| +-----------------+
Copy the Public Key to the Server
Next you will copy the key up to the server using the ssh-copy-id command. It will log you in and you will use your normal password that you have for your login and then it will copy the key to the server. The example shows that the user is pi and the ip=192.168.1.17. Change these to your id and server IP.
ssh-copy-id pi@192.168.1.17
In this example I am installing it on the same machine that I created it. So this is what I see…
pi@raspberrypi ~ $ ssh-copy-id pi@192.168.1.17 The authenticity of host '192.168.1.17 (192.168.1.17)' can't be established. ECDSA key fingerprint is 7e:f0:94:8a:bd:f2:95:44:f3:a5:36:ff:e3:64:48:a3. Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added '192.168.1.17' (ECDSA) to the list of known hosts.
…And the key is added.
Test It
Now you can login to your server with the newly created keys. But you still can also login via the username and password combo.
Making it SSH Key Only login
You need to set the sshd_config to explicity allow Public Key Authentication. This step requires editing the sshd_config file. Which I didn’t remember the location of so I used…
sudo find / -name sshd_config
Edit it …
sudo nano /etc/ssh/sshd_config
Find the line that reads PasswordAuthentication which is set to yes by default, as in commented out = yes.
Set it to no and make sure it is uncommented…
PasswordAuthentication noCheck to see that this is set also…
ChallengeResponseAuthentication noRestart the SSH server…
sudo service ssh restartRemapping the SSH Port 22 to something less obvious
If you don’t remap to port, lots of hits happen to it. Attempts to login that will fill up your router logs. In theory someone can still find the new port, but they would have to get lucky or scan the ports. So this does cut down on bogus login attempts significantly.
There are two ways of doing this, in the configuration file sshd_config or by setting up the port forwarding in yur router. I left sshd_config set at port 22 and made the change in the router. I care about the port being mapped to something else for the outside world on my LAN it can stay 22. So I can simply use SSH servername and not specify a port.
sshd_config mod method
There is a line near the beginning of the file, change the 22 to something else and restart the sshd server…
# What ports, IPs and protocols we listen for Port 22
Router Port Forward Mapping Change Method
Or go into your router and find the port forwarding. In my Netgear router it was under Advanced–> Port Forwarding/Port triggering. You will see a list that allows there to be changed…
|
External End Port | Internal Start Port | Internal End Port |
Set it up for a port other than 22 for External Start and end Port, 5678 in this example…
| SSH | 5678 | 5678 | 22 | 22 | 192.168.1.170 |
More Tightening of SSH Security
I have not done any of this yet on my machine but for FYI. Under the spot in sshd_config where the port is set there is a place where you can place a whitelist of IP addresses that the sshd will listen for. This can restrict the IP space that can connect to the machine..
# Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0
It is also possible to further restrict the actual users that are allowed or denied access to the machine via SSH. This is accomplished by using the AllowUsers, AllowGroups,DenyUsers,DenyGroups directives.
Example…
AllowUsers joe bob naomi
AllowGroups workinggroup powerusergroup
DenyUsers tempuser1 tempuser2
DenyGroups gaming
You can also block the ability to login as root, so that users will have to su to root once logged in.
PermitRootLogin on
Encryption and Keys
Creating keys such as the RSA pair is an interesting mathematical concept. It falls in the realm of one way functions. You can have the public key and have only remote odds of being able to generate the corresponding private key by a brute force search. But, the other way around is easy. It’s kind of like glass breaking or throwing a cup of water in the ocean, in theory it is all still there, but to put it back together is nearly impossible.
In physics this is what makes “time” on the macro scale. On the quantum level, time really doesn’t matter. You can play particles interactions backwards and forwards and it all works out OK. Feynman diagrams, work both ways. But on the macro level, a lot of things just go one way, just like the hash algorithms that generate the encryption keys. The same thing applies to hashes to generate look up tables, it is easy to go one way, to the lookup from the hash, but harder to go the other way. Ratchets, diodes and worm gears, go one way but not the other.
Resources
How do I force SSH to only allow uses with a key to log in?
7 Default OpenSSH Security Options You Should Change in /etc/ssh/sshd_config