Le système d'exploitation GNU-Linux/Le serveur de shell distant SSH
 |
Une proposition de fusion est en cours entre Administration réseau sous Linux/SSH et en:OpenSSH. Les avis sur cette proposition sont rassemblés dans une section de Wikilivres:Pages à fusionner. Les modifications majeures apportées, entre temps, aux pages doivent être commentées sur la même page.
|
À faire après la pose du bandeau
Vous venez d’apposer le modèle {{à fusionner}}, suivez ces étapes :
| 1. | Apposez le bandeau sur l’(les) autre(s) page(s) à fusionner. | Utilisez ce texte :
{{à fusionner|Administration réseau sous Linux/SSH|:en:OpenSSH}}
|
|---|---|---|
| 2. | Important : ajoutez une section dans Pages à fusionner en motivant votre proposition. | Utilisez ce texte :
== [[Administration réseau sous Linux/SSH]] et [[:en:OpenSSH]] == |
| 3. | Pensez à informer le(s) contributeur(s) principal(ux) de la page. | Utilisez ce texte :
{{subst:Avertissement fusion|Administration réseau sous Linux/SSH|:en:OpenSSH|7=~~~~}}
|
Le serveur SSH
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]Utilisation
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]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.
scp contient une faille que rsync n'a pas, où un serveur malicieux peut envoyer au client des fichiers non demandés[1].
Les clients SSH sous Windows
[modifier | modifier le wikicode]Il existe plusieurs clients SSH pour Windows, dont notamment les logiciels libres suivants :
- PuTTY[2] : fournit une liste de serveurs où se connecter en SSH uniquement.
- WinSCP[3] : client SSH, SFTP, FTP et SCP.
- Bitvise : n'affiche qu'un serveur SSH et SFTP pour chaque profil (nécessite de les charger depuis le système de fichier à chaque changement de serveur).
- MobaXterm : fournit une liste de sessions où se connecter en double-cliquant (en SSH et SFTP), mais problèmes fréquents pour copier-coller en console.
Problèmes connus
[modifier | modifier le wikicode]Le mot de passe est toujours demandé malgré la clé SSH
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]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]
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]Lancer :
eval `ssh-agent -s`
et réitérer.
Enter passphrase for key
[modifier | modifier le wikicode]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]
[modifier | modifier le wikicode]Se produit sur un serveur quand on essaie de se connecter automatiquement sans spécifier de clé privée.
Failed publickey for...
[modifier | modifier le wikicode]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
[modifier | modifier le wikicode]Regénérer les clés.
Permission denied (publickey,hostbased)
[modifier | modifier le wikicode]Il manque l'enregistrement de la clé publique (ssh -i).
Sinon, utiliser Putty.
Server refused our key
[modifier | modifier le wikicode]Vérifier les permissions, par exemple pour root :
ls -alh ~/.ssh total 24K drwxr--r-- 2 root root 4,0K mars 1 17:57 . drwxrwxr-x 25 root root 4,0K mars 6 12:41 .. -rw------- 1 root root 209 mars 1 17:57 authorized_keys -rw------- 1 root root 951 mars 1 17:57 id_rsa -rw-r--r-- 1 root root 397 mars 1 17:57 id_rsa.pub -rw-r--r-- 1 root root 869 mars 1 17:57 private.ppk
D'où :
chmod 700 ~/.ssh chmod 600 ~/.ssh/id_rsa
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 :
tail /var/log/auth.log
Si aucun log n'apparait lorsque le client reçoit l'erreur, passer en LogLevel DEBUG dans la configuration du serveur SSH :
vim /etc/ssh/sshd_config /etc/init.d/ssh restart
Cela permettra par exemple de savoir si l'erreur provient de authorized_keys.
WARNING: UNPROTECTED PRIVATE KEY FILE! / bad permissions / Permission denied (publickey)
[modifier | modifier le wikicode]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 chmod n'a aucun effet depuis Bash, même lancée en tant qu'administrateur. Et une modification des droits après suppression de l'ACL, 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
[modifier | modifier le wikicode]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