Un blog de geek

Utilisation de SSH

Billet posté le 18 déc. 2016

Se connecter à un serveur c’est vieux comme le monde !

Et oui c’est un besoin qui existe depuis de nombres années. Nous pouvons citer quelques programmes :

  • telnet est crée en 1969 (fonctionne sur le port 23/TCP) ;
  • rsh est crée en 1983 (port 514/TCP) ;
  • rlogin est crée en 1991 (port 513/TCP).

Bref, comme on peut le voir dès 1969 on était capable de se connecter à d’autres serveurs. Le problème me direz-vous ? Il est bien simple : ces programmes ont pour principales faiblesses d’avoir les informations qui circulent en clair sur le réseau. On imagine aisémenent une personne sniffant le réseau et être capable de récupérer des informations sensibles telles que : nom d’utilisateur, mot de passe ainsi que les opérations effectuées sur le serveur. Très peu pour moi. On pourra par exemple consulter cet article à propos de telnet.

L’arrivée de SSH

Dans ce contexte et avec une utilisation toujours exponentielle du nain ternet il devient primordial de pouvoir se connecter à des serveurs de manière sécurisée. Ainsi, en 1995 sort la première version de SSH créée par Tatu Ylönen (Finlande), puis devient une entreprise qui elle-même à son tour est rachetée par F-Secure. Il en ressort qu’en parallèle il y a un véritable besoin de continuer à se connecter à des serveurs et surtout que SSH est bien pratique. C’est tout naturellement qu’en 1999 l’équipe OpenBSD sort OpenSSH. L’histoire du projet OpenSSH est disponible ici https://www.openssh.com/history.html.

La première version d’OpenSSH reprend la dernière version libre du SSH originel (version 1.2.12).

En terme de numéro de port c’est le 22 qui est utilisé et le protocole est TCP.

Le RFC sur SSH est disponible ici : https://tools.ietf.org/html/rfc4253.

A l’heure où j’écris ces quelques lignes la dernière version d’OpenSSH est disponible pour les systèmes suivants on peut se référer à cette page pour savoir qui utilise OpenSSH.

La syntaxe de la commande ssh

ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D
[bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I
pkcs11] [-i identity_file] [-J [user@]host[:port]] [-L address]
         [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p
port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w
local_tun[:remote_tun]] [user@]hostname [command]

Et en vrai ?

Quelques exemples de base pour se connecter à un serveur distant : 

ssh monutilisateur@monserveur
ssh −l monutilisateur monserveur
ssh monutilisateur@monserver -p autreport

On peut aussi exécuter une commande via ssh : 

ssh monutilisateur@monserver date

Et il apparaît alors la sortie de la commande date sur la sortie standard.

Copier des fichiers à travers ssh

On utilisera la commande scp qui permet de copier des fichiers d’une source à une destination. Quelques exemples :

scp monutilisateur@monserveur:/chemin/fichier /tmp
scp /tmp/monfichier montuilisateur@monserveur:/chemin/fichier

Il est à noter qu’on peut aussi utiliser la commande sftp qui veut dire Secure File Transfert Protocol. Qu’est-ce donc ? C’est un protocole de communication fonctionnant au-dessus de SSH pour transférer des fichiers à distance. Le programme sftp est une implémentation de ce protocole.

Exemple d’utilisation de sftp : 

sftp monutilisateur@monserveur
Connected to monserveur.
sftp> ls
toto.pdf
sftp> get toto.pdf
Fetching /home/hindy/toto.pdf to toto.pdf
/home/hindy/toto.pdf
100%  464KB 463.4KB/s   00:01
sftp> put mybook.epub
Uploading mybook.epub to /home/hindy/mybook.epub
mybook.epub
100% 4238    26.7KB/s   00:00
sftp> quit

Pour ma part j’utilise assez peu la commande sftp et je lui préfère la commande lftp. Pourquoi ? La complétion dans les commandes ainsi que la possibilité d’envoyer ou de télécharger des dossiers et sous dossiers facilement (help mirror).

Les redirections de ports

Le besoin est le suivant : vous devez atteindre le port TCP d’une application qui est derrière un firewall et non ouvert sur le grand ternet. Vous disposez d’un accès SSH au serveur de ce fait vous allez pouvoir rediriger les ports via la commande ssh. Comment ?

Nous utiliserons la commande suivante qui permet d’atteindre le port 7071 du serveur distant qui à la base est firewallé : 

ssh -L 7071:localhost:7071 monutilisateur@monserveur

Vous pouvez alors utiliser votre navigateur sur https://localhost:7071. Sur votre poste de travail il se passe quelque chose intéressant : 

netstat −lt | grep 7071
tcp 0 0 localhost:7071 ∗:∗ LISTEN

Concrètement voici ce qu’il se passe vous avez crée un tunnel ssh sur le port 7071 en local ainsi que sur le port distant. Dès que localement vous vous adressez au port 7071 les paquets sont automatiquement redirigés vers le serveur sur le port 7071.

Échange de clés

Vous vous connectez en permanence sur des serveurs ssh et vous en avez marre de taper votre mot de passe. Cela se comprend. Il est possible de gagner un peu de temps. La solution passe par l’utilisation d’une clé publique / privée. Nous allons voir comment mettre ceci en place.

Nous allons en réalité générer une paire de clé :

  • privée ;
  • publique.

La clé privée elle est à conserver très précieusement et à ne jamais divulguer à un tiers !

La clé publique est à envoyer sur le serveur distant.

toto@orion:~$ ssh-keygen -o -a 100 -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/toto/.ssh/id_ed25519):
Created directory '/home/toto/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/toto/.ssh/id_ed25519.
Your public key has been saved in /home/toto/.ssh/id_ed25519.pub.
The key fingerprint is:
02:ff:fb:99:a9:24:fa:a2:b7:35:03:f2:1f:ee:d9:bd toto@orion
The key's randomart image is:
+--[ED25519  256--+
|                 |
|                 |
|    .            |
|     o           |
|  . . o S        |
|   o . o         |
|    . * o        |
|    o= O o +     |
|  .oo=* +oE.     |
+-----------------+
toto@orion:~$

Deux fichiers ont été générés avec le type de clé ed25519 :

  • /home/toto/.ssh/id_ed25519 qui est la clé privée ;
  • /home/toto/.ssh/id_ed25519.pub qui est la clé publique.

Notons une chose importante : nous avons mis un mot de passe quand ssh-keygen nous a demandé un passphrase. Qu’est-ce que cela veut dire ? Le but n’était pas de se connecter à distance sans saisir son mot de passe ? Si, c’est bien le cas. Nous y revenons dans peu.

Maintenant nous allons copier via la commande ssh-copy-id la clé publique sur le serveur distant : 

toto@orion:~$ ssh-copy-id -i /home/toto/.ssh/id_ed25519.pub utilisateur@serveur
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to
filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you
are prompted now it is to install the new keys
utilisateur@serveur's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'utilsateur@serveur'"
and check to make sure that only the key(s) you wanted were added.

toto@orion:~$

La commande ssh-copy-id a pris votre clé publique et l’a envoyée sur le serveur distant dans le fichier $HOME/.ssh/authorized_keys en y mettant les permissions à 600. Il faut aussi s’assurer que le répertoire $HOME/.ssh possède bien les droits à 700. Enfin, la clé privée qui restera toujours sur votre poste de travail doit être en *chmod 600.

Cas du ssh agent

Un mot de passe a été créée pour protéger la clé privée et donc à chaque fois que l’on se connecte sur le serveur distant nous devrons taper ce mot de passe. Il existe une solution via l’utilisation de ssh-add et ssh-agent.

ssh-add
Identity added: /home/toto/.ssh/id_ed25519.pub (/home/toto/.ssh/id_ed25519)
ssh-agent
SSH_AUTH_SOCK=/var/folders/xf/q7m6df851_s7kb_b1zpmdt9w0000gn/T//ssh-NyZhr4Ij5o7s/agent.2265;
export SSH_AUTH_SOCK;
SSH_AGENT_PID=2266; export SSH_AGENT_PID;
echo Agent pid 2266;

Et maintenant lorsque vous vous connectez en ssh vers le serveur distant le mot de passe ne vous sera pas demandé car il est chargé en mémoire via ssh-agent.

Configuration du client ssh

Tous les jours vous devez taper la commande suivante : 

ssh -i $HOME/.ssh/ma-cle-priv user@serveur -p 4242

C’est quelque peu long, on peut envisager de créer un alias shell après tout :

alias serveur="ssh -i $HOME/.ssh/ma-cle-priv monuser@serveur.tld -p 4242"

On peut faire mieux en utilisant le fichier de configuration du client ssh. C’est le fichier $HOME/.ssh/config que nous utiliserons de la manière suivante : 

Host serveur
	HostName serveur.tld
	User monuser
	Port 4242
	IdentityFile $HOME/.ssh/ma-cle-priv

Et nous pourrons alors tout simplement ssh serveur : plutôt pratique non ?

On peut aussi mettre en place les redirections :

Host zimbra-admin
  HostName zimbra.tld
  Port 22
  User monutilisateur
  LocalForward 7071 localhost:7071

Et à ce moment là je fais ssh zimbra-admin et mon navigateur est lancé sur https://localhost:7071/.

Et les serveurs avec rebond ?

Habituellement on réalise les opérations suivantes : 

ssh user@rebond
ssh user@serveur_destination

On enchaine donc commandes ssh. On peut alors utiliser le $HOME/.ssh/config de la manière suivante : 

Host serveur_destination
	HostName serveur_destination.tld
	User monuser
	ProxyCommand ssh monuser@rebond nc %h %p

Il devient alors possible de faire ceci qui permet de se connecter au serveur de destination : 

ssh serveur_destination

Note : assurez-vous de bien avoir la commande nc d’installée.

Configuration du serveur ssh

Nous pouvons regarder aussi la configuration côté serveur. C’est le daemon sshd qui entre en jeu. Le fichier de configuration est /etc/ssh/sshd_config.

Par exemple nous allons interdire le fait de se logger en root ainsi que d’utiliser le X11Forwarding :

PermitRootLogin no
X11Forwarding no

Si vous souhaitez changer le port d’écoute qui est par défaut le port 22 afin que cela soit le port 4242 :

Port 4242

N’autoriser que certains utilisateurs :

AllowUsers utilisateur1 utilisateur2 utilisateur3

Debuger du ssh

N’oubliez pas que quand vous faîtes une modification du le serveur ssh il faut bien entendu redémarrer le service et si vous rencontrez des soucis avec le client vous pouvez toujours passer l’option -v afin d’obtenir un peu de verbose.

Conclusion

Nous avons survolé l’utilisation de ssh. En effet, nous n’avons pas abordé les notions telles que : proxy socks, les différents ciphers à utililser, certaines options du client ssh (cf -o). Bref, je vous invite à consulter la documentation officielle ainsi que les moteurs de recherche.