SSH: Secure SHell
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:22Type ‘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:00Below, 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:002.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 public 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.pubIn 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@ipowerhtYou 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@ipowerhtFor 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:~$systemctl restart sshdNote that, contrary to halting, rebooting the daemon prevents the users of the ssh server to be disconnected.
nadir@ipower:~$systemctl stop sshdTo change the parameters of this configuration file, we strongly encourage you to read the documentation
nadir@ipower:~$man sshdIf you found this post or this website helpful and would like to support our work, please consider making a donation. Thank you!
Help Us