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]] == Votre motivation ici. ~~~~
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 de configuration réseau DHCP

Le partage de fichiers Samba

Le système d'exploitation GNU-Linux

Qu'est-ce qu'un système d'exploitation ?
Unix et Linux
Partitionnement du disque
Installation
1. Installer Debian via le réseau
Utilisateur Unix, l'interface console
Administration du système
Administration des services réseaux
Sécurisation d'un serveur Linux
1. Installation d'un service en mode chroot
2. Protection avec iptables
Erreurs connues
Médiagraphie
Auteurs

Version imprimable

[ Modifier le sommaire ]

Le serveur de configuration réseau DHCP

Le partage de fichiers Samba

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.

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

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

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 Putty.

Server refused our key

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)

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

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

Références

[1] ttps://lists.mindrot.org/pipermail/openssh-unix-dev/2019-March/037672.html

[2] ttp://www.putty.org/

[3] ttp://winscp.net

[1]

[2]

[3]