SSH is heavily used across large networks, and this can be a good thing. I mean it’s great, it is nicely encapsulated, unlike telnet (still see this). However, when it’s configured badly you might as well not have bothered in the first place.
Even though root access via username and password is normally disabled by default, you still find systems specifically modified to allow root login via passwords. Ok, again this wouldn’t be that bad if the password was worthy of a highly privileged account, but no. I still find weak password use with highly privileged accounts.
So this post is going to explain how to setup SSH key access onto a server. Firstly, let’s explain how the SSH key system works. Of course the majority of people know about public-key cryptography. The fact it uses two keys, one public and one private. However, they get confused about how the keys are used, where the keys should reside, and how to configure SSH key access correctly, or at least in a more secure manner.
Let’s create a hypothetical scenario, yes those always work well :). Ok, so I have for instance a Mac I want to use to manage a Debian server via SSH.
Initially we need to generate our key pair, this is done using ’ssh-keygen’. More specifically in this instance, ‘ssh-keygen -t rsa -b 4096 -C DL-Mac’. We are going to set our bit rate at ‘4096’(-b), generate an ‘rsa'(-t) key pair and set a comment of ‘DL-Mac'(-C) (the comment is found in the public key).
‘ssh-keygen -t rsa -b 4096 -C DL-Mac’
Once your passphrase is set and I would suggest setting it, if your keys end up in the wrong hands they would still require the passphrase to use them. The keys would by default be saved to ‘~/.ssh/id_rsa’, but feel free to save it to any directory and filename you like. The two files generated by default in the ‘~/.ssh/’ directory are, the ‘id_rsa’ file, this is the private key and, the other is ‘id_rsa.pub’, which in turn is the public key.
*You could now add the private key to your authentication agent (‘ssh-agent’) which would take care of the authentication on your behalf, so there would be no need to enter the passphrase all the time.
To achieve this you would use ‘ssh-add’ with the ‘-c’ flag and point it to your private key ‘ ~/.ssh/id_rsa’. The use of the ‘ssh-agent’ has some security concerns relating to the ability for others to access the agent. The ‘-c’ flag asks for permission for every connection, put some compensating control around its use.
‘ssh-add -c ~/.ssh/id_rsa’
You will be notified of ‘Identity added:’.*
Bare in mind it would be more secure to not be lazy and enter your passphrase each time.
You can now add your public key to the server you want to connect to. If you have admin access via SSH you could copy the key from your client to the server using ‘ssh-copy-id’.
This command copies the public key via SSH using your root account on the remote server. It will respond with something similar to.
‘sudo ssh-copy-id -i ~/.ssh/id_rsa.pub email@example.com’
You can now go to your server and disabl the username and password access by modifying the server SSH config file.
‘sudo nano /etc/ssh/sshd_config’
Change the following line: ‘PermitRootLogin yes’ –> ‘PermitRootLogin without-password’.
Some additional config changes would include ‘StrictModes yes’ and set ‘PermitRootLogin no’. ‘StrictMode’ disallows authentication if the key file permissions are to lax.
Anything you only want a specific user to access should be set to ‘(rw——-)’ aka ‘0600’ by the specific user. This can be achieved using ‘chmod 0600 file_name’. This equates to the owner may read and write to the file and all other users have no access rights. The ‘PermitRootLogin no’ setting is self explanitory but for the sake of brevity, it means the root account can not login remotely. So make sure you have your relevant account setup to sudo before changing this setting and restarting the service.
All that is left to do now is restart the SSH service.
‘sudo service ssh restart’
You can now SSH to the remote server from your mac using your private key as authentication, your public key as authorisation along with your passphrase (unless you are using the ‘ssh-agent’ of course). The server compares your public key with the one it has stored, your passphrase is used to decrypt the key authorising the the connections legitimacy.
You can of course generate the key pair server side, but you would need to pass the key pair to the client after adding the pub key to the authorised keys list server side.