Installer, configurer et sécuriser le serveur ssh
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
au préalable.
Installer ssh
Pour ce faire, c’est très simple :
apt 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.
En outre, avec les attaques par bruteforce, les mots de passe deviennent plus vulnérables. 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.
Dans ce cas, 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).
Déjà 8 réponses, rejoignez la discussion !
Cascador
dit :Salut poulet,
Tu devrais être un peu plus précis sur le fait de parler du serveur SSH ou du client SSH : Configurer SSH –> Configurer le serveur SSH
celui par défaut –> celui par défaut)
restart ssh –> Il manque le début systemctl je suppose
Tcho !
Buzut
dit :Hello,
Merci pour le feedback, c’est corrigé !
Tchô
Cascador
dit :Error ! service ssh restart ou systemctl restart ssh mais pas service restart ssh.
Tcho !
Buzut
dit :Je suis allé un peu vite ;) fixed!
ManuD
dit :Merci pour l’article.
La crypto c’est complexe mais merci d’avoir débrousaillé
Buzut
dit :Complexe mais passionnant ! Merci pour le commentaire :)
ManuD
dit :Pour ma part je but sur un problème de config
J’ai 2 cartes et je souhaiterai que l’une écoute sur le port 222 et l’autre sur le port 22.
J’ai ajouté 2 directives
ListenAddress xxx.xxx.xxx.1:222
ListenAddress xxx.xxx.xxx.2:22
Et commanté la directive
Port 22
Malgré tout quand je recharge sshd j’ai le message
sshd[8311]: error: Bind to port 22 on xxx.xxx.xxx.xxx failed: cannot assign requested address.
En revanche la connexion sur le port 222 de l’autre carte fonctionne sans problème.
Je me suis bien assuré que les ports 22 et 222 soient bien ouverts dans Firewalld et les cartes concernées dans les bonnes zones.
J’ai certainement râté un truc
Buzut
dit :J’avoue que là comme ça. Je ne sais pas trop. Il faudrait jeter un œil au serveur et faire quelques tests. Est-ce que ça fonctionne avec la directive Port 222 et joignables sur les deux cartes réseaux sur ce même port ?