2017-04-30-openssh-debian-configuration

Installer, configurer et sécuriser le serveur ssh

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, lister les algos pris en charge par votre serveur avec les commandes suivantes – respectivement pour l’asymétrique, le symétrique et le hashage :

Debian Jessie (OpenSSH 6.7p1-5+deb8u3)

l’asymétrique

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
diffie-hellman-group1-sha1
curve25519-sha256@libssh.org

le symétrique

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

le hashage

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 utilisé.
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 :

ssh -Q key

ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com
ssh-rsa-cert-v00@openssh.com
ssh-dss-cert-v00@openssh.com

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, dont les clefs sont plus courtes.

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(fail2ban)…

Mettre en place une clef ssh de type EdDSA ainsi que la connexion automatique sans mot de passe.
Générer une clé côté client

ssh-keygen -t ed25519 -f ssh_host_ed25519

Modifier le fichier de configuration /etc/ssh/sshd_config

PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication yes
PermitEmptyPasswords no

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

les valeurs ci-dessus sont celles par défaut sur une installation debian

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

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

TCPKeepAlive

Lorsqu’on est connecté en ssh à un ordinateur distant et qu’on laisse la connexion inactive pendant un certain temps, il arrive que l’on soit déconnecté. On se retrouve alors avec un message du style :

Read from remote host distant.tld: Connection reset by peer Connection to distant.tld closed.

Deux approches de contournement

A-Serveur

Si vous avez un accès administrateur au serveur, il est possible de configurer ClientAliveInterval et ClientAliveCountMax.

Il existe bien un paramètre TCPKeepAlive, mais il fonctionne sur la couche transport et non sur la couche applicative. C’est donc un petit peu moins fiable, on préférera le désactiver au profit de ClientAliveInterval ou ClientAliveCountMax.

• ClientAliveInterval envoie un message au client ssh après x secondes sans activité (0 = jamais). Si le client répond au serveur, la connexion est maintenue.
• ClientAliveCountMax quant à lui, concerne le nombre maximal de requêtes ClientAliveInterval sans réponse que tolérera le serveur avant de fermer la connexion.

Ajouter les lignes suivantes au fichier /etc/ssh/sshd_config :

ClientAliveInterval 600 
ClientAliveCountMax 0

modidier la ligne (passage à no)

TCPKeepAlive no

On redémarre ensuite le serveur

service ssh restart.

B-Client

Cette solution est très pratique si l’on a pas un accès root à la machine. Il va s’agir d’utiliser la directive ServerAliveInterval. Cette dernière va faire en sorte que le client envoie toutes les x secondes une requête au serveur ssh pour lui signaler qu’il est toujours en vie. Ainsi, on évite la déconnexion par timeout.
Ouvrir le fichier de configuration ssh client /etc/ssh/ssh_config et y ajouter la ligne suivante :

ServerAliveInterval 120

Votre ssh ne devrait désormais plus se couper