Math-Linux.com

Knowledge base dedicated to Linux and applied mathematics.

Home > Linux > Network > SSH: Secure SHell

SSH: Secure SHell

All the versions of this article: [English] [français]

We shall present here the SSH (Secure SHell) protocol. The main commands will be explained as well as how to use the private/public keys to be authenticated. We shall first start with the guest profile (your machine) then we shall see the sever profile remote machine). We assume that the server (remote machine) has the sshd (ssh server).

1. General facts

1.1 What is SSH ?

SSH, as its name suggests, is a Secure SHell which enables you to connect to a remote machine in a network. The network could a local one or located in London, Madrid or New York ! Furthermore, this protocol allows you to launch applications on the remote machine, make and receive transfers with the server, all in a secure way. SSH allows to establish a secured communication channel and be authenticated with the remote server by means of a pair of keys.

1.2 Why use SSH ?

The traditional commands such as rcp, rlogin, telnet are vulnerable. It is pretty easy to "snoop" a local network and find logins and passwords. Bear in mind that logins and passwords are not hidden when sent in the network. It only takes an evil-minded person to listen to your ports and analyze the circulating packets. Try for instance the EtherReal utilitary, and you will realize what we are talking about ! SSH is much more secure. Data are encrypted, so it’s a pain in the neck for evil-minded folks! This being said, be careful !!! Your password is encrypted during the connection, so are the data circulating between the server and the guest.

1.3 A few notations

- The local machine will be referred to as ipowerht, with and IP address set to 10.0.0.3.
- The remote server will be referred to as ipower with and IP address set to 10.0.0.4.
- my login (connection ID) will be nadir.

2. SSH for the guest

2.1 Establishing the connection

To be connected to an ssh server, we shall use the following command:

ssh login@remote_server

We should remind you that we are the guest now: the the IP is 10.0.0.3 and the machine is ipowerht. We can check that:

nadir@ipowerht:~ $ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0C:6E:4D:3F:2A
         inet adr:10.0.0.3  Bcast:10.0.0.255  Mask:255.255.255.0
         adr inet6: fe80::20c:6eff:fe4d:3f2a/64 Scope:Lien
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:12462 errors:0 dropped:0 overruns:0 frame:0
         TX packets:11916 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:1000
         RX bytes:6283113 (5.9 MiB)  TX bytes:1396161 (1.3 MiB)
         Interruption:22

Type ’yes’ to be connected.

nadir@ipowerht:~ $ ssh nadir@10.0.0.4
The authenticity of host '10.0.0.4 (10.0.0.4)' can't be established.
RSA key fingerprint is c2:72:14:de:97:a3:68:e6:80:96:e5:f6:03:6d:ab:b0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.4' (RSA) to the list of known hosts.
nadir@10.0.0.4's password:
Linux ipower 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 GNU/Linux

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
You have new mail.
Last login: Mon Oct 31 12:32:04 2005
nadir@ipower:~$

We now connected to the remote server ipower, the IP of which is 10.0.0.4.

A few details are necessary here: you must answer yes to be connected. Doing so authorizes a public key to be saved in a file, known_hosts, located in the .ssh subdirectory of your home directory.

nadir@ipowerht:~ $ cat ~/.ssh/known_hosts
|1|0Oe37usFY/ObV2ZushNUYkaCJHw=|hUK+rpChGZkayH3B5DtafHoggwQ= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtb+INGggM1ISDOrKTBc0bp3wa7HZOzaAjgi8TJEt
VQyg4cB1ege3C+2WiOdUDoKBDxBdgKaWesEIwx4g+LTY1YzwB6bb2JHU487WJx5YRDRF
yfKYICLJLg2n++vQWW/Bw8fwpcjCfhjV591WyDzHtb9lPkX45qFcWWtgJvJGxOc=

2.2 File transfer via scp

To transfer files in a secure way, we use the scp command as follows:

scp source destination

If it’s a directory transfer, we use -r

scp -r source destination

We use the classic notation of directories for a guest machine, whereas for a remote server we use
login@remote_server:(Do NOT put a blank space after the ’:’). Let’s see a few examples. We are copying a file from the guest to the server:

nadir@ipowerht:~ $ scp Desktop/sources.list nadir@10.0.0.4:Desktop
nadir@10.0.0.4's password:
sources.list                                  100% 1686     1.7KB/s   00:00

Below, we are copying a directory (-r) from the server to the local machine:

nadir@ipowerht:~ $ scp -r nadir@10.0.0.4:simula+ Desktop/
nadir@10.0.0.4's password:
Root                                          100%   29     0.0KB/s   00:00
Repository                                    100%    8     0.0KB/s   00:00
Entries                                       100%   43     0.0KB/s   00:00
test.cpp                                      100%  181     0.2KB/s   00:00

2.3 File transfer via sftp

Instead of using the classic ftp, we shall use the ’sftp’ command. Do not blame anybody but yourself if some folks find your password when you use the classic ftp. The syntax is as follows:

sftp login@remore_server

In practice:

nadir@ipowerht:~ $ sftp nadir@10.0.0.4
Connecting to 10.0.0.4...
nadir@10.0.0.4's password:
sftp>

2.4 Key authentication

We have previously seen that the authentication on the server was done via a login and a password. We shall now see that the authentication can be done by means of asymmetrical cryptography and a pair of private/public keys.

What is exactly a strong authentication ?
- for and foremost, it is an RSA/DSA type encryption
- each user has two keys: a private and a public one
- to be authenticated, the private part should be on the server and the private one on on the guest.
- instead of entering your login and password, you will only need to enter a "passphrase", which is a password that authorizes sentences. NEVER EVER LEAVE THE PASSPHRASE EMPTY !!!. Why? Simply because, if someone steals your public key, you are in the dog house since you left the passphrase empty.

To generate a pair of keys, we use the following command:

ssh-keygen -t rsa

You have the choice between dsa, rsa and rsa1. Let’s see an example of how to generate public and private keys with the dsa encryption. By default, press ’Enter’ on your keyboard for the name of files, but not for the passphrase. I repeat: NEVER EVER LEAVE THE PASSPHRASE EMPTY !!!

nadir@ipowerht:~ $ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/nadir/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nadir/.ssh/id_dsa.
Your public key has been saved in /home/nadir/.ssh/id_dsa.pub.
The key fingerprint is:
99:02:09:26:f7:18:1d:9d:85:93:d8:3f:12:2a:0e:52 nadir@ipowerht
nadir@ipowerht:~ $ ls -al .ssh
total 16
drwx------   2 nadir nadir 4096 2005-11-01 20:28 .
drwxr-xr-x  41 nadir nadir 4096 2005-11-01 19:16 ..
-rw-------   1 nadir nadir  736 2005-11-01 20:28 id_dsa
-rw-r--r--   1 nadir nadir  604 2005-11-01 20:28 id_dsa.pub

In the user’s directory, the .ssh subdirectory contains the public key id_dsa.pub and the private key id_dsa. Note the permission on the private key id_dsa:

-rw------- 1 nadir nadir 736 2005-11-01 20:28 id_dsa

It is of type 600, ie. rw for the user, whereas the others have no permission. Why? Simply because others should not know your private key ...

Transferring the public key on remote servers

To transfer the public key on remote servers, we use the following command:

ssh-copy-id -i path_to_the_public_key login@remote_server

Practically, we have:

nadir@ipowerht:~ $ ssh-copy-id -i ~/.ssh/id_dsa.pub nadir@10.0.0.4
27
The authenticity of host '10.0.0.4 (10.0.0.4)' can't be established.
RSA key fingerprint is c2:72:14:de:97:a3:68:e6:80:96:e5:f6:03:6d:ab:b0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.4' (RSA) to the list of known hosts.
nadir@10.0.0.4's password:
Now try logging into the machine, with "ssh 'nadir@10.0.0.4'", and check in:

 .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

See that you have a message asking you to connect to the remote server and check the file .ssh/authorized_keys. Com’on, be patient! Enter the passphrase:

nadir@ipowerht:~ $ ssh nadir@10.0.0.4
Enter passphrase for key '/home/nadir/.ssh/id_dsa':
Linux ipower 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 GNU/Linux

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
You have new mail.
Last login: Tue Nov  1 22:42:00 2005 from ipowerht.lan
nadir@ipower:~$ cat .ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAACBANIk54Df106UVD4Op/bHSOFWvyWl+P5GfkaOJV
j5i+MOO2fs1GD3SivhpZ6UbWfV2VhpidGg+DgqLg9817Isj7GexCrIQ269TgNSvLRb
rD3fA3JkD8zXOlBwn0UhFXURZkUJ9+ghT/JQPUXoKLhb+SN6kQxH8XAh7yPH5+hsug
YRAAAAFQCQtWe+/XfqCmkQO9iAtnJqlNED7wAAAIBUXoNpRZKBNi6CXeSNCzMS6jjC
0yuaLEUetwDGYT0w1aI8rVNiCrohcPiPba/vKgrgO/F+uSBsU2RsNLL8TLHfZvl+2c
e4U6m2o6APzwZFCyRXlgZWvPmsZZqnx1qKwRLkjSOq5ufIfMBXed2RWprwYINq8W7U
a0NYbjVkdD8G7AAAAIEAutDMfZeURchN88dHVuLA5uSR5dE+y2Gk2OmZx2ZjxM7adB
Zi1dKJQ85h6NrnqrgrgNhA0yWDhOBkIWNp24S9jwXS9dCHlnRO+yeaR2faXZbOGjeV
CtEfcdjc5GLSR2heFqBDQntiNnwmNoYzV9kqu1SzylbmdIAHNWJarjxo9xw= nadir@ipowerht

You can check that it’s indeed the correct key (provided you are patient enough to check character by character ;-)):

nadir@ipower:~$ exit
logout
Connection to 10.0.0.4 closed.
nadir@ipowerht:~ $ cat ~/.ssh/id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBANIk54Df106UVD4Op/bHSOFWvyWl+P5GfkaOJV
j5i+MOO2fs1GD3SivhpZ6UbWfV2VhpidGg+DgqLg9817Isj7GexCrIQ269TgNSvLRb
rD3fA3JkD8zXOlBwn0UhFXURZkUJ9+ghT/JQPUXoKLhb+SN6kQxH8XAh7yPH5+hsug
YRAAAAFQCQtWe+/XfqCmkQO9iAtnJqlNED7wAAAIBUXoNpRZKBNi6CXeSNCzMS6jjC
0yuaLEUetwDGYT0w1aI8rVNiCrohcPiPba/vKgrgO/F+uSBsU2RsNLL8TLHfZvl+2c
e4U6m2o6APzwZFCyRXlgZWvPmsZZqnx1qKwRLkjSOq5ufIfMBXed2RWprwYINq8W7U
a0NYbjVkdD8G7AAAAIEAutDMfZeURchN88dHVuLA5uSR5dE+y2Gk2OmZx2ZjxM7adB
Zi1dKJQ85h6NrnqrgrgNhA0yWDhOBkIWNp24S9jwXS9dCHlnRO+yeaR2faXZbOGjeV
CtEfcdjc5GLSR2heFqBDQntiNnwmNoYzV9kqu1SzylbmdIAHNWJarjxo9xw= nadir@ipowerht

For every connection to the remote machine, ssh will ask for the passphrase used to encrypt the private key:

nadir@ipowerht:~ $ ssh nadir@10.0.0.4
Enter passphrase for key '/home/nadir/.ssh/id_dsa':

3. SSH for the server

The file /etc/ssh/sshd_config allows to configure the ssh server. It manages the parameters of connections. Any modification of this file requires a reboot of the sshd daemon as follows:

nadir@ipower:~$/etc/init.d/sshd restart

Note that, contrary to halting, rebooting the daemon prevents the users of the ssh server to be disconnected.

nadir@ipower:~$/etc/init.d/sshd stop

To change the parameters of this configuration file, we strongly encourage you to read the documentation

nadir@ipower:~$man sshd

Any message or comments?

comments powered by Disqus