Ceci est une ancienne révision du document !
SSH
La façon la plus pratique de se connecter à un serveur pour l'administrer est de passer par ssh (sous linux ; sous les autres OS je vous laisse chercher). Il est possible de passer par des logiciels tiers (tel qu'Ansible) mais la connexion elle-même utilise le protocole SSH.
Cet article a plusieurs objectifs :
- Configurer SSH sur son ordinateur personnel afin de se connecter à ses serveurs de façon sécurisée et confortable
- Configurer SSH sur les serveurs administrés afin d'atteindre un niveau de sécurité aussi haut que possible1).
Configurer SSH sur son ordinateur personnel
Pour se connecter à un serveur, on peut s'authentifier avec un mot de passe, ou bien avec une authentificatuon par clé SSH. Le mot de passe n'est pas sécurisé : une attaque par dictionnaire permet de le trouver, en particulier sur l'utilisateur “root”. C'est pourquoi il est nécessaire de générer une clé SSH.
Générer une clé a un autre avantage : vous n'aurez plus qu'un mot de passe à retenir pour vous connecter de nombreux serveurs, celui qui déverouille la clé elle-même.
Générer une clé
Ouvrez une console et générez une paire de clefs :
ssh-keygen -t rsa -b 4096
Ou
ssh-keygen -t ecdsa -b 521
Vous devriez avoir le texte suivant qui s'affiche :
Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub.
Si vous n'entrez rien pour le fichier où sauver la clef (donc tapez sur “entrée”), cela laissera dans le répertoire par défaut, c'est à dire /home/user/.ssh/id_rsa
, ce qui est très bien.
Pour la “passphrase”, trouvez un mot de passe efficace.
Une clef publique/privée est générée, spécifiquement pour les connexions ssh, en utilisant l’algorithme RSA dans la première commande ou ECDSA dans la seconde.
L'ajout du paramètre -b (chiffre)
permet de fixer la taille de la clé, augmentant sa sécurité.
RSA ou ECDSA ?
Il existe différents protocoles pour générer une clé, en suivant la syntaxe ssh-keygen -t type
, type
étant à remplacer par dsa
, rsa
, ecdsa
.
- DSA n'est plus accepté partout, c'est vraiment ancien.
- ECDSA est théoriquement accepté partout à présent et son empreinte est moins longue, donc plus rapide à contrôler, c'est le dernier arrivé.
- Enfin, RSA est la référence, acceptée sur tous les serveurs.
Y'a-t-il vraiment un avantage entre RSA et ECDSA ? Les débats sont nombreux. Ce qui en ressort, c'est que dans la majorité des cas… l'un ou l'autre peuvent être utilisé indifférement.
Le fichier /home/user/.ssh/config
Ce fichier permet de personnaliser ses accès à ssh de façon extrêmement pratique.
Alias ssh
Pour se connecter à un serveur, il faut taper une commande de la forme suivante :
ssh user@ip:port/chemin_des_dossiers
Il en est de même pour les divers logiciels utilisants la connexion SSH. Il est possible de faire un alias, dans la configuration de ssh, qui va associer un nom à l'ensemble des paramètres, ce qui transforme la commande de façon bien plus courte.
Il faut alors créer un fichier config
dans son répertoire .ssh
dans son /home. Il contiendra pour chaque serveur un identifiant, son nom (ou adresse IP directe), le fichier rsa à utiliser et l'identifiant qui y est lié :
Voici ce qu'il faut mettre dans le fichier /home/user/.ssh/config
host serveur1 HostName serveur1.fr IdentityFile ~/.ssh/cle1 User totor Port 2369 host serveur2 HostName 202.127.12.13 IdentityFile ~/.ssh/cle1 User roxxor
host
est suivi du “raccourci” que vous souhaitez associer aux paramètresHostName
indique l'adresse du serveur ; cela peut être une adresse ip, un nom de domaine ou même un des noms renseigné dans votre fichier/etc/hosts
.IdentityFile
indique la clé ssh associée à ce serveur (voir le chapitre suivant pour plus de détails).User
indique l'utilisateur avec lequel se connecter au serveur.Port
permet d'indiquer le port sur lequel se connecter si ce n'est pas celui par défaut.
Ici, la commande ssh serveur1
vous connectera à “serveur1.fr” avec l'utilisateur “totor” et la clé “cle1” (celle par défaut), via le port 2369. Les trois commandes ci-dessous sont équivalentes :
ssh serveur1 ssh totor@serveur1.fr:2369 ssh -p 2369 totor@serveur1.fr:2369
Et si on veut une clef par site ?
Il est possible d'indiquer automatiquement à SSH d'utiliser telle ou telle clef selon le site auquel on se connecte.
Cela n'a généralement aucun intérêt : la même clé peut vous permettre de vous connectez sur tous les serveurs que vous souhaitez. Les clés asymétriques ne sont pas comme les mots de passe ; la sécurité n'augmente pas en utilisant une différente à chaque endroit, d'autant que ce qui est envoyé est la clé publique qui par définition peut être publique sans rien comprommettre.
Cependant, c'est parfois une manipulation nécessaire. Par exemple, il fut un temps où Bitbucket ne supportait pas ECDSA, il fallait donc une clé RSA pour ce service et quelques autres serveurs en retard.
Imaginons qu'on ait généré deux clefs RSA comme indiqué au-dessus. Il suffit d'indiquer pour cela un autre nom à la question “Enter file in which to save the key (/home/user/.ssh/id_rsa)” : /home/user/.ssh/cle1
et /home/user/.ssh/cle2
. On a donc décidé d'utiliser les clefs comme suit:
- cle1 pour aller sur le serveur 1
- cle2 pour aller sur le serveur 2
- config
host serveur1 HostName serveur1.fr IdentityFile ~/.ssh/cle1 User totor host serveur2 HostName 202.127.12.13 IdentityFile ~/.ssh/cle2 User roxxor
Ensuite quand on se connectera avec SSH, le système saura que pour aller sur serveur1.fr, il faut qu'il utilise la clef ~/.ssh/cle1 et l'identifiant totor. Il ne restera qu'à entrer la passphrase qui y est liée. Il n'y a plus besoin de donner la clef nécessaire ou l'identifiant.
Se connecter à un serveur avec sa clé
Copier la clef publique sur le compte du serveur distant
ssh-copy-id -i ~/.ssh/id_rsa.pub yyy@xxxxx.org
ou
ssh-copy-id -i ~/.ssh/id_rsa.pub alias_ssh
Remplacez yyy@xxxxx.org
par le nom de votre serveur et son utilisateur, par exemple root@monserveur.org
. Ceci dit, si vous avez paramétré correctement votre fichier /home/user/.ssh/config
, la seconde commande fonctionne très bien, en remplaçant “alias_ssh” par l'un des “hosts” renseigné dans ce fichier.
Si vous avez généré une clé avec autre chose que RSA, ou lui avez donné un autre nom, modifiez bien le chemin ~/.ssh/id_rsa.pub
.
Entrez le mot de passe du serveur lorsqu'il vous est demandé (donc pas votre passphrase de clef, il faut d’abord que le serveur sache que c’est bien vous !).
Et maintenant, c’est bon, vous pouvez vous connecter au serveur en ssh avec votre clef :
ssh yyy@xxxxx.org
ou
ssh user@monserveur.org
ou encore
ssh alias_ssh
Sur le serveur, allez dans le dossier .ssh de /home/user et faites
more authorized_keys
Une ligne doit se terminer par votre nom d’utilisateur et le nom de votre machine, il s’agit des clefs publiques autorisées à se connecter.
Se connecter sans retaper trop souvent son mot de passe (méthode sécurisée) : l'agent ssh
Il suffit d'utiliser un “agent ssh” qui va se souvenir de votre clé. En théorie, votre mot de passe ne devrait être demandé qu'une fois par session, la première fois que vous déverrouillez la clé.
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa
Vous devrez retaper cette commande à chaque redémarrage de votre session, avant de vous connecter en ssh pour la première fois lors de la session.
Pour vous simplifier la vie, vous pouvez créer un petit alias (dans /home/user/.aliases si vous utilisez bashrc et que vous avez bien activé cette option) :
alias mykey='eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_rsa'
Il n'y aura plus qu'à taper mykey
dans votre console lors de votre première connexion ssh de la journée et ce sera déverouillé pour la session.
Se connecter sans mot de passe (méthode non sécurisée)
Se connecter sans mot de passe ouvre potentiellement une faille de sécurité. À réserver à des cas très particuliers !
NE SURTOUT PAS LE FAIRE PAR DÉFAUT OU PAR FLEMME !
Un de ces cas est la possibilité pour un serveur A de se connecter à un serveur B, pour effectuer une sauvegarde des données par exemple. Le serveur A doit lui-même être bien protégé.
Il suffit de créer une clé sur le serveur A, comme indiqué plus haut (ssh-keygen -t rsa -b 4096
) mais de ne pas rentrer de mot de passe. Cette clé pourra donc être utilisée pour se connecter sans mot de passe.
Ensuite on ajoute cette clé sur le serveur B (ssh-copy-id -i ~/.ssh/id_rsa.pub yyy@xxxxx.org
).
Comme les fichiers id_rsa et id_rsa.pub peuvent facilement être copiés d'un ordinateur à l'autre, on peut sécuriser un peu en faisant en sorte que le serveur B n'accepte la clé du serveur A que si cette clé est utilisé depuis l'adresse IP du serveur A.
Il faut alors ajouter “from=IP1,IP2” dans le fichier ~/.ssh/authorized_keys
, au début de la clé en question.
Exemple :
from="192.02.300.01" ssh-rsa XXXYYYZZZ(clé) user@server
Configurer SSH sur ses serveurs
En brouillon.
La connexion par mot de passe doit être désactivée partout. La seule façon de se connecter est d'utiliser une clé SSH.
Il peut arriver que le fichier stockant les clés ssh soit corrompu (c'est rare mais comme c'est déjà arrivé sur Khaganat, autant en parler). Ce n'est pas bloquant :
- soit il s'agit d'une VM, dans ce cas, il est possible d'accéder à la VM depuis l'hyperviseur, et de réparer le fichier,
- soit il s'agit de l'hyperviseur, dans ce cas, il suffit de rebooter en mode rescue depuis l'interface de gestion des serveurs et de monter les partitions, puis réparer le fichier.
Cela demande à chaque fois les privilèges au dessus, mais ce n'est pas bloquant (sauf si la supersyadmin s'est sauvée loin du net). Enfin, au pire… c'est à ça que servent les backup : relancer un serveur, ailleurs. D'autant que si un fichier de ce genre est corrompu, il faut s'inquiéter de ce qui a pu se corrompre par ailleurs.
Chaque utilisateur doit avoir son propre compte sur les serveurs où il a un accès. Par exemple, un compte “zatalyz” sur jukni, avec les privilèges sudo.
La connexion via root est désactivée.
Cela permet deux choses :
- chaque utilisateur peut paramétrer sa session suivant ses préférences : terminal, alias, etc.
- l'historique de chacun est différencié. En cas de souci, il est possible de retrouver qui a fait quoi et donc de mieux comprendre l'enchainement des opérations.
Paramétrer sshd_config
Ssh doit donc être configuré pour être bien sécurisé et ne pas permettre qu'un attaquant se connecte par ce biais.
Cette partie a été mise à jour le 6 février 2018. La sécurité étant un domaine en perpétuelle évolution, tenez-vous au courant et n'appliquez pas bêtement et veillez à utilier des informations récentes.
D'autres options peuvent être intéressantes à activer/désactiver suivant votre usage. Ce qui est décrit ici permet une installation de base, couvrant les besoins les plus classiques et apportant un niveau de sécurité acceptable.
La configuration de base sur Debian est relativement correcte ; il y a quelques options qui gagnent à être expliquées et d'autres qui gagnent à être modifiées. Certaines options sont déjà configurées par défaut sur la bonne valeur, même quand elles sont commentées, mais ça va toujours mieux en le disant explicitement.
Le fichier à modifier est /etc/ssh/sshd_config
.
# What ports, IPs and protocols we listen for Port 22
Cette option peut être modifiée pour qu'un attaquant automatique soit bloqué : par contre il faudra préciser le port ssh pour se connecter. La commande ne sera donc plus ssh identifiant@serveur.com
mais ssh identifiant@serveur.com -p monport
. Suivant votre installation2), il peut être intéressant de mettre autre chose que 22 (port par défaut, ciblé par pas mal de bots), tout en sachant que changer de port ne suffit pas à protéger votre serveur.
PermitRootLogin no
ou
PermitRootLogin prohibit-password
La première option interdit de se connecter en root directement via ssh. C'est l'option la plus sécurisée. Il faudra donc se connecter en ssh avec un nom d'utilisateur basique, puis passer en root si nécessaire.
La seconde option permet de se connecter en root uniquement si la clé ssh a été envoyée au serveur. C'est relativement sécurisé, tant que votre propre clé est elle-même en sécurité. Préférez l'utilisation d'un compte utilisateur non-root pour vous connecter !
StrictModes yes
Cela garantit que le serveur vérifie les modes et droits des fichiers de l'utilisateur avant de se connecter.
UsePrivilegeSeparation sandbox # si dispo sinon # UsePrivilegeSeparation yes
La première option, si elle est supportée par votre version de SSH, permet de bien séparer les privilèges et est à privilégier. Si vous avez une version SSH un peu plus ancienne, la seconde reste très acceptable.
AllowUsers Pseudo1 Moi Toiaussi AllowsGroups wheel
AllowUsers
n'est pas dans le fichier de base de la plupart des fichier de config sous Linux, et ça vaut le coup de l'ajouter. Seul les utilisateurs listés pourront se connecter en ssh. Cela évite qu'on puisse se connecter avec un des utilisateurs automatiquement créé par le système ou un des paquets. Bien que faire ssh www-data@serveur.com
ne soit pas sensé marcher quoi qu'il arrive ; mais si vous installez des paquets via des dépôts externes à votre distribution, vous n'êtes pas forcément sûr (à moins de bien lire le code) qu'une faille dans ce genre n'existe pas. AllowUsers
sécurise de ce point de vue : seuls les utilisateurs listés peuvent se connecter.
L'alternative AllowsGroups
est intéressante pour gérer directement tous les utilisateurs d'un groupe (ici, le groupe “wheel”, nom souvent attribué aux sysadmins).
À noter que vous pouvez aussi spécifier l'accès à une plage d'ip : AllowUsers admin@192.168.14/24
; se référer à la doc de SSH pour plus d'infos.
PasswordAuthentication no
Interdit purement et simplement à tous les utilisateurs de se connecter via ssh avec un mot de passe : il faut forcément une clé ssh enregistré sur le serveur.
ChallengeResponseAuthentication no
Cela va avec le paramètre précédent et le complète. La meilleure explication (en anglais) est ici.
PermitEmptyPasswords no
Cela interdit de se connecter sans mot de passe. C'est sans doute superflu vu que de toute façon on oblige à se connecter avec sa clé SSH, mais dans le doute, on le renseigne.
MaxAuthTries 6
Spécifie le nombre de tentative d'authentification par connexion. L'ANSSI préconise 2 ; personnellement, entre ma capacité à me planter en tapant le mot de passe de ma clé SSH et le fait que j'ouvre parfois 3 connexions au même serveur en même temps, j'ai préféré mettre un chiffre un peu plus grand afin de ne pas me faire éjecter de mes propres serveurs, tout en étant assez petit pour limiter une attaque par bruteforce.
LoginGraceTime 30
Temps en seconde pour saisir son mot de passe. En fait, 30 secondes, c'est plutôt long, même avec une passphrase un peu conséquente.
PubkeyAuthentication yes
Autorisé par défaut, comme toujours c'est aussi bien en le déclarant… Permet simplement d'utiliser les clés SSH pour se connecter au serveur !
Protocol 2
SSh a évolué et nous utilisons à présent la 2e version du protocole. Pour des raisons de compatibilité, le protocole 1 n'est pas désactivé (et n'est utile que si vous n'avez pas mis à jour votre installation, hein). En renseignant cette option, vous vous assurez d'utiliser la dernière version.
Ciphers aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
Ajoutez ces lignes pour préciser les algorithmes acceptés et leur ordre de préférences lors de l'utilisation de SSH. Pour les protocoles, voir http://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf page 11.
AllowTcpForwarding no
Il est possible, via SSH, de faire des trucs fun avec TCP, mais mal maitrisé, cela peut ouvrir des failles à un attaquant. On ne va pas faire compliqué, sauf besoin spécifique, vous devez désactiver ceci et le mettre à no
.
X11Forwarding no
X11Forwarding
sert à afficher graphiquement ce qui se passe sur le serveur. En dehors de quelques cas particuliers, ça n'a aucun intérêt puisque vous allez agir via la console. De plus, les interfaces graphiques viennent avec leurs propres failles (forcément un logiciel de plus c'est plus de risque de failles, et avec X11 il y a de quoi s'amuser), donc… on désactive. Dans le cas où ce serait nécessaire, il faudra ajouter l'option ForwardX11Trusted no
qui en limitera les privilèges.
PrintLastLog yes
Cette option permet surtout de faire un contrôle “humain” des incohérences. Lors de votre connexion ssh, un message vous indiquera les informations de la dernière connexion, ce qui peut permettre de s'inquiéter si ça n ressemble pas à ce que vous savez des connexions au serveur…
PrintMotd no
Précise si sshd affiche le contenu du fichier /etc/motd quand un utilisateur se connecte en mode interactif et par défaut à “yes”. Comme c'est généralement le shell qui gère ça, on peut passer à “no”, ce qui permet aux utilisateurs que ça gonfle de tout simplement le désactiver, tout en laissant les autres le garder, le tout sur le même serveur.
AcceptEnv LANG LC_*
Là, de ce que je comprends, cela permet à l'utilisateur de passer avec ses propres variables d'environnement (pour la langue). Il est possible que la variable AcceptEnv ouvre une faille même si, là, avec ça, je ne suis pas sûre. Comme nous sommes en français avec des accents bizarres, il me semble raisonnable de laisser ça (au risque, sinon, de ne plus pouvoir entrer nos mots de passe). Si vous comprenez exactement les enjeux de cette ligne, merci de le préciser.
Subsystem sftp /usr/lib/openssh/sftp-server
Appelle un daemon pour gérer certains aspects, ici sftp.
Présent dans tous les fichiers sshd_config des diverses distributions Linux que j'ai pu voir, je préfère le laisser “dans le doute”, car sftp est bien pratique. Cependant, sftp mal configuré peut ouvrir aussi des failles, donc, si vous en savez plus, n'hésitez pas à partager votre savoir.
UsePAM yes
Bon, là… je ne sais pas, je ne comprends pas bien la doc.
Donc, pour le moment je le laisse… Si les options PasswordAuthentication et ChallengeResponseAuthentication sont passés à non, cela empêche en principe qu'une connexion par mot de passe soit possible, ce que PAM peut permettre…
Exemple de fichier sshd.config
Voici à quoi peut ressembler votre fichier /etc/ssh/sshd_config
. Adaptez les quelques points à personnaliser.
- ssh_config
#Port 22 Protocol 2 Ciphers aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com PermitRootLogin no StrictModes yes UsePrivilegeSeparation sandbox # si dispo sinon # UsePrivilegeSeparation yes PasswordAuthentication no ChallengeResponseAuthentication no PubkeyAuthentication yes UsePAM yes PermitEmptyPasswords no MaxAuthTries 6 LoginGraceTime 30 AllowsGroups wheel AllowTcpForwarding no X11Forwarding no PrintLastLog yes PrintMotd no AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server
N'oubliez pas de relancer ssh après avoir modifié ce fichier.
service ssh restart
Pour aller plus loin
- Toutes les possibilités de sshd_config, doc officielle en anglais.