Par définition, un serveur est accédé de manière distante. C’est à dire qu’on doit pouvoir l’administrer sans être physiquement devant. Alors qu’il soit dans un datacenter à l’autre bout du globe ou dans le grenier de la maison, SSH nous permettra de gérer tout ça depuis notre ordinateur de bureau (ou laptop). Si vous louez votre serveur chez un hébergeur, vous l’avez sans doute-reçu avec ssh pré-installé. Cependant, si vous bidouillez au fond de votre garage, il va falloir l’installer vous-même, et qui plus est, il n’est pas inintéressant de peaufiner la config de SSH pour vos propres besoins !

Toutes les commandes ci-dessous seront exécutées en tant que root, pensez donc à faire un petit sudo su au préalable.

Installer ssh

Pour ce faire, c’est très simple :

apt-get install ssh

Cette commande va installer open-ssh sur votre machine. C’est d’ailleurs la seule commande que vous aurez à exécuter sur cette dernière puisque après ça, vous pourrez laisser le serveur au garage tandis que vous le gérerez confortablement assis à votre bureau !

Se connecter

On va maintenant se connecter en ssh à notre serveur depuis une autre machine. Celle-ci doit disposer d’un client ssh. Si vous êtes sous Linux ou Mac OS, je vous invite donc à ouvrir un terminal, si vous êtes sous Windows, regardez du côté de putty. Première connexion :

ssh nom_de_votre_user@ip_du_serveur

C’est tout. Dans mon cas, j’ai créé un compte buzut sur le serveur ayant pour ip 192.168.0.13, je tape donc dans mon terminal ssh buzut@192.168.0.13. Attention, cette adresse ip étant une adresse locale, vous ne pourrez accéder à ce serveur en utilisant cette ip, que lorsque l’ordinateur à partir duquel vous vous connectez est sur le même réseau local que votre serveur (sur la même box ADSL par exemple).

Dans le cas où vous voudriez vous connecter à votre serveur depuis l’extérieur, il faudra utiliser une IP publique. Aucun problème si vous avez votre serveur chez un hébergeur. En revanche, si vous auto-hébergez votre serveur, vous n’avez qu’une seule adresse IPv4 publique (cela n’est pas valable pour l’IPv6) pour une multitude d’appareils connectés sur la box. Votre box/routeur fait donc du NAT et il va falloir procéder à de la redirection de ports pour que le serveur soit joignable depuis l’extérieur.

Configurer SSH

Pour paramétrer SSH, rendez-vous dans son fichier de configuration :

nano /etc/ssh/sshd_config

Chiffrement et intégrité

SSH utilise trois types d’algos différents :

• chiffrement asymétrique pour l’échange des clefs, à partir duquel le client et le serveur se mettent d’accord sur une clef pour du chiffrement symétrique,
• chiffrement symétrique qui servira à chiffrer l’ensemble des données de la session. C’est plus rapide que l’asymétrique, mais il faut une clef partagée, donc on utilise tout d’abord pour cela l’asymétrique,
• du hashage afin de s’assurer de l’intégrité des données.

Pour une explication un peu plus en détails du fonctionnement de SSH, vous pouvez lire cet article [en] de DigitalOcean.

OpenSSH, notamment depuis sa version 7, a fait un peu de ménage dans le support des algos peu fiables. Toutefois, vous pourrez lister les algos pris en charge par votre serveur avec les commandes suivantes – respectivement pour l’asymétrique, le symétrique et le hashage :

# exemple ubuntu 16.04 (OpenSSH_7.2p2 Ubuntu-4ubuntu2.1)
ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256@libssh.org

ssh -Q cipher
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
hmac-ripemd160@openssh.com
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-ripemd160-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Le premier algo dans l’ordre de la liste supporté par le client et le serveur sera celui utilité. Si on passe en mode parano après avoir lu les révélations de Snowden, on peut virer tous les algos créés ou adoubés par le NIST ainsi que ceux n’étant pas à la pointe.

Si nous voulons modifier ces listes d’algorithmes, il faut les préciser dans le fichier de conf. Pour une config axée sécurité, au détriment de la compatibilité avec de plus vieux clients ssh – hors cas spéciaux avec de vieilles ditrib RHEL ou CentOS, nos machines d’admin sont généralement plutôt équipées de clients modernes.

# notez qu'il suffit de séparer les noms par une virgule pour autoriser plusieurs algos
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com
MACs umac-128-etm@openssh.com

Authentification

Au delà de ces trois algorithmes, la question qui fait grand débat est celle concernant l’authentification par clef. Plusieurs algorithmes s’affrontent ici de nouveau, vous pouvez les lister avec ssh -Q key.

Me concernant, dans la droite ligne de ce que nous avons spécifié pour KexAlgorithms, j’ai délaissé RSA (DSA n’est même plus supporté à partir d’openSSH 7.0) au profit de EdDSA, qui est bien plus sécurisé [en] et dont les clefs sont plus courtes. Néanmoins, Ed25519 n’a pas encore un support aussi étendu que RSA au niveau des clients ssh, tout dépendra donc de vos contraintes.

Avec les attaques par bruteforce, les mots de passe deviennent plus vulnérables, et pour palier à cela, il faut en retenir de plus en plus compliqués. On peut cependant interdire toute connexion par mot de passe en substituant le mot de passe par un certificat. La machine cliente génère un certificat, que l’on enregistre sur le serveur. Dès lors, il n’y aura plus de mot de passe à taper ! Ce qui ne nous empêche pas de restreindre le nombre de tentatives de connexion…

Pour mettre en place une clef ssh de ce type ainsi que la connexion automatique sans mot de passe, je vous invite à lire mon article dédié.

Pour en revenir au support des clefs, je commente donc tous les protocoles sauf ed25519 :

# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Pour encore plus de sécurité, vous pouvez limiter les adresses IP qui auront le droit de se connecter au serveur, mais dans ce cas, il faudra vous connecter toujours du même endroit (ou alors passer par votre proxy ou VPN avec toujours la même IP). Remplacez pour cela 0.0.0.0 par l’IP en question et décommenter la ligne en enlevant le dièse.

Vous pouvez également décommenter l’une ou l’autre des deux lignes en laissant 0.0.0.0 ou :: pour faire en sorte que ssh ne soit joignable qu’en ipv4 ou qu’en ipv6.

# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0

Vous pouvez aussi spécifier les utilisateurs que vous autorisez à se connecter. Ainsi, tout autre utilisateur sera dans l’impossibilité de se connecter via ssh. Pour ce faire, il faut rajouter la directive AllowUsers suivie des noms d’utilisateurs à qui vous souhaitez accorder l’autorisation de se connecter en ssh :

AllowUsers login login2 login3 etc

Enfin, je vous conseille aussi de désactiver la possibilité de se connecter en tant que root (l’utilisateur qui a tous les droits). Il est préférable de se connecter avec un utilisateur ayant des droits plus restreints et d’utiliser sudo lorsque les opérations nécessitent d’être root.

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

LoginGraceTime concerne le temps pendant lequel le serveur ssh attend que l’utilisateur s’authentifie, au delà de ce laps de temps, il va clore la connexion. Vous pouvez spécifier le temps que vous voulez, sachant qu’il est par défaut à 2 minutes (120 secondes).

Désactiver l’inutile

Comme souvent, ce qui n’est pas utilisé augmente la surface d’attaque potentielle. Donc si on ne s’en sert pas, autant s’en passer. On peut désactiver X11Forwarding et AllowAgentForwarding pour respectivement le serveur graphique x11 et le ssh forwarding.

X11Forwarding no
AllowAgentForwarding no
TCPKeepAlive no

Vous noterez que je désactive le TCPKeepAlive, en effet, ce n’est pas la meilleure manière de s’assurer que la session reste active. Et j’utilise une autre technique à la place.

C’est tout pour la configuration de ssh. Il va maintenant falloir redémarrer le serveur ssh pour que les modifications prennent effet.

service ssh restart

Enfin, pour vous connecter à votre serveur depuis un autre ordinateur, n’oubliez pas de préciser le port (avec -p que vous avez choisi si vous n’avez pas laissé celui par défaut).