Installation et configuration de OpenSSH

OpenSSH est une implémentation libre du protocole SSH permettant des communications sécurisées. OpenSSH fournit les outils suivants :

• ssh, le client ssh, et un remplaçant pour rlogin et telnet.
• scp, un remplaçant pour rcp, permet la copie de fichiers.
• sftp, un remplaçant pour ftp.
• sshd, le démon SSH

Installation

Utilisez apt pour installer le serveur openssh :

apt install openssh-server

Modification du fichier sshd_config

Le fichier /etc/ssh/sshd_config permet de définir des options agissant sur le daemon sshd. Éditez ce fichier et ajoutez ou modifiez les lignes suivantes si nécessaire. Dans la majorité des cas, la configuration par défaut de debian sera suffisante. Attention cependant, depuis debian jessie, le login root est désactivé par défaut (PermitRootLogin no).

Les deux directives auxquelles je touche le plus souvent :

PermitRootLogin without-password
AllowUsers root pfoo jonass

Petite revue des options :

• Port : spécifie le port sur lequel le serveur ssh doit écouter. Par défaut, le port 22 est utilisé. Certaines personnes préfèrent utiliser un autre port afin de réduire les risques d'attaques, principalement par brute force. Personnellement, je trouve cela inutile du moment qu'on a bien configuré sshd.
• ListenAddress : spécifie l'adresse ip sur laquelle le serveur ssh écoute. Par défaut, ssh écoute sur l'ip 0.0.0.0 (il écoutera donc toutes les ips configurée sur la machine).
• Protocol : spécifie la version du protocole ssh qu'il faut utiliser. Il est préférable (voir impératif...) d'utiliser la version 2.
• HostKey : spécifie les fichiers où sont stockés la clé privé.
• ServerKeyBits : spécifie le nombre de bits à utiliser pour la clé éphémère du serveur. Cette valeur est utilisée lors de la génération de la clé lors du lancement de openssh (pour le protocole SSH v1 uniquement).
• LoginGraceTime : spécifie le temps (en seconde) que le serveur va attendre avant de déconnecter un utilisateur ne s'étant pas logué avec succès.
• KeyRegenerationInterval : spécifie combien de temps le serveur va attendre avant de régénérer automatiquement sa clé.
• PermitRootLogin : spécifie si l'utilisateur root peut se loguer en utilisant ssh. Désactiver cette option permet d'augmenter sensiblement la sécurité en se prévenant des attaques de type brute-force sur l'utilisateur root. Pour n'autoriser que le login par clé utilisez l'argument without-password au lieu de no et ajouter root à la liste des utilisateurs autorisés par la directive AllowUsers.
• IgnoreRhosts : spécifie si les fichiers ~/.rhosts et ~/.shosts ne doivent pas être utilisé. Il est recommandé de mettre cette option à yes pour des raisons de sécurité.
• IgnoreUserKnownHosts : spécifie si le fichier ~/.ssh/known_hosts doit être ignoré lors d'une RhostsRSAAuthentication.
• StrictModes : spécifie si le serveur ssh doit vérifier les permissions des utilisateurs dans leur répertoire home et leur fichier rhosts avant d'accepter le login. Il est recommandé de conserver cette option à la valeur yes car les utilisateurs peuvent laisser -par erreur- leurs fichiers/dossiers en lecture totale.
• X11Forwarding : spécifie si le forwarding X11 doit être activé. Inutile dans le cas d'un serveur sans environnement graphique.
• PrintMotd : spécifie si le fichier /etc/motd doit être affiché lorsqu'un utilisateur se logue. Je vous recommande de générer un joli motd avec le paquet linuxlogo.
• SyslogFacility : spécifie le code syslog à utiliser pour loguer les messages de sshd. Ce code spécifie le système qui a produit le message (AUTH dans notre cas).
• LogLevel : spécifie le niveau de log à utiliser. INFO est généralement utilisé.
• RhostsAuthentication : spécifie si sshd peut essayer d'utiliser les authentifications basé sur rhosts. Pour des problèmes de sécurité, il est peut recommandé d'activer cette option (protocole SSHv1 uniquement).
• RhostsRSAAuthentication : spécifie si le serveur ssh doit essayer d'utiliser les authentifications rhosts en concert avec les authentifications RSA (SSHv1 uniquement).
• HostbasedAuthentication : spécifie s'il faut autoriser une authentification par rhost en concert avec une authentification par clé publique de la machine distante. Cette option est similaire à RhostsRSAAuthentication pour SSHv2.
• RSAAuthentication : spécifie si le serveur doit utiliser l'authentification RSA. Cette option doit être yes pour augmenter la sécurité.
• PubkeyAuthentication : spécifie si les authentifications par clé publique sont activés.
• PasswordAuthentication : spécifie si les authentifications basés sur le password doivent être activés.
• PermitEmptyPasswords : spécifie s'il doit être possible de se loguer sans entrer de mot-de-passe.
• AllowUsers : spécifie que seul les utilisateurs listés par cette ligne seront autorisés à se loguer. Il faut séparer les utilisateurs par un espace. Il est possible de préciser l'ip autorisée à se loguer avec une entrée de la forme login@ip.
• AllowGroups : spécifie que seul les utilisateurs membres des groupes donnés ici seront autorisés à se connecter.
• MaxStartups : cette option permet de limiter le nombre de connexion. La valeur 10:30:60 signifie par exemple qu'on accepte 10 connexions sans qu'un utilisateur n'ait réussi à s'identifier. Si le nombre de connexion passe au dessus de 10, il y a 30% de chances que les tentatives suivantes soient bloquées. Les chances de blocage augmentent de manière linéaire jusqu'à bloquer 60% des connexions.
• MaxAuthTries : spécifie le nombre de tentative d'authentification avant que la session ssh soit refermée (cette option permet de ralentir les attaques par bruteforce).

Les fichiers relatifs à openssh

• /etc/ssh/sshd_config : contient la configuration pour le serveur sshd.
• /etc/ssh/ssh_config : contient la configuration globale pour le client ssh.
• /etc/ssh/ssh_host_*_key: ces fichiers contiennent les clés privés de la machine. Ils ne doivent appartenir que à root, et n'avoir des droits que pour root, sinon sshd ne démarre pas.
• /etc/ssh/ssh_host_*_key.pub : ces fichiers contiennent les clés publiques de la machine. Ils ne doivent être accessible en écriture que par root, mais doivent être lisible par tous. Ces fichiers sont crées avec ssh-keygen.
• $HOME/.ssh/authorized_keys : Ce fichier contient la liste des clés publiques (RSA, DSA) qui peuvent être utilisés pour se connecter avec le compte correspondant à $HOME.
• /etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts : Ces fichiers définissent les clés des machines distantes auxquels on se connecte. Cela permet de savoir si on se connecte bien à la bonne machine distante. Lorsque vous établissez pour la première fois une connexion ssh vers une machine, ssh vous demandera s'il doit ajouter la clé à la liste. /etc/ssh/ssh_known_hosts doit être lisible par tous le monde, et writable uniquement pas root.
• /etc/nologin : Lorsque ce fichier existe, personne ne peut se connecter en ssh à l'exception de root. Le contenu de ce fichier est renvoyé aux personnes essayant de se connecter. Généralement, ce fichier est créé pendant que la machine boot pour éviter que des utilisateurs ne se connectent trop tôt. Si vous avez interdit le login root, ce système peut poser de sérieux problème. Pour le désactiver, ce que je déconseil, il faut commenter la ligne account required pam_nologin.so du fichier /etc/pam.d/ssh.
• /etc/hosts.allow, /etc/hosts.deny : La liste des hosts ayant le droit/n'ayant pas le droit de se connecter. Ces fichiers ne concernent pas uniquement ssh, mais toutes les connexions ip.

Le fichier AUTHORIZED_KEYS

Comme nous l'avons dit précédemment, $HOME/.ssh/authorized_keys est le fichier listant les clefs publiques autorisées lors d'une authentification par clé publique. Chaque ligne de ce fichier est formé de manière à contenir jusqu'à cinq champs séparés par des espaces : options, type de clef, clef (encodée en base64), commentaire. La version 2 du protocole ssh impose une clé d'au moins 768 bits. Voici les différentes options que vous pouvez spécifier :

• from= : spécifie le nom canonique de la machine distante. L'opérateur "!" peut être utilisé pour empêcher la connexion si le mot précédé d'un "!" est trouvé. Si un hostname est spécifié, toutes les ips associées à cette hostname seront autorisés.
• command= : spécifie la commande qui doit être exécuté lorsqu'un connexion utilisé cette clé. Celà implique que la commande fournie par le client se connectant sera ignoré.
• no-port-forwarding : interdit les redirections (forwarding) tcp/ip.
• no-X11-forwarding : interdit les redirections (forwarding) X11.
• no-agent-forwarding : interdit les redirections (forwarding) de l'agent d'authentification.
• no-pty : interdit l'allocation d'un terminal.
• permitopen=host:port : limite les redirections de port de manière à ce qu'il ne soit possible de se connecter qu'à l'host:port spécifié.

Exemple :

from="192.168.0.15",no-port-forwarding,no-pty ssh-rsa AAAAB
3NzaC1yc2EAAAABIwAAAQEAybmcqaU/Xos/GhYCzkV+kDsK8+A5OjaK5WgLMqmu38aPo
56Od10RQ3EiB42DjRVY8trXS1NH4jbURQPERr2LHCCYq6tHJYfJNhUX/COwHs+ozNPE8
3CYDhK4AhabahnltFE5ZbefwXW4FoKOO+n8AdDfSXOazpPas8jXi5bEwNf7heZT++a/Q
xbu9JHF1huThuDuxOtIWl07G+tKqzggFVknM5CoJCFxaik91lNGgu2OTKfY94c/ieETO
XE5L+fVrbtOh7DTFMjIYAWNxy4tlMR/59UVw5dapAxH9J2lZglkj0w0LwFI+7hZu9XvN
fMKMKg+ERAz9XHYH3608RL1RQ== commentaire de la clé

Installation d'une clé privé pour se connecter plus facilement au serveur

Génération des clés

Si vous utilisez linux, il vous est possible d'installer une clé ssh sur le serveur afin de ne plus avoir à entrer votre mot de passe à chaque fois que vous souhaitez vous connecter au serveur. Pour commencer, il faut installer le client OpenSSH sur VOTRE ordinateur. Si vous utilisez debian ou ubuntu :

apt install openssh-client

Il faut ensuite générer vos clés publique et privée :

ssh-keygen -t rsa -b 4096

Ici je génère une clé rsa de 4096 bits. D'autres algorithmes sont disponibles comme ecdsa et ed25519.
Il vous sera posé deux questions. La première vous demandera d'indiquer le chemin où les clés doivent être installés. Vous pouvez laisser le chemin proposé par défaut si vous ne souhaitez utiliser qu'un seul couple de clé. La seconde question vous demande d'entrer la passphrase qui servira à protéger la clé privé. Vous pouvez entrer une passphrase ou non, mais il est recommandé d'en entrer une par mesure de sécurité. Une fois les clés générées, il va falloir ajouter la clé publique à la liste des clés autorisées par votre serveur. Pour cela, on utilise la commande ssh-copy-id

$ ssh-copy-id -i ~/.ssh/id_rsa.pub plouf@hostname
Password:

Entrez le mot de passe de l'utilisateur plouf de votre serveur. Si l'opération se passe bien, vous devriez voir le message suivant apparaitre:

Now try logging into the machine, with "ssh 'plouf@hostname'", and check in:
 .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Désormais, si vous tapez ssh plouf@hostname, vous devrez entrer votre passphrase et non plus votre mot-de-passe. Si vous avez décidé de ne pas préciser de passphrase lors de la création de la clé, vous pourrez vous connecter à votre serveur sans avoir à préciser votre mot de passe ou votre passphrase. Vous pouvez sauter l'étape suivante.

Utiliser plusieurs clés

Rien de vous empêche de créer plusieurs clés (sous des noms différents tout de même). Il faudra cependant configurer votre client ssh afin qu'il sache quelle clé utiliser pour quelle ip. Pour cela, créez le fichier ~/.ssh/config et ajoutez y les lignes suivantes :

Host serveur1.domain.com
User pfoo
Identityfile ~/.ssh/id_rsa_serveur1

Host serveur2.domain.com
User blah
Identityfile ~/.ssh/id_rsa_serveur2

Avec ce fichier, une tentative de connexion de l'utilisateur pfoo sur serveur1.domain.com utilisera la clé ~/.ssh/id_rsa_serveur1 alors qu'une connexion de l'utilisateur blah sur serveur2.domain.com utilisera la clé ~/.ssh/id_rsa_serveur2.

Limiter l'utilisation

• from=""
• command=""
• no-port-forwarding
• no-X11-forwarding
• no-agent-forwarding
• no-pty

exemple :

from="votre_ip",no-port-forwarding,no-pty ssh-rsa AAAAB[...]

Forcer des utilisateurs à utiliser sftp

La directive Match permet de définir des actions qui ne s'appliqueront qu'à un utilisateur (Match User) ou un groupe d'utilisateur (Match Group). Si vous voulez par exemple forcer un groupe d'utilisateur à se connecter en sftp uniquement (les utilisateurs de ce groupe ne pourront donc plus se connecter en ssh) vous pouvez ajouter les lignes suivantes à la fin du fichier de configuration de sshd :

Match Group sftponly
      ChrootDirectory %h
      ForceCommand internal-sftp
      AllowTcpForwarding no

Ainsi, tous les membres du groupe sftponly seront obligés de se connecter en sftp. Notez que pour que cela fonctionne il faut que les utilisateurs :

• aient pour groupe primaire sftponly
• que leurs répertoires home appartiennent à root et ne puissent être écrit par aucun autre utilisateur ou groupe.

Vous pouvez aussi, pour plus de sécurité, changer le shell de ces utilisateurs pour /bin/false ou /usr/sbin/nologin :

chsh -s /bin/false username
chsh -s /usr/sbin/nologin username

Forcer des utilisateurs aux commandes de transfert de fichiers

Vous pouvez utiliser rssh qui est un shell restreint qui ne permet l'usage que des commandes scp, sftp, cvs, svnserve (Subversion) rdist et rsync.

Renouveler les clés ssh du serveur

rm -rf /etc/ssh/ssh_host*
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -t ecdsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -t ed25519 -N ''