OpenSSh

De Wiki info-lab.fr
Aller à : Navigation, rechercher

Sommaire

Présentation

OpenSSh (Secure Shell) SSh sur Wikipedia est un programme de type client-serveur s'appuyant sur le protocole du même nom. SSh ( RFC 4251 ) permet de créer une connexion sécurisée entre un client et un serveur au dessus de TCP ( par défaut sur le port 22).
Une connexion SSh sert par nature à se connecter à un terminal distant sur la machine hébergeant le serveur SSh, mais par extension permet aussi de faire du transfert de fichiers ou d'encapsuler n'importe quel autre protocole (y compris un affichage déporté) qui bénéficiera alors de la sécurité apportée par SSh. OpenSSh est un ensemble d'outils de sécurité sous licence BSD s'appuyant sur le protocole SSH. Ces outils sont :

  • ssh le client de connexion remplaçant rlogin, rsh, rexec et telnet.
  • sshd le démon serveur SSH.
  • scp le client de transfert de fichiers remplaçant rcp.
  • sftp le client de transfert de fichiers remplaçant ftp.
  • ssh-keygen programme de génération, gestion et conversion des clés.
  • ssh-agent et ssh-add utilitaires facilitant l'authentification par clé publique, gérant entre autres l'accès au fichier known_hosts.
  • ssh-keyscan et ssh-argv0 divers utilitaires nécessaires pour une bonne utilisation de SSH.
  • ssh-copy-id utilitaire servant uniquement à déposer sa clé publique sur un serveur distant.

Versions

OpenSSH est en version 7.1 depuis août 2015, entièrement compatible avec le version 2.0 du protocole SSH.

Fonctionnalités

OpenSSH 7.1 possède les caractéristiques suivantes :

  • Compatibilité avec le protocole SSH en versions 1.3, 1.5 et 2.0
  • Licence libre type BSD
  • Utilisation des algorithmes de chiffrement 3DES, blowfish, Arcfour ou AES.
  • Encapsulation d'autres protocoles (port forwarding ou X11 forwarding).
  • Transfert de fichiers grâce à SCP ou SFTP.
  • Compression des données avant chiffrement.
  • Agent d'authentification qui gère les clés de l'utilisateur.
  • Authentification possible par mot de passe, clé publique RSA ou DSA, jeton Kerberos, ou mot de passe à usage unique (OTP).

Installation

Le client SSH est en général présent sur toute distribution Gnu-Linux ( /usr/bin/ssh ). L'installation du serveur se déroule de la manière suivante sur une distribution Debian/Ubuntu :

# apt-get install openssh-server

Plusieurs paires de clés RSA et DSA sont générées à l'installation, le plus souvent stockées dans /etc/ssh/. Un script lance généralement le serveur à l'issue de son installation et l'ajoute automatiquement dans la liste des services lancés au démarrage (rc.d). Sur certaines distributions la modification de rc.d n'est pas automatique et doit être réalisée par un utilisateur ROOT.

  • ssh_host_dsa_key est la clé privée et ssh_host_dsa_key.pub sa clé publique (.pub) de type DSA utilisées pour l'authentification. Ne plus utiliser DSA : supprimer la paire de clés et commenter la ligne correspondante dans /etc/ssh/sshd_config (voir ci-dessous).
  • ssh_host_ecdsa_key est la clé privée et ssh_host_ecdsa_key.pub sa clé publique (.pub) de type DSA mettant en oeuvre la cryptographie sur les coubes elliptiques utilisées pour l'authentification.
  • ssh_host_rsa_key est la clé privée et ssh_host_rsa_key.pub sa clé publique (.pub) de type RSA utilisées pour l'authentification.

Configuration du serveur sshd

Le fichier /etc/ssh/sshd_config définit le comportement par défaut du serveur sshd. Les options suivantes sont dignes d'attention :

Port   22              port tcp en écoute
Protocol   2           ssh v2
PermitRootLogin   no     root n'a pas d'accès ssh
HostKey /etc/ssh/ssh_host_dsa_key       ligne désignant la paire de clés DSA, à supprimer ou désactiver en la transformant en #HostKey /etc/ssh/ssh_host_dsa_key
PermitEmptyPasswords   no         les comptes n'ayant pas de mot de passe n'ont pas d'accès ssh
AllowUsers        liste des utilisateurs ou utilisateur@machine autorisés (séparés par des espaces, * et ? autorisés)
AllowGroups       liste des groupes autorisés (séparés par des espaces, * et ? autorisés)
LoginGraceTime  60   temps en secondes pour tuer une ouverture de session SSh si aucune authentification n'aboutit
AllowTcpForwarding   yes   autorise l'encapsulation d'autres protocoles dans ssh
X11Forwarding   yes   affichage distant dans ssh, nécessite d'avoir un serveur graphique en local
PrintLastLog yes   affiche l'horodatage de la dernière connexion SSh réussie
Subsystem sftp /usr/lib/openssh/sftp-server   autorise le sftp en pointant vers l'exécutable correspondant
(sftp peut nécessiter un chroot pour plus de sécurité)
PubkeyAuthentication yes    pour autoriser l'authentification par clé
AuthorizedKeysFile      .ssh/authorized_keys  le chemin par défaut des clés publiques connues

Autres options : DenyUsers et DenyGroups, l'inverse de AllowUsers et AllowGroups. Hostkey pour choisir le chemin vers la clé privée. PubkeyAuthentication pour autoriser l'authentification par clés publiques. AuthorizedKeysFile pointe vers le fichier contenant ces clés publiques. PrintMotd permet d'afficher le contenu de /etc/motd à la connexion. Banner pour l'envoi d'un message avant authentification.

Ne pas oublier de rafraîchir la configuration du serveur sshd après modification de ce fichier.

# service ssh reload

et depuis que SYSTEMD à remplacé INIT :

# systemctl reload sshd.service

Modifier le passphrase de la clé privée DSA (fonctionne aussi pour RSA et ECDSA)

$ ssh-keygen -p -f /etc/ssh/ssh_host_dsa_key
Enter old passphrase:
Enter new passphrase (empty for no passphrase) :
Enter same passphrase again :
$

Utilisation du client ssh

Voici quelques exemples d'utilisation du client SSH :

$ ssh login@serveur01                    (serveur01 peut être identifié par un nom DNS ou une adresse IP)
$ ssh -p 5930 login@serveur01            (connexion sur le port TCP 5930, sinon 22 est le port par défaut)
$ ssh -1 -c DES login@serveur01          (SSHv1 et chiffrement DES pour connexion à un serveur non compatible SSHv2)

Dans ces 3 cas, un utilisateur nommé login doit exister sur la machine exécutant le serveur sshd et la connexion nécessite de saisir le mot de passe associé à cet utilisateur.

$ ssh login@serveur01
The authenticity of host 'serveur01 (82.66.233.215)' can't be established.
ECDSA key fingerprint is 39:6d:b1:29:e1:39:2f:3c:ec:87:f8:6f:1d:b8 
Are you sure you want to continue connecting (yes/no)?

Lors de chaque première connexion à un serveur SSH celui-ci va soumettre sa clé publique au client SSh qui ne la connait pas. ssh-keyscan va calculer un condensat (empreinte) de cette clé, vous demander si vous acceptez cette clé, et si oui l'enregistrera dans votre liste de clés publiques connues (par défaut le fichier ~/.ssh/known_hosts). Avant d'accepter vous devez comparer cette empreinte à celle que devrait vous avoir communiqué un administrateur du serveur distant. Sans comparaison possible, l'acceptation de cette empreinte expose à l'attaque de l'homme du milieu.
Pour calculer l'empreinte de la clé publique sur le serveur :

$ ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub       
256 39:6d:b1:29:e1:39:2f:3c:ec:87:f8:6f:1d:b8  root@serveur01 (ECDSA)           {format des anciennes versions d'OpenSSH}
256 SHA256:kHOLqhrmszcG4pQkzTbbrq7bUBaMK8ChrwFz99ROexQ root@serveur01 (ECDSA)       {format des nouvelles versions d'OpenSSH}

Cette comparaison d'empreinte est réalisée automatiquement par ssh-keyscan à chaque connexion. Si ssh-keyscan détecte que l'empreinte de clé soumise ne correspond pas à celle qui est enregistrée dans votre fichier ~/.ssh/known_hosts, c'est que :

  • Un individu malveillant essaie de s'intercaler dans la tentative de connexion par la technique de l'attaque de l'homme du milieu. Il faut absolument refuser l'établissement de la connexion.
  • Un administrateur du serveur SSH a généré de nouvelles paires de clés DSA, ECDSA, ou RSA. A condition d'avoir reçu les nouveaux condensats de clés qui correspondent à ceux soumis lors de la tentative de connexion, et après avoir effacé les anciens condensats dans le fichier ~/.ssh/known_hosts, vous pouvez accepter la connexion. ssh-keyscan enregistrera la nouvelle clé publique du serveur SSH.

Profils de connexions

Le fichier /etc/ssh/ssh_config définit le comportement par défaut du client ssh.
Il est possible de personnaliser ses différentes connexions vers des serveurs différents en éditant (ou créant) le fichier ~/.ssh/config pour y créer des profils de connexion différents.

$ vim .ssh/config
Host serveurAlpha
 Hostname serveur.domaine.com
 CheckHostIP no
 ForwardX11 yes
 Port 22
 User marcel
Host serveurBravo  
 Hostname serveur-bis.domaine.com
 CheckHostIP no
 Port 8022
 User louis
:wq
$ ssh serveurBravo

Connexion SSH par clé publique

Pour se connecter sur un serveur distant en utilisant une clé publique à la place d'un mot de passe, il faut effectuer 3 opérations :

  • 1) Générer une paire de clés RSA, DSA ou ECDSA du côté du client SSH :
$ ssh-keygen -t ecdsa -b 384 -f .ssh/nom-clef -C clef-serveur01
Generating public/private ecdsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in nom-clef.
Your public key has been saved in nom-clef.pub.
The key fingerprint is:
55:c7:f0:a9:af:84:44:de:17:1a:34:bc:69:d3:4c:11 clef-serveur01
The key's randomart image is:
+--[ECDSA  384]---+
|       .E+..     |
|       .*..      |
|        o +      |
|        =*o+     |
|       .S.* .    |
|         = + .   |
|          . =    |
|           = .   |
|            .o.  |
+-----------------+
$

Création d'un clé privée de type ecdsa, de longueur 384 bits dont le nom sera nom-clef (la clé publique appairée se nommera nom-clef.pub) et ajout d'un commentaire (clef-serveur01). La génération peut être plus ou moins longue en fonction de la longueur choisie pour la clé et de la puissance CPU disponible. Cette paire de clés sera stockée par défaut dans $HOME/.ssh/, avec les permissions 600 pour la clé privée et 644 pour la clé publique. Une option du serveur SSh activée permet d'envoyer la randomart image au client à chaque tentative de connexion. Précisions : Les randomarts, qui sont des empreintes graphiques de clés sous forme de dessin dans un cadre sont difficiles à comparer entre elles . De plus, le manque de complexité des caractères dessinés laissant présager un nombre de collisions (deux fois la même empreinte pour des clés différentes) non négligeable, fragilisent la confiance que l'on pourrait leur accorder.
Il est possible de ne pas saisir de passphrase pour protéger l'utilisation de la clé privée, mais sauf dans quelques cas bien particuliers il est préférable de ne pas utiliser cette possibilité.

  • 2) Copier la clé publique ainsi générée (nom-clef.pub) sur le serveur distant dans le répertoire du compte utilisé pour se connecter :
$ scp ~/.ssh/nom-clef.pub login@serveur01:/home/login/           (envoi de la clé publique dans le répertoire de "login")
nom-clef.pub                                           100%  217     0.2KB/s   00:00
$ ssh login@serveur01          (dernière connexion au serveur en utilisant le mot de passe de l'utilisateur login)
cat nom-clef.pub >> .ssh/authorized_keys        (contenu du ficher copié dans le fichier authorized_keys)
logout
$

Cette opération peut être réalisée au moyen de l'utilitaire ssh-copy-id prévu pour cela :

ssh-copy-id -i ~/.ssh/nom-clef.pub login@serveur01
password: 

ssh-copy-id ajoute automatiquement l'extension .pub si le fichier source ne le possède pas
Nota : L'utilitaire ssh-copy-id fonctionne normalement avec les clés RSA et ne semble pas identifier correctement les clés DSA et ECDSA.

  • 3) S'authentifier en désignant la clé privée locale appairée à la clé publique installé sur le serveur distant :
$ ssh -i ~/.ssh/nom-clef login@serveur01       (on spécifie la clé privée utilisée)
Enter passphrase for key '.ssh/nom-clef':               (il faut saisir la passphrase protégeant la clé privée et non plus le mot de passe de l'utilisateur login)

L'utilisation des clés fonctionne aussi pour le transfert de fichiers par SCP et SFTP.

Autres fonctionnalités de SSH

Transfert de fichier SCP

Récupération du fichier photo.jpg présent sur un serveur distant (qui doit exécuter un serveur SSh) vers le répertoire courant local :

scp login@serveur-ssh:~/images/photo.jpg .

Envoi d'un fichier local vers un répertoire sur une machine distante

scp /srv/data/truc.jpg login@serveur-ssh:~/images

L'utilisation de clés est bien sûr possible :

scp -i .ssh/nom-clef login@serveur-ssh:~/images/photo.jpg .

Transfert de fichier SFTP

Récupération du fichier photo.jpg présent sur un serveur distant vers le répertoire courant local (syntaxe équivalente à SCP) :

sftp login@serveur-ssh:~/images/photo.jpg .

Envoi d'un fichier local vers un répertoire sur une machine distante

sftp /srv/data/truc.jpg login@serveur-ssh:~/images

L'utilisation de clés est bien sûr possible :

sftp -i .ssh/nom-clef login@serveur-ssh:~/images/photo.jpg .

Affichage déporté encapsulé dans SSh

L'option X11Forwarding du fichier /etc/ssh/sshd_config doit être positionnée sur yes pour pouvoir activer cette fonctionnalité.

toto@machine:~$ ssh -X login@server01
login@server01:~$ export DISPLAY=:10.0  optionnel ; il peut être nécessaire de rediriger X11 vers l'affichage distant
login@server01:~$ geany

Exécution distante de l'éditeur de texte geany mais affichage en local.

Encapsulation de protocole non sécurisé

Pour protéger un protocole de communication ne disposant pas de mécanismes de sécurité intrinsèques, il est possible de l'encapsuler dans SSh.
Pour cela il faut créer un fichier nommé config dans .ssh et l'éditer pour renseigner un profil de connexion par protocole à encapsuler. Le fichier .ssh/config sera interprété en priorité par rapport à /etc/ssh/ssh_config.

  • Exemple d'encapsulation : VNC (Condition : Un serveur VNC doit être installé sur la machine distante)
$ vim.tiny .ssh/config
Host secuVNC
     Hostname 82.66.233.254
     CheckHostIp no
     Port 22
     LocalForward 5900 127.0.0.1:5900
     Compression yes
:wq
$ ssh secuVNC
$ vncviewer localhost

Redirection de ports

L'encapsulation de protocole vue ci-dessus peut servir aussi pour traverser un équipement filtrant autorisant SSh et protégeant une ressource interne normalement inaccessible.
Exemple : Je veux accéder au site baseclients.societe.com:80, hébergé sur serveur01 à travers un parefeu interdisant l'accès à ce site depuis l'extérieur mais autorisant ma connexion SSh :

$ ssh -L 8080:baseclients.societe.com:80 login@serveur01
password : .............

En local je lance un navigateur avec saisie de l'URL suivante : http://localhost:8000 pour profiter de l'encapsulation du http à travers la connexion SSh lui permettant de traverser l'équipement filtrant.
Cette redirection de port peut être mise en place après la connexion au serveur SSh :

$ ssh login@serveur01
login@serveur01:~$ ~C
> -L 8080:baseclients.societe.com:80
login@serveur01:~$
Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Outils