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 for an existing user that you want to authenticate with:

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 option:

$ ssh -i ~/.ssh/<your-private-key-file-name> myuser@server

Private keys are usually stored in the user’s ~/.ssh folder, while public keys live in the ~/.ssh/authorized_keys file on the server.

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 (private key)
  • ~/.ssh/ (public key)

You can now copy the contents of the public key file into your server’s ~/.ssh/authorized_keys file.

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.


In addition to containing your public key file, you can also use authorized_keys to restrict what users can do over SSH, like which commands can be run:

command="/usr/local/bin/", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Or from which host a user is allowed to authenticate:

from="yourhost,anotherhost", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...


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:

Next: Known Hosts →

← Previous: Introduction

Table of Contents:

  1. Introduction
  2. Authentication
  3. Known Hosts
  4. SSH Agent
  5. Config
  6. Jumping Hosts
  7. Tunnelling and Port Forwarding
  8. X11 Forwarding
  9. Multiplexing and Master Mode