Le serveur SSH.
SSH (Secure SHELL) permet de se connecter à un ordinateur distant et de disposer d'un shell sécurisé. Par défaut, le serveur SSH attend les connexions distantes sur le port 22 / protocole TCP.
Pour installer un serveur SSH, on utilise la commande suivante :
 # apt-get install ssh
La connexion et le transfert de données via SSH est sécurisée par un système de chiffrement utilisant soit l'algorithme RSA (Rivest Shamir Adleman), soit l'algorithme DSA (Digital Signature Algorithm).
Lors de son installation, le serveur SSH génère des clés de chiffrement RSA et DSA. Ces clés sont composées d'une partie privée et d'une partie publique. Elles sont stockées dans le répertoire /etc/ssh/ :
 $ ls -l /etc/ssh/
 -rw------- 1 root root 672 2007-11-05 17:37 ssh_host_dsa_key
 -rw-r--r-- 1 root root 600 2007-11-05 17:37 ssh_host_dsa_key.pub
 -rw------- 1 root root 1675 2007-11-05 17:37 ssh_host_rsa_key
 -rw-r--r-- 1 root root 392 2007-11-05 17:37 ssh_host_rsa_key.pub
Chaque tentative de connexion est enregistrée dans le fichier /var/log/auth.log.
Fichier de configuration.
Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config :
 # cat /etc/ssh/sshd_config
 # Port de fonctionnement du serveur SSH
 Port 22
 # Permet de spécifier sur quelle interface SSH écoute
 #ListenAddress ::
 #ListenAddress 0.0.0.0
 # On utilise exclusivement la version 2 du protocole SSH
 Protocol 2
 # Emplacement des clés RSA et DSA
 HostKey /etc/ssh/ssh_host_rsa_key
 HostKey /etc/ssh/ssh_host_dsa_key
 # On active la séparation des privilèges
 UsePrivilegeSeparation yes
 # Durée de vie et taille de la clé
 KeyRegenerationInterval 3600
 ServerKeyBits 768
 # Pour syslog
 SyslogFacility AUTH
 LogLevel INFO
 # Authentification
 LoginGraceTime 120
 PermitRootLogin no
 StrictModes yes
 RSAAuthentication yes
 PubkeyAuthentication yes
 #AuthorizedKeysFile %h/.ssh/authorized_keys
 # Ignore les fichiers ~/.rhosts et ~/.shosts
 IgnoreRhosts yes
 # Ignore l'authentification RhostsRSA
 RhostsRSAAuthentication no
 # Même principe pour la version 2 du protocole
 HostbasedAuthentication no
 # À décommenter sur on ne veut pas se fier au fichier ~/.ssh/known_hosts pour RhostsRSAAuthentication
 #IgnoreUserKnownHosts yes
 # Empêche la connexion des utilisateurs qui n'ont pas de mot de passe (PAS RECOMMANDE)
 PermitEmptyPasswords no
 # Activer les mots de passes par Challenge / Réponse
 ChallengeResponseAuthentication no
 # Permet de supprimer l'authentification par mot de passe et n'utiliser que l'authentification par clé partagée
 #PasswordAuthentication yes
 # Options Kerberos
 #KerberosAuthentication no
 #KerberosGetAFSToken no
 #KerberosOrLocalPasswd yes
 #KerberosTicketCleanup yes
 # Options GSSAPI
 #GSSAPIAuthentication no
 #GSSAPICleanupCredentials yes
 # Activer la redirection X11
 X11Forwarding yes
 X11DisplayOffset 10
 # Afficher le message du jour (Message Of the Day)
 PrintMotd no
 # Afficher la date et heure de la dernière connexion
 PrintLastLog yes
 # Maintient la connexion TCP
 TCPKeepAlive yes
 #UseLogin no
 #MaxStartups 10:30:60
 #Banner /etc/issue.net
 # Permet à un client de passer des variables locales d'environnement
 AcceptEnv LANG LC_*
 Subsystem sftp /usr/lib/openssh/sftp-server
 # Utilise l'authentification via PAM
 UsePAM yes
Les options de ce fichier de configuration sont décrites dans la page de manuel de sshd_config :
 $ man sshd_config
Le fichier de configuration par défaut proposé par Debian nécessite quelques ajustements.
La ligne PermitRootLogin yes autorise les connexions distantes à partir du compte root. Cette option est dangereuse car elle permet à un attaquant distant de scanner le mot de passe du super-utilisateur root. 
La bonne pratique est de se connecter avec son compte utilisateur (ex: alex), et ensuite de passer root avec la commande su, ou d'effectuer les opérations d'administration avec la commande sudo.
On remplace donc cette ligne par : 
 PermitRootLogin no
Afin de renforcer la sécurité, on peut limiter les connexions SSH à une liste d'utilisateurs donnés. Ceci est réalisé avec l'option AllowUsers :
 AllowUsers alex pierre
Sur le même principe, on peut restreindre les connexions à un ou plusieurs groupes Unix : 
 AllowGroups admin sshusers
Afin que ces modifications soient prises en compte, il faut relancer le serveur SSH :
 # /etc/init.d/ssh restart
Le client SSH.
Utilisation.
Pour se connecter à un serveur SSH, on utilise la commande ssh. Sa syntaxe est la suivante :
 $ ssh <login>@<nom ou adresse IP du serveur>
Exemple :
 $ ssh alex@pc210
ou
 $ ssh pc210 -l alex
Si on possède le même login sur la machine locale et distante, il est inutile de spécifier le login :
 $ ssh pc210
Si ssh ne fonctionne pas sur le port standard 22, l'option -p permet d'indiquer le port à utiliser :
 $ ssh pc210 -p 2222
L'option -X du client SSH permet de rediriger l'affichage graphique (le DISPLAY) via le tunnel SSH, et ainsi lancer un programme graphique distant et l'afficher sur notre ordinateur :
 $ ssh -X pc210
 pc210$ xeyes &
Il faut toutefois que l'option X11Forwarding soit positionnée à yes sur le serveur pour que la redirection graphique fonctionne.
Vérification du fingerprint.
Lors de la première connexion, ssh affiche le fingerprint du serveur SSH et demande confirmation :
 $ ssh pc210
 The authenticity of host 'pc210 (192.168.30.210)' can't be established.
 RSA key fingerprint is 8e:c6:f0:b5:e6:71:c9:20:ec:5d:ed:d4:e1:fc:fb:16.
 Are you sure you want to continue connecting (yes/no)?
Si on veut être certain de l'authenticité du serveur distant, on peut contacter l'administrateur et vérifier avec lui que le "fingerprint" indiqué est le bon. Pour faire ceci, taper la commande ssh-keygen -l sur le serveur ssh et indiquer le chemin vers la clé RSA du serveur ssh :
 # ssh-keygen -lv
 Enter file in which the key is (/root/.ssh/id_rsa): /etc/ssh/ssh_host_rsa_key
 2048 8e:c6:f0:b5:e6:71:c9:20:ec:5d:ed:d4:e1:fc:fb:16 /etc/ssh/ssh_host_rsa_key.pub
 +--[ RSA 2048]----+
 | |
 | oEo |
 | . S.o |
 |o. . + +o=. |
 |=.+ E..+o |
 |oo . . oo. |
 | . o.. |
Par la suite, le fichier /home/<user>/.ssh/known_hosts stoque l'identité chiffrée de la machine et ssh ne nous demande plus confirmation.
Authentification automatique.
Si on se connecte souvent sur le même serveur, on peut générer une paire de clés afin de ne pas avoir à saisir le mot de passe à chaque connexion.
Sur la machine cliente
On génére une paire de clés avec la commande ssh-keygen :
 $ ssh-keygen -t rsa
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/alex/.ssh/id_rsa):
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:
 Your identification has been saved in /home/alex/.ssh/id_rsa.
 Your public key has been saved in /home/alex/.ssh/id_rsa.pub.
 The key fingerprint is:
 41:ab:25:09:eb:ad:41:66:2d:d6:85:e3:73:02:40:e3 alex@pc210
On ne saisi pas de passphrase, sinon le système va demander à saisir la passphrase à chaque connexion, ce qui est aussi contraignant que la saisie du mot de passe.
Sur la machine distante
On se connecte sur la machine distante et on copie le contenu de la clé publique précédement générée (/home/alex/.ssh/id_rsa.pub) dans le fichier /home/alex/.ssh/authorized_keys.
 ssh-copy-id -i /home/alex/.ssh/id_rsa.pub alex@192.168.30.190
Note: Si on ne dispose pas de la commande ssh-copy-id (anciennes versions de ssh), on peut utiliser la commande suivante :
 cat ~/.ssh/id_rsa.pub | ssh alex@192.168.30.190 "cat - » ~/.ssh/authorized_keys"
Ceci fait, on peut se connecter sur la machine distante sans avoir à saisir le mot de passe.
La commande scp.
La commande scp (Secure Copy) permet de copier un fichier d'un ordinateur vers un autre en utilisant SSH.
Par exemple, la commande suivante permet de copier le fichier fichier.txt vers le répertoire /tmp de l'ordinateur pc211 :
 $ scp fichier.txt alex@pc211:/tmp
On peut également copier un fichier distant sur la machine locale :
 $ scp alex@pc211:/etc/passwd /tmp
L'option -r permet de copier un répertoire de manière récursive.
Les clients SSH sous Windows.
Il existe plusieurs clients SSH pour Windows, dont notamment les logiciels libres suivants :
Problèmes connus.
Le mot de passe est toujours demandé malgré la clé SSH.
Quand on teste la clé SSH depuis le client :
 $ ssh -i .ssh/id_rsa <login>@<serveur>
si les logs d'authentification du serveur acceptent la clé :
 $ tail /var/log/auth.log
cela donne :
 Accepted publickey for root from xxxx port yyyy ssh2: RSA SHA256:zzzz
ou :
 Found matching RSA key:zzzz
au lieu de :
 Accepted password for root from xxxx port yyyy ssh2
Il faut donc réinstaller les clés.
Authentication refused: bad ownership or modes for directory.
Il faut s'approprier le dossier : 
 chown MonUtilisateur MonDossier
Could not create directory '/c/UsersUtilisateur/.ssh' ... Failed to add the host to the list of known hosts.
Se produit sous Windows quand le chemin défini n'est pas celui retenu par SSH. Par exemple, quand :
 $ setx HOME %USERPROFILE%
ou
 $ setx HOME "C:/Users/Utilisateur/"
ou
 $ setx HOME "C:\\Users\\Utilisateur\\"
donnent tous :
 $ echo $HOME
 /c/UsersUtilisateur
Peu importe la casse.
On peut aussi utiliser "CMD" au lieu de "Bash" pour modifier la variable d'environnement "home", ce qui aboutit à un résultat équivalent :
 > setx HOME %USERPROFILE%
 > set home
 home=C:\Users\Utilisateur
 HOMEDRIVE=C:
 HOMEPATH=\Users\Utilisateur
Attention : sous "Git CMD" cela ne fonctionne pas, il faut vraiment utiliser la console DOS du système :
 > set home
 home=c:UsersUtilisateur
 HOMEDRIVE=C:
 HOMEPATH=\Users\Utilisateur
Mais surtout il faut utiliser "CMD" pour mettre à jour le contenu du dossier .ssh sans obtenir cette erreur, par exemple en installant OpenSSH for Windows :
 >"C:\Program Files (x86)\OpenSSH\bin\ssh.exe" depot.example.com
 RSA key fingerprint is zzzz
 Are you sure you want to continue connecting (yes/no)? yes
 Warning: Permanently added 'depot.example.com' (RSA) to the list of known hosts.
Connection closed by authenticating user user 172.19.0.1 port 55920 [preauth].
Regarder les logs du client SSH. S'il n'en n'a pas, utiliser à la place :
 ssh -vvv -i my_key.ppk user@172.19.0.1 -p 2223
Cela dira si le format de la clé est invalide ou autre.
Could not open a connection to your authentication agent.
Lancer :
 eval `ssh-agent -s`
et réitérer.
Enter passphrase for key.
Il faut ajouter la clé privée depuis le serveur avec :
 ssh-add ~/.ssh/id_rsa
Sinon, spécifier la clé privée depuis le client :
 ssh -i .ssh/id_rsa <login>@<serveur>
Sinon, voir #Permission denied (publickey,hostbased).
error: Received disconnect from x.x.x.x port yyyyy:13: Unable to authenticate [preauth].
Se produit sur un serveur quand on essaie de se connecter automatiquement sans spécifier de clé privée.
Failed publickey for....
La clé envoyée par le client ne correspond pas à la clé publique indiquée dans /etc/ssh/sshd_config (ou elle n'est peut-être pas dans ~/.ssh/authorized_keys).
Load key "my_key.ppk": error in libcrypto.
Regénérer les clés.
Permission denied (publickey,hostbased).
Il manque l'enregistrement de la clé publique (ssh -i).
Sinon, utiliser .
Server refused our key.
Vérifier les permissions, par exemple pour root :
D'où :
Cela peut aussi être lié à la non prise en charge par le serveur de l'en-tête et du pied de la clé publique. Dans ce cas, retirer les deux lignes :
 ---- BEGIN SSH2 PUBLIC KEY ----
 ---- END SSH2 PUBLIC KEY ----
Si le problème persiste, la cause est détaillée dans :
Si aucun log n'apparait lorsque le client reçoit l'erreur, passer en codice_1 dans la configuration du serveur SSH : 
Cela permettra par exemple de savoir si l'erreur provient de authorized_keys.
WARNING: UNPROTECTED PRIVATE KEY FILE! / bad permissions / Permission denied (publickey).
 Permissions 0644 for '/cygdrive/c/Users/Utilisateur/.ssh/id_rsa' are too open.
 It is recommended that your private key files are NOT accessible by others.
 This private key will be ignored.bad permissions: ignore key: /cygdrive/c/Users/Utilisateur/.ssh/id_rsa
Sous Linux il est facile d'appliquer les permissions sur la clé :
 chmod 700 ~/.ssh
 chmod 600 ~/.ssh/id_rsa
NB : sous Windows par contre, la commande codice_2 n'a aucun effet depuis Bash, même lancée en tant qu'administrateur. Et une modification des droits après suppression de l', via Cygwin ou l'explorateur Windows fonctionne chez eux, mais n'a guère plus d'effet pour SSH :
 $ setfacl -b ~\.ssh
 $ setfacl -b ~\.ssh\id_rsa
 $ chgrp -R Utilisateurs ~\.ssh
 $ chmod -Rv 600 ~\.ssh\id_rsa
 mode of ‘C:\\Users\\Utilisateur\\.ssh\\id_rsa’ changed from 0644 (rw-r--r--) to 0600 (rw-------)
 $ ls -alh ~\.ssh\id_rsa
 -rw-r--r-- 1 Utilisateur 1049089 843 sept. 19 2011 C:\Users\Utilisateur\.ssh\id_rsa
we did not send a packet, disable method.
Cette erreur du client SSH peut venir d'un authorized_keys mal rempli :
chown -Rf user:1000 /home/user/.ssh
su user
cd /home/user/.ssh
cat id_rsa.pub > authorized_keys
ssh -i id_rsa.ppk localhost