There are two ways of authenticating to a server with SSH: user/password based authentication (which is now by many considered outdated and insecure) and key pair based authentication. Let’s start from the legacy one and build up to the modern way of doing things:
Username and Password Based Authentication
In this version, all you will need to to connect to your server is to run
$ ssh myuser@server
And you’ll be prompted for that user’s password (nb – the user is configured on the server, not your client). Type it, press enter and voilà – you now have an open shell into the server.
How to set it up
You can enable this type of authentication on the server simply by making sure that the following lines are present in the file /etc/ssh/sshd_config
Match User <username> PasswordAuthentication yes
Then restart the ssh daemon with
$ sudo service sshd restart
Remember you can change the password of the user (you should set a strong one) by running
$ sudo passwd <username>
While this approach might be simple and familiar, it presents many security issues:
- It is very vulnerable to brute force attacks
- Bad (easily guessable) passwords are everywhere
- It can be shoulder surfed or read with a keylogger
- The password has to be sent by the ssh client to the server over the network – which means it is vulnerable to man in the middle attacks and/or an ssh demon modified by a malicious actor
Most of these are addressed by key pair based authentication, which is the way to go nowadays.
Key Pair Based Authentication
The idea is to assign a pair of asymmetric keys to every user that needs authentication.
Users will store their public key in every server they want to use, while their private key will remain secret and be safely stored on their computers.
That way, instead of inputting a password, your client can authenticate by specifying the private key file to the ssh command with the -i
$ ssh -i ~/.ssh/<your-private-key-file-name> myuser@server
Private keys are usually stored in the user’s ~/.ssh~/.ssh/authorized_keys
When a connection is attempted, the server will verify that the request was signed by one of the allowed private keys. (See below how that is accomplished).
How to set it up
Generate key pair with:
$ ssh-keygen -t rsa -f ~/.ssh/key_name_id_rsa
You will be asked to input a passphrase for the key. This is optional and you can leave it empty, but you should definitely input a value if you want an extra security layer (the key will be stored in encrypted form and you will be asked for the passphrase every time you try to use it with an SSH client).
This will generate 2 files:
~/.ssh/key_name_id_rsa~/.ssh/key_name_id_rsa.pub
You can now copy the contents of the public key file into your server’s ~/.ssh/authorized_keys
Next set the right permissions for your private key with:
$ chmod 600 ~/.ssh/key_name_id_rsa
This should allow you to ssh safely into the server with your private key.
Tip:
In addition to containing your public key file, you can also use authorized_keys
command="/usr/local/bin/your_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
Or from which host a user is allowed to authenticate:
from="yourhost,anotherhost", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
Etc.
How a key pair works
Pairs of public and private keys have a special asymmetric cryptographic relationship: everyone holding the public key can verify a message is signed using the corresponding private key – but without ever having access to the private key itself.
This is accomplished by applying mathematical problems called one way functions: operations which are easy to perform, but hard for an eavesdropper to reverse.
You can read more about public key cryptography here, or watch the excellent video below for a simple explanation: