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:
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:
Type ‘yes’ to be connected.
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.
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:
Below, we are copying a directory (-r) from the server to the local machine:
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:
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 !!!
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:
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:
You can check that it’s indeed the correct key (provided you are patient enough to check character by character ;-)):
For every connection to the remote machine, ssh will ask for the passphrase used to encrypt the private key:
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:
Note that, contrary to halting, rebooting the daemon prevents the users of the ssh server to be disconnected.
To change the parameters of this configuration file, we strongly encourage you to read the documentation
If you found this post or this website helpful and would like to support our work, please consider making a donation. Thank you!Help Us