SSH for beginners: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Ebarrier (talk | contribs)
m Ebarrier moved page Ssh for beginners to SSH for beginners
Ebarrier (talk | contribs)
 
(28 intermediate revisions by the same user not shown)
Line 1: Line 1:
Author: Etienne Barrier
Author: Etienne Barrier
Last modified: 19.04.2016


==Introduction==
Last modified: 01.05.2016


==Background==
This tutorial-like article is intended for beginner users who would like to learn about SSH cryptography protocol from scratch and/or get a deeper understanding of it.  
This tutorial-like article is intended for beginner users who would like to learn about SSH cryptography protocol from scratch and/or get a deeper understanding of it.  


It has been made using Linux Ubuntu 14.04 distribution, therefore we cannot guarantee that the information is relevant for other Linux distributions or for Windows or MAC.  
It has been made using Linux Ubuntu 14.04 distribution, therefore it is not guaranteed that the information is relevant for other Linux distributions or for Windows or MAC.  


It is assumed that you are already familiar with the basics of Linux command line terminal commands. We are not going to explain the commands which are not directly related to SSH.  
It is assumed that you are already familiar with the basics of Linux command line terminal commands. The commands which are not directly related to SSH will not be explained.  


SSH was built based on a client-server architecture and we are focusing only on the client side of SSH. See here for SSH on server side for Ubuntu [https://help.ubuntu.com/community/SSH/OpenSSH/Configuring]  
SSH was built based on a client-server architecture and this article focuses only on the client side of SSH. See [https://help.ubuntu.com/community/SSH/OpenSSH/Configuring here for SSH on server side for Ubuntu.]  


For any comments to the author of this article, please send an email to etienne(dot}barrier{at]itcollege[dot)ee [put picture]
For any comments to the author of this article, please send an email to etienne(dot}barrier{at]itcollege[dot)ee.


==A bit of history==  
==A bit of history==  


The SSH protocol was invested in 1995 by the Finnish Tatu Ylönen who was a researcher at the Helsinki University of Technology in Finland. He decided to develop his own remote connection protocol after an attack performed against his university. He published the source code if his protocol and everyone could use it for free. SSH gained popularity very rapidly and Tatu understood that SSH could become something much bigger. Consequently, he founded his company the same year, called SSH Communications Security, to develop and sell his service around SSH. Tatu Ylönen is still the CEO of the company (ssh.com/about/management).  
The SSH protocol was invested in 1995 by the Finnish Tatu Ylönen who was a researcher at the Helsinki University of Technology in Finland.<ref>[http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch01_05.htm docstore.mik.ua] Short history of SSH</ref> He decided to develop his own remote connection protocol after an attack performed against his university. He published the source code of his protocol and everyone could use it for free. SSH gained popularity very rapidly and Tatu understood that SSH could become something much bigger. Consequently, he founded his company the same year, called SSH Communications Security, to develop and sell his service around SSH. Tatu Ylönen is still the [http://www.ssh.com/about/management CEO of the company].


SSH version 1 was relased and documented in 1995 but its problems also emerged as it was used by a steadily number of users. Meanwhile, a working group called SECSH at the IETF (Internet Engineering Task Force - https://www.ietf.org) started to work on the version 2. When the version was released in 1998, it was not widely adopted because its licensed was more restrictive than the first version: it is was not free for commercial use.  
SSH version 1 was released and documented in 1995 but its problems also emerged as it was used by a steadily number of users. Meanwhile, a working group called SECSH at the IETF ([https://www.ietf.org Internet Engineering Task Force]) started to work on the version 2. When this latter version came out in 1998, it was not widely adopted because its licensed was more restrictive than the first version: it is was not free for commercial use.


In the years 2000 however, the loosening of the license terms combined with the development of a fork of the first version under the OpenBSD license called OpenSSH, boosted its interest. As for today, the OpenSSH implementation is the most widely in the open-source world.  
In the years 2000 however, the loosening of the license terms combined with the development of a fork of the first version under the OpenBSD license called OpenSSH, boosted its interest. As for today, the OpenSSH implementation is the most widely in the open-source world.


http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch01_05.htm
==Concepts of SSH== 


http://www.jeffgeerling.com/blog/brief-history-ssh-and-remote-access
SSH is the acronym of "'''S'''ecure '''SH'''ell". It is a cryptographic protocol but also a program (or a set of utilities) that allows two computers to exchange encrypted messages over an unsecured network (like internet). This protocol is used to do many things: encrypt a connection (without authentication), authenticate a host, share files, remote terminal, SSH tunneling, etc. <ref>[http://www.howtogeek.com/114812/5-cool-things-you-can-do-with-an-ssh-server howtogeek.com] Cool things you can do with an SSH server</ref>


==The concepts of SSH==
===Why use SSH to access a remote host?===


SSH is the acronym of "'''S'''ecure '''SH'''ell". It is a cryptographic protocol but also a program (or a set of utilities) that allows two computers to exchange encrypted messages over an unsecured network (like internet). This protocol is used to do many things: encrypt a connexion (without authentication), authenticate a host, share files, remote terminal, SSH tunneling, etc.  
The main reason to use SSH is '''security''', because the data between the two hosts is encrypted. SSH has almost completely replaced Telnet and FTP protocols which transfer data in plain text. With Telnet or FTP, if somebody listens to someone else's traffic, it is extremely easy to get all the data, including the passwords.  


===Why to use an SSH connection to access a remote host?===
SSH has become a standard to establish a connection between two computers and a good practice regarding privacy and security standards.
 
The main reason to do all this via SSH is security, because the data between the two hosts is encrypted. SSH has almost completely replaced Telnet and FTP protocols which transfer data in plain text. With Telnet or FTP, if somebody listens to your traffic, it will be extremely easy to get all the data, including the passwords.
 
SSH has become a standard to establish a connexion between two computers and a good practice regarding privacy and security standards.  


===Types of encryption===
===Types of encryption===


To encrypt the data, it can use different types of encryption: DSA, RSA, RSA1, ECDSA and Ed25519. The type of encryption depends on some mathematical properties it uses to generate random keys which are really hard to guess using a reverse model of these mathematical properties. The type RSA1 is from the SSH protocol version 1 which is obsolete and should not be used. All others are part of SSH protocol version 2 but DSA should not be used because it has vulnerabilities found in 2015 [link].  
To encrypt the data, SSH can use different types of encryption: DSA, [http://searchsecurity.techtarget.com/definition/RSA RSA], RSA1, [https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ ECDSA] and [http://ed25519.cr.yp.to Ed25519]. The type of encryption depends on mathematical properties used to generate random keys which are extremely hard to reverse engineer. The type RSA1 is from the SSH protocol version 1 which is obsolete and should '''not''' be used. All others are part of SSH protocol version 2 but [http://searchsecurity.techtarget.com/definition/Digital-Signature-Standard DSA] should '''not''' be used because it has vulnerabilities.<ref>[http://thread.gmane.org/gmane.linux.debian.devel.announce/1220/focus=127931 Vulnerability of DSA algorithm 1]</ref> <ref>[https://plog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html Vulnerability of DSA algorithm 2]</ref>


From the remaining RSA, ECDSA and Ed25519, RSA is the most widely used although it not as efficient and "strong" as the other ones (in theory). The main advantage of ECDSA and Ed25519 is that they provide the same level of security than RSA but with shorter keys (256-bit key for ECDSA/Ed25519 is equivalent to 3000-bit RSA key) [link]. But RSA remains the most popular type because all SSH clients are compatible with it and until now, it has remained unbreakable. RSA, ECDSA and Ed25519 types are so far considered unbreakable.  
From the remaining RSA, ECDSA and Ed25519, RSA is the most widely used although it not as efficient and "strong" as the other ones (in theory). The main advantage of ECDSA and Ed25519 is that they provide the same level of security than RSA but with shorter keys (256-bit key for ECDSA/Ed25519 is equivalent to 3000-bit RSA key) <ref>[https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet blog.cloudflare.com] ECDSA vs RSA</ref>. But RSA remains the most popular type because all SSH clients are compatible with it and until now, it has remained unbreakable. RSA, ECDSA and Ed25519 types are all so far considered unbreakable.


===Private and public keys===
===Private and public keys===
Line 50: Line 46:
===Passphrase===
===Passphrase===


During the generating process, you will be asked to enter a '''passphrase'''. A passphrase is basically a password, but whereas a password is usually considered a single "word" (or string) of variable length, a passphrase is an arrangement of words separated by space. Passphrase is usually considered safer than passwords because it is usually longer than passwords. Its main advantage is that it is considered easier to remember. Read here how to choose a strong passphrase: http://windows.microsoft.com/en-us/windows7/tips-for-creating-strong-passwords-and-passphrases.  
During the generating process, you will be asked to enter a '''passphrase'''. A passphrase is basically a password, but whereas a password is usually considered a single "word" (or string) of variable length, a passphrase is an arrangement of words separated by space. Passphrase is usually considered safer than passwords because it is usually longer than passwords. Its main advantage is that it is considered easier to remember. [http://windows.microsoft.com/en-us/windows7/tips-for-creating-strong-passwords-and-passphrases More about choosing a strong passphrase].  


The passphrase is used to access the content of your private key. Although you can choose to not to enter a passphrase it is recommend since in case your private key gets stolen, the thief will need to first break your passphrase before he can use it: it will give you time to remove the public key from all the places you have put it, therefore the private key will become useless even if the passphrase is broken.  
The passphrase is used to access the content of your private key and to use it in general. Although you can choose to not to enter a passphrase it is recommend since in case your private key gets stolen, the thief will need to first break your passphrase before he can use it: it will give you time to remove the public key from all the places you have put it, therefore the private key will become useless even if the passphrase is broken. This is especially important if your key is stored on a non-private computer of a network (work, school, ...) because the root user can access it.


If you forget your passphrase, it cannot be retrieved. Should you be in this situation, you must generate new keys and replace your old public key by the new one in all the servers where you placed it.  
If you forget your passphrase, it cannot be retrieved. Should you be in this situation, you must generate new keys and replace your old public key by the new one in all the servers where you placed it.  
Line 58: Line 54:
===Authorized keys===
===Authorized keys===


Your public key must be placed on all servers that you want to access remotely. More specifically, your public key must be insert in a new line of the file ''~/.ssh/'''authorized_keys''''' located on the server. This file contains all the public keys of all the clients that are authorized to access the server via SSH. This is the reason why your private key must remain secret: anybody with your private key file can access all servers where your private key is written in the ''authorized_keys'' file. If your key gets stolen, you must remove the line where your key appears in this file on all servers where it is present.  
Your public key must be placed on all servers that you want to access remotely. More specifically, your public key must be insert in a new line of the file ''~/.ssh/'''authorized_keys''''' on the server. This file contains all the public keys of all the clients that are authorized to access the server via SSH. This is the reason why your private key must remain secret: anybody with your private key file can access all servers where your public key is written in the ''authorized_keys'' file. If your key gets stolen, you must remove the line where your key appears in this file on all servers where it is present.


===Known-host and key fingerprint/randomart===
===Known-host and key fingerprint/randomart===


SSH connexion is very safe, but it is vulnerable to a man-in-the-middle attack when you connect to a server the first time. When you access a server with SSH for the first time, the server will send you its public key (which is its identity), and you will see a message that looks like  
SSH connection is very safe, but it is vulnerable to a man-in-the-middle attack when you connect to a server the first time. When you access a server with SSH for the first time, the server will send you its public key (which is its identity), and you will see a message that looks like  
<pre>
<pre>
The authenticity of host 'mint.phcomp.co.uk (78.32.209.33)' can't be established.  
The authenticity of host 'enos.itcollege.ee (192.30.48.103)' can't be established.
RSA key fingerprint is 6a:de:e0:af:56:f8:0c:04:11:5b:ef:4d:49:ad:09:23.  
ECDSA key fingerprint is g5:0e:po:kl:tz:5r:gg:67:nq:90:ec:43:a4:w4:fd:99.
Are you sure you want to continue connecting (yes/no)?</pre>  
Are you sure you want to continue connecting (yes/no)?</pre>  


Instead of displaying the whole key (which is hard to read), the terminal shows you a more readable MD5 hash of it: this is the '''fingerprint'''. Both keys of an SSH pair (public and private) have the same fingerprint.  
Instead of displaying the whole key (which is hard to read), the terminal shows you a more readable MD5 hash of it: this is the '''fingerprint'''. Both keys of an SSH pair (public and private) have the same fingerprint.  


You then must make sure that this fingerprint is the one that you supposed to get: either you already know what the fingerprint should be, or you can know what it is yourself, or you must ask another person who knows it. If the fingerprint displayed on the terminal is the one expected, you can continue and type "yes". If it is not the one expected, you are probably trying to connect to a server that is fake, and you should deny connexion and contact the administrator or perform a security check.  
You then must make sure that this fingerprint is the one that you supposed to get: either you already know what the fingerprint should be, or you can know what it is yourself, or you must ask another person who knows it. If the fingerprint displayed on the terminal is the one expected, you can continue and type "yes". If it is not the one expected, you are probably trying to connect to a server that is fake, and you should deny connection and contact the administrator or perform a security check.  


Once you establish a connexion to a server for the first time with SSH, the server's public key information will be stored as a new line in the file "'''''known_hosts'''''" of the ''.ssh'' directory. Each line of this file correspond to a server which you have successfully connected before. When the server's public key you connect to is in this file, the connexion will be established without asking you to verify the server's identity once again: it is a known host already.  
Once you establish a connection to a server for the first time with SSH, the server's public key information will be stored as a new line in the file "''~/.ssh/'''known_hosts'''''" on the server. Each line of this file correspond to a server which you have successfully connected before. When the server's public key you connect to is in this file, the connection will be established without asking you to verify the server's identity once again: it is a known host already.  


If you still find the fingerprint hard to read, SSH provides the '''randomart''', which is a more visual representation of the fingerprint. It makes it easier and faster to compare keys.  
If you still find the fingerprint hard to read, SSH provides the '''randomart''', which is a more visual representation of the fingerprint. It makes it easier and faster to compare keys.


==SSH in practice==
==SSH in practice==


We are covering several study-cases which are the most common ones you may encounter. In all of them, it is assumed that SSH package is installed on your machine (comes by default on Ubuntu), and that the remote host (which we will call "server" from now on) has also enabled SSH remote access.  
Several study-cases which are the most common ones a user may encounter will be covered in this section. In all of them, it is assumed that SSH package is installed on your machine (comes by default on Ubuntu), and that the remote host (called "server" from now on) has also SSH remote access enabled.  
   
   
===Create/Generate SSH keys===
===Create/Generate SSH keys===
Line 88: Line 84:
<code>ssh-keygen</code>  
<code>ssh-keygen</code>  


Then you will be asked a path where to save the key. We suggest you save it in the default location by just hitting <code>Enter</code>.   
Then you will be asked a path where to save the key. It is suggested to save it in the default location by just hitting <code>Enter</code>.   
Then you will be asked to enter a passphrase, which we recommend to do, although it is not compulsory.
Then you will be asked to enter a passphrase, which is strongly recommended to do, although it is not compulsory.


That's all, your keys are generated! The whole process looks like this in your terminal:  
That's all, your keys are generated! The whole process looks like this in your terminal:  
Line 122: Line 118:


<code>-b</code> is to set the number of bits in the key to make it longer: For example <code>ssh-keygen –b 4096</code>   
<code>-b</code> is to set the number of bits in the key to make it longer: For example <code>ssh-keygen –b 4096</code>   
Making the key longer increases security but also slows down connexion as every packet has to be decrypted (high CPU usage). [https://certsimple.com/blog/measuring-ssl-rsa-keys].   
Making the key longer increases security but also slows down connection as every packet has to be decrypted (high CPU usage). [https://certsimple.com/blog/measuring-ssl-rsa-keys].   
For RSA, 2048 bits is considered sufficient. Maximum number of bits is 13384: [https://wiki.archlinux.org/index.php/SSH_keys]  
For RSA, 2048 bits is considered sufficient. Maximum number of bits is 13384: <ref name=archlinux>[https://wiki.archlinux.org/index.php/SSH_keys wiki.archlinux.org] A detailed article about SSH keys</ref>
For ECDSA type, three values are possible 256, 384 or 521 bits (an error is thrown otherwise).  
For ECDSA type, three values are possible 256, 384 or 521 bits (an error is thrown otherwise).  
The number of bits does not apply to Ed52219 type (always 256 bits).
The number of bits does not apply to Ed52219 type (always 256 bits).


<code>-C</code> is to set a comment for this key: for example <code>ssh-keygen –C "My personal laptop"</code>.  
<code>-C</code> is to set a comment for this key: for example <code>ssh-keygen –C "My personal laptop"</code>.  
Double quotes are required if you have space(s) in your comment.  
Double quotes are required if you use space(s) in your comment.  
This comment is placed at the end of your public key in plain text. It becomes very handy if you have several computer with different private keys on each of them. The comment can be used to identify to which it is linked to.  
This comment is placed at the end of your public key in plain text. It becomes very handy if you have several computer with different private keys on each of them. The comment can be used to identify to which it is linked to.  
For example suppose you have two computers with different private keys. You have put one of their public keys to your server but you do not remember which private key (computer) matches it. If you have a comment in your public key which identifies the client host which holds the corresponding private key, this is not a problem.  
For example suppose you have two computers with different private keys. You have put one of their public keys to your server but you do not remember which private key (computer) matches it. If you have a comment in your public key which identifies the client host which holds the corresponding private key, this is not a problem.  
In case you have not set a comment when generating your keys, you can add it later. Just open the public key file, add a space in the end of the key, and write your comment (spaces are allowed). Example: http://serverfault.com/questions/442933/add-comment-to-existing-ssh-public-key. Ultimately, you could write a different comment on each server where you place your public key.
In case you have not set a comment when generating your keys, you can add it later. Just open the public key file, add a space in the end of the key, and write your comment (spaces are allowed - [http://serverfault.com/questions/442933/add-comment-to-existing-ssh-public-key example]). Ultimately, you could write a different comment on each server where you place your public key.


Take a look at your keys in your ''.ssh'' folder.  
Take a look at your keys in your ''.ssh'' folder.


===Copy public key to server===
===Copy public key to server===


Now that you have generated your keys, you must place your public key inside your server. More precisely you must insert your public key inside the file ~/.ssh/authorized_keys on the server.  
Now that you have generated your keys, you must place your public key inside your server. More precisely you must insert your public key inside the ''~/.ssh/authorized_keys'' file  on the server.  


Here are two commands to achieve it:  
Here are two commands to achieve it:  
Line 160: Line 156:


If you cannot access the server's keys to get the fingerprint by yourself, you should ask someone who can.  
If you cannot access the server's keys to get the fingerprint by yourself, you should ask someone who can.  
===Change the passphrase===
To change the passphrase of your private key, you can use the wizard:
<code>ssh-keygen -p</code>
And you will go through the following steps:
<pre>
ssh-keygen -p
Enter file in which the key is (/home/user/.ssh/id_rsa):
Enter old passphrase:
Key has comment '/home/user/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase</pre>
Alternatively you can enter arguments to go faster. Note that all the arguments (-f, -P and -N) are optional. If they are omitted, you will be prompted for them.
Note also that all arguments that you will type will be displayed on the screen! It is usually not suggested to type clear passphrase/word on the screen, therefore this command is not recommended to use:
<code>ssh-keygen -p -P <currentPassphrase> -N <newPassphrase> -f <privateKeyPath></code>


===Manage keys===
===Manage keys===


Usually you create one pair of keys per computer you have. But you can create as many keys as you want if needed. To have several keys of the same type you can change their file name and/or file path. But SSH utility will look for the default key file names (''id_<keyType>'') in the default directory (''~/.ssh/'').  
Usually you create one pair of keys per computer you have. But you can create as many keys as you want if needed. To have several keys of the same type you can change their file name and/or file path. But SSH utility will look for the default key file names (''id_<keyType>'') in the default directory (''~/.ssh/'').  
To connect to a server using a non-default private key, we can specify its path:  
To connect to a server using a non-default private key, its path can be specified:  


<code>ssh -i <privateKeyPath> <user>@<hostname></code>
<code>ssh -i <privateKeyPath> <user>@<hostname></code>
You can also [https://www.freebsd.org/cgi/man.cgi?query=ssh_config&sektion=5 use a configuration file] but this is beyond the scope of this article.


===Delete keys===
===Delete keys===
Line 176: Line 196:
<code>ssh-keygen –R <hostname></code>
<code>ssh-keygen –R <hostname></code>


==References==
==Summary==


https://kb.iu.edu/d/aews
SSH is a must-know and a must-use protocol in nowadays information systems. It encrypts communications between two computers using encryption algorithms which are extremely hard to break. These encryption algorithms implement the concept of public and private keys to exchange data in a secure manner. Its free and open-source implementations make it widely used in the whole world and the main way to exchange data as a good security practice. SSH is present by default in Ubuntu and can be easily used on other platforms as well, either on CLI or GUI. It is very easy to use its basic features (see present article) while experienced users can use all the powerful features it also offers under the hood (see links below).


http://support.suso.com/supki/SSH_Tutorial_for_Windows
==See also==


http://security.stackexchange.com/questions/20706/what-is-the-difference-between-authorized-key-and-known-host-file-for-ssh
[http://www.jeffgeerling.com/blog/brief-history-ssh-and-remote-access jeffgeerling.com] Another brief history of SSH


https://help.ubuntu.com/community/SSH/OpenSSH/Keys
[http://searchsecurity.techtarget.com/definition/Secure-Shell searchsecurity.techtarget.com] Overview of SSH


http://man.openbsd.org/ssh.1
[https://help.ubuntu.com/community/SSH/OpenSSH/Keys help.ubuntu.com] Ubuntu tutorial of SSH


http://man.openbsd.org/OpenBSD-current/man1/ssh-keygen.1  
Unix manuals of [http://man.openbsd.org/ssh.1 ssh] and [http://man.openbsd.org/OpenBSD-current/man1/ssh-keygen.1 ssh-keygen]


http://www.howtogeek.com/114812/5-cool-things-you-can-do-with-an-ssh-server/
[https://kb.iu.edu/d/aews kb.iu.edu] Setting up SSH public-key authentication on Linux, Mac and Windows


https://wiki.archlinux.org/index.php/SSH_keys 
[http://support.suso.com/supki/SSH_Tutorial_for_Windows support.suso.com] Complete SSH tutorial for Windows


http://ed25519.cr.yp.to/
[http://support.suso.com/supki/SSH_Tutorial_for_Linux support.suso.com] Complete SSH tutorial for Linux


https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/
[http://security.stackexchange.com/questions/20706/what-is-the-difference-between-authorized-key-and-known-host-file-for-ssh stackexchange.com] Difference between ''authorized_keys'' and ''known_hosts'' files


http://www.howtogeek.com/114812/5-cool-things-you-can-do-with-an-ssh-server/
==References==
 
{{reflist|30em}}
https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2
 
http://6ftdan.com/allyourdev/2015/02/12/setting-up-remote-ssh-access-to-your-ubuntu-box/


http://searchsecurity.techtarget.com/definition/Secure-Shell
[[Category:Operatsioonisüsteemide administreerimine ja sidumine]]

Latest revision as of 19:46, 16 May 2016

Author: Etienne Barrier

Last modified: 01.05.2016

Background

This tutorial-like article is intended for beginner users who would like to learn about SSH cryptography protocol from scratch and/or get a deeper understanding of it.

It has been made using Linux Ubuntu 14.04 distribution, therefore it is not guaranteed that the information is relevant for other Linux distributions or for Windows or MAC.

It is assumed that you are already familiar with the basics of Linux command line terminal commands. The commands which are not directly related to SSH will not be explained.

SSH was built based on a client-server architecture and this article focuses only on the client side of SSH. See here for SSH on server side for Ubuntu.

For any comments to the author of this article, please send an email to etienne(dot}barrier{at]itcollege[dot)ee.

A bit of history

The SSH protocol was invested in 1995 by the Finnish Tatu Ylönen who was a researcher at the Helsinki University of Technology in Finland.[1] He decided to develop his own remote connection protocol after an attack performed against his university. He published the source code of his protocol and everyone could use it for free. SSH gained popularity very rapidly and Tatu understood that SSH could become something much bigger. Consequently, he founded his company the same year, called SSH Communications Security, to develop and sell his service around SSH. Tatu Ylönen is still the CEO of the company.

SSH version 1 was released and documented in 1995 but its problems also emerged as it was used by a steadily number of users. Meanwhile, a working group called SECSH at the IETF (Internet Engineering Task Force) started to work on the version 2. When this latter version came out in 1998, it was not widely adopted because its licensed was more restrictive than the first version: it is was not free for commercial use.

In the years 2000 however, the loosening of the license terms combined with the development of a fork of the first version under the OpenBSD license called OpenSSH, boosted its interest. As for today, the OpenSSH implementation is the most widely in the open-source world.

Concepts of SSH

SSH is the acronym of "Secure SHell". It is a cryptographic protocol but also a program (or a set of utilities) that allows two computers to exchange encrypted messages over an unsecured network (like internet). This protocol is used to do many things: encrypt a connection (without authentication), authenticate a host, share files, remote terminal, SSH tunneling, etc. [2]

Why use SSH to access a remote host?

The main reason to use SSH is security, because the data between the two hosts is encrypted. SSH has almost completely replaced Telnet and FTP protocols which transfer data in plain text. With Telnet or FTP, if somebody listens to someone else's traffic, it is extremely easy to get all the data, including the passwords.

SSH has become a standard to establish a connection between two computers and a good practice regarding privacy and security standards.

Types of encryption

To encrypt the data, SSH can use different types of encryption: DSA, RSA, RSA1, ECDSA and Ed25519. The type of encryption depends on mathematical properties used to generate random keys which are extremely hard to reverse engineer. The type RSA1 is from the SSH protocol version 1 which is obsolete and should not be used. All others are part of SSH protocol version 2 but DSA should not be used because it has vulnerabilities.[3] [4]

From the remaining RSA, ECDSA and Ed25519, RSA is the most widely used although it not as efficient and "strong" as the other ones (in theory). The main advantage of ECDSA and Ed25519 is that they provide the same level of security than RSA but with shorter keys (256-bit key for ECDSA/Ed25519 is equivalent to 3000-bit RSA key) [5]. But RSA remains the most popular type because all SSH clients are compatible with it and until now, it has remained unbreakable. RSA, ECDSA and Ed25519 types are all so far considered unbreakable.

Private and public keys

To perform its encryption, SSH will create 2 digital keys: a public key and a private key. The public key is not confidential, anybody can have it (thus the name "public"). On the contrary, your private key must remain secret and accessible only by you! Your public key is not secret because it must be stored in each server/computer/device you will want to access with your private key. Your private key is the only one that can match its public key, that is why they form a pair. The public key is like the same lock that you install on several doors. All those doors which have this (public) lock can be opened by you because you have the only (private) key that can open this lock.

The keys are by default stored in the hidden folder .ssh in the user's home directory. The private key will be a file named "id_rsa" and the public key a file named "id_rsa.pub". If you create keys of other types than RSA, they will be named id_<keyType> and id_<keyType>.pub (ie. id_ecdsa.pub).

Passphrase

During the generating process, you will be asked to enter a passphrase. A passphrase is basically a password, but whereas a password is usually considered a single "word" (or string) of variable length, a passphrase is an arrangement of words separated by space. Passphrase is usually considered safer than passwords because it is usually longer than passwords. Its main advantage is that it is considered easier to remember. More about choosing a strong passphrase.

The passphrase is used to access the content of your private key and to use it in general. Although you can choose to not to enter a passphrase it is recommend since in case your private key gets stolen, the thief will need to first break your passphrase before he can use it: it will give you time to remove the public key from all the places you have put it, therefore the private key will become useless even if the passphrase is broken. This is especially important if your key is stored on a non-private computer of a network (work, school, ...) because the root user can access it.

If you forget your passphrase, it cannot be retrieved. Should you be in this situation, you must generate new keys and replace your old public key by the new one in all the servers where you placed it.

Authorized keys

Your public key must be placed on all servers that you want to access remotely. More specifically, your public key must be insert in a new line of the file ~/.ssh/authorized_keys on the server. This file contains all the public keys of all the clients that are authorized to access the server via SSH. This is the reason why your private key must remain secret: anybody with your private key file can access all servers where your public key is written in the authorized_keys file. If your key gets stolen, you must remove the line where your key appears in this file on all servers where it is present.

Known-host and key fingerprint/randomart

SSH connection is very safe, but it is vulnerable to a man-in-the-middle attack when you connect to a server the first time. When you access a server with SSH for the first time, the server will send you its public key (which is its identity), and you will see a message that looks like

The authenticity of host 'enos.itcollege.ee (192.30.48.103)' can't be established.
ECDSA key fingerprint is g5:0e:po:kl:tz:5r:gg:67:nq:90:ec:43:a4:w4:fd:99.
Are you sure you want to continue connecting (yes/no)?

Instead of displaying the whole key (which is hard to read), the terminal shows you a more readable MD5 hash of it: this is the fingerprint. Both keys of an SSH pair (public and private) have the same fingerprint.

You then must make sure that this fingerprint is the one that you supposed to get: either you already know what the fingerprint should be, or you can know what it is yourself, or you must ask another person who knows it. If the fingerprint displayed on the terminal is the one expected, you can continue and type "yes". If it is not the one expected, you are probably trying to connect to a server that is fake, and you should deny connection and contact the administrator or perform a security check.

Once you establish a connection to a server for the first time with SSH, the server's public key information will be stored as a new line in the file "~/.ssh/known_hosts" on the server. Each line of this file correspond to a server which you have successfully connected before. When the server's public key you connect to is in this file, the connection will be established without asking you to verify the server's identity once again: it is a known host already.

If you still find the fingerprint hard to read, SSH provides the randomart, which is a more visual representation of the fingerprint. It makes it easier and faster to compare keys.

SSH in practice

Several study-cases which are the most common ones a user may encounter will be covered in this section. In all of them, it is assumed that SSH package is installed on your machine (comes by default on Ubuntu), and that the remote host (called "server" from now on) has also SSH remote access enabled.

Create/Generate SSH keys

To establish an SSH connection to a server, you must first generate your pair of public and private keys.

The simplest way to generate the keys is to use the following command which will by default create a set of 2048-bit size RSA keys:

ssh-keygen

Then you will be asked a path where to save the key. It is suggested to save it in the default location by just hitting Enter. Then you will be asked to enter a passphrase, which is strongly recommended to do, although it is not compulsory.

That's all, your keys are generated! The whole process looks like this in your terminal:

ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<username>/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase):  
Enter same passphrase again:  
Your identification has been saved in /home/<username>/.ssh/id_rsa. 
Your public key has been saved in /home/<username>/.ssh/id_rsa.pub. 
The key fingerprint is:
76:99:9d:fa:42:40:a2:65:59:ca:26:6f:4d:0c:04:e2 johndoe@johnPC
The key's randomart image is:
+--[ RSA 2048]----+
|  . .ooo.        |
| . . .=+.        |
|  E .++oo        |
|    .+ o.  + .   |
|      o S.+ o    |
|     . . ...     |
|         ..      |
|          ..     |
|           ..    |
+-----------------+

Please note the fingerprint and the randomart of your keys (see previous section).

There are many options you can add the the command. Here is a list of the most useful ones:

-t is to set up the type of encryption. For example ssh-keygen –t ecdsa

-b is to set the number of bits in the key to make it longer: For example ssh-keygen –b 4096 Making the key longer increases security but also slows down connection as every packet has to be decrypted (high CPU usage). [1]. For RSA, 2048 bits is considered sufficient. Maximum number of bits is 13384: [6] For ECDSA type, three values are possible 256, 384 or 521 bits (an error is thrown otherwise). The number of bits does not apply to Ed52219 type (always 256 bits).

-C is to set a comment for this key: for example ssh-keygen –C "My personal laptop". Double quotes are required if you use space(s) in your comment. This comment is placed at the end of your public key in plain text. It becomes very handy if you have several computer with different private keys on each of them. The comment can be used to identify to which it is linked to. For example suppose you have two computers with different private keys. You have put one of their public keys to your server but you do not remember which private key (computer) matches it. If you have a comment in your public key which identifies the client host which holds the corresponding private key, this is not a problem. In case you have not set a comment when generating your keys, you can add it later. Just open the public key file, add a space in the end of the key, and write your comment (spaces are allowed - example). Ultimately, you could write a different comment on each server where you place your public key.

Take a look at your keys in your .ssh folder.

Copy public key to server

Now that you have generated your keys, you must place your public key inside your server. More precisely you must insert your public key inside the ~/.ssh/authorized_keys file on the server.

Here are two commands to achieve it:

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'cat >> ~/.ssh/authorized_keys'

Or

ssh-copy-id <user>@<hostname>

Establish connection to the server

When you will connect to the server for the first time, you will be ask to check the fingerprint of the server's public key.

ssh <user>@<hostname>

example: ssh johndoe@enos.itcollege.ee

If you have access the public or private key of the server, you can get their fingerprint with this command:

ssh-keygen –lf <keyPath>

If you cannot access the server's keys to get the fingerprint by yourself, you should ask someone who can.

Change the passphrase

To change the passphrase of your private key, you can use the wizard:

ssh-keygen -p

And you will go through the following steps:

ssh-keygen -p
Enter file in which the key is (/home/user/.ssh/id_rsa): 
Enter old passphrase: 
Key has comment '/home/user/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved with the new passphrase

Alternatively you can enter arguments to go faster. Note that all the arguments (-f, -P and -N) are optional. If they are omitted, you will be prompted for them. Note also that all arguments that you will type will be displayed on the screen! It is usually not suggested to type clear passphrase/word on the screen, therefore this command is not recommended to use:

ssh-keygen -p -P <currentPassphrase> -N <newPassphrase> -f <privateKeyPath>

Manage keys

Usually you create one pair of keys per computer you have. But you can create as many keys as you want if needed. To have several keys of the same type you can change their file name and/or file path. But SSH utility will look for the default key file names (id_<keyType>) in the default directory (~/.ssh/). To connect to a server using a non-default private key, its path can be specified:

ssh -i <privateKeyPath> <user>@<hostname>

You can also use a configuration file but this is beyond the scope of this article.

Delete keys

To delete a set of keys, you can delete their files directly.

If you want to remove some servers from your "known_hosts" file, it is not possible to understand what they are by reading the content of the file. But you can remove a particular one with this command:

ssh-keygen –R <hostname>

Summary

SSH is a must-know and a must-use protocol in nowadays information systems. It encrypts communications between two computers using encryption algorithms which are extremely hard to break. These encryption algorithms implement the concept of public and private keys to exchange data in a secure manner. Its free and open-source implementations make it widely used in the whole world and the main way to exchange data as a good security practice. SSH is present by default in Ubuntu and can be easily used on other platforms as well, either on CLI or GUI. It is very easy to use its basic features (see present article) while experienced users can use all the powerful features it also offers under the hood (see links below).

See also

jeffgeerling.com Another brief history of SSH

searchsecurity.techtarget.com Overview of SSH

help.ubuntu.com Ubuntu tutorial of SSH

Unix manuals of ssh and ssh-keygen

kb.iu.edu Setting up SSH public-key authentication on Linux, Mac and Windows

support.suso.com Complete SSH tutorial for Windows

support.suso.com Complete SSH tutorial for Linux

stackexchange.com Difference between authorized_keys and known_hosts files

References

  1. docstore.mik.ua Short history of SSH
  2. howtogeek.com Cool things you can do with an SSH server
  3. Vulnerability of DSA algorithm 1
  4. Vulnerability of DSA algorithm 2
  5. blog.cloudflare.com ECDSA vs RSA
  6. wiki.archlinux.org A detailed article about SSH keys