Si vous utilisez linux (et potentiellement windows) au quotidien et que vous êtes amenés à travailler avec des serveurs, vous ne pouvez vous passer de ssh. Certes, une bonne automatisation d’infrastructure peut vous permettre de limiter son utilisation mais rare est une journée sans ssh.

Mais finalement qu’est-ce que SSH ? le connait-on vraiment assez ? Voilà ce que je vous propose de découvrir dans la formation SSH. Cet ensemble de tutoriels permet pour les débutants de mieux comprendre leur environnement de travail et pour d’autres peut être de reposer les bases ou encore découvrir des astuces.

Qu’est-ce que SSH ?

C’est trivial mais il faut bien repartir de quelque chose. SSH cela signifie Secure Shell… comme on dit ça casse pas 3 pattes à un canard mais pourtant c’est terriblement utile et efficace.

Il faut voir d’où l’on vient et à quelle époque nous sommes. Dans un passé informatique plus lointain, la communication avec les serveurs se faisait avec des outils non sécurisés ou peu sécurisés comme par exemple telnet ou encore rsh (remote shell). Désormais, on utilise telnet rarement pour des tests simples comme la vérification d’ouverture de ports ou encore le test l’envoi de mail via un serveur smtp.

Ces outils non sécurisés sont de nos jours à éviter voir à bannir. Les pirates informatiques n’ont plus besoin que nous leur ouvrions les portes déjà assez difficiles à maintenir fermées.

Bref la sécurité informatique commence dès l’installation d’un serveur et à tous les niveaux.

Pour cela, SSH se base bien sûr sur de la cryptographie assez poussée. C’est d’ailleurs pour cela que tout le monde l’utilise et que toute brèche ne traîne pas à être patchée. Il se base sur la bonne vieille mais efficace méthode de client/serveur.

SSH a deux objectifs principaux :

• lutter contre l’interception : c’est à dire qu’une personne qui écoute la communication entre un client et un serveur puisse accéder à ses informations
• lutter contre l’usurpation : pour éviter que le client se fasse passer le serveur et inversement

Du coup on parle souvent de tunnel SSH avec ce sentiment d’assurer une communication sécurisée entre deux protagonistes avec une isolation totale.

Pour son chiffrement, SSH utilise deux phases :

• un chiffrement asymétrique : avantage sa sécurité et inconvénient sa rapidité
• un chiffrement symétrique : avantage sa rapidité et inconvénient la sécurité

Le déroulé d’une communication est la suivante :

Communication SSH :

0. Client > Serveur : TCP – initie la connexion – poignée de main (handshake) SYNchronize

1. Serveur > Client : TCP – réponse handshake SYN/ACKnowledge

2. Client > Serveur : TCP – confirmation handshake ACK

3. Client > Serveur : SSH – Version serveur

4. Serveur > Client : SSH – Version client

…initialisation de la clef

5. Client > Serveur : SSH – requête Diffie Hellman (objectif définir clef symétrique)

6. Serveur > Client : SSH – envoi de la clef symétrique chiffré par la clef publique asymétrique

7. Client > Serveur : SSH – début des échanges par le chiffrement de la clef symétrique

L’installation d’un serveur SSH

Dans mon cas je parlerai pour debian mais sur redhat et sa famille, le principe est le même :

sudo apt install openssh-server

sudo systemctl start sshd

Désormais votre serveur écoute avec le port par défaut à savoir le port 22 sur vos interfaces et donc toutes ses ips.

Ensuite, la configuration passe par le fichier /etc/ssh/sshd_config

Sans rentrer dans d’importants détails, voici l’interprétation de différents paramètres (je vous recommande vivement en cas de modification de paramètres ssh de toujours ouvrir 2 sessions en cas d’erreur cela vous permettra de revenir dessus) :

AcceptEnv : fixer les variables d'env pouvant être importées via le client

AllowAgentForwarding : permet de conserver votre clef (ex : rebond)

AllowGroups / DenyGroups : limiter les groupes à se connecter via ssh

AllowUsers / DenyUsers : limiter les users

Banner : ajouter une bannière à la connexion ssh

Password : mettre les deux à no pour disable password

ChallengeResponseAuthentication - RFC 4256 > poser des questions à l'utilisateurs (password..) > plus sécurisé

PasswordAuthentication - RFC 4252 > specific au password

ChrootDirectory : spécifier au chroot pour users/groups (utilisé avec match généralement)

Ciphers : combinaison des algorithmes d'échange

ClientAliveCountMax : le nombre connexion sans réponse avant cloture de la connexion

ClientAliveInterval : durée de la connexion ssh sans activité (envoi une requête si sans réponse = déconnexion)

Compression : defaut yes

DisableForwarding : supprime les fowarding agent, x11...

ExposeAuthInfo : permet d'afficher des informations l'authentification (path du fichier dans SSH_USER_AUTH)

FingerprintHash : type de hash pou rle fingerprint

ForceCommand : commande exécutée à la connexion (bypass les commandes clientes)

GatewayPorts : désactivation du port forwarding possible (no)

HostbasedAcceptedKeyTypes : type de clefs accepté : edcsa, rsa...

HostbasedAuthentication : authentification sur la clef par host (pas par user)

HostKey / HostCertificate : localisation des fichiers de clefs ou certificatss

IPQoS : limitation de service via débit et/ou délai

Kerberos Authentication : activation de l'authentification via kerberos

ListenAddress : interface/ip d'écoute

LoginGraceTime : délai pour s'authentifier (120 secondes par défaut)

LogLevel : niveau de logs

Match : permet de conditionner une liste d'acions sous condition

MaxSessions : connexions permisses par connexion réseau

PermitEmptyPasswords : permettre un password vide

PermitOpen : quel port forwarding est autorisé

PermitRootLogin : autorisé la connexion en tant que root via ssh (défaut prohibit-password)

PermitUserRC : permettre l'utilisation d'un ssh rc (~/.ssh/rc) = similaire à profile

Port : spécifier le port d'écoute du serveur ssh

PrintLastLog : spécifie la denrière connexion réalisé sur le serveur à la connexion suivante

PrintMotd : affichage d'un message d'accueil (similaire à banner)

PubkeyAcceptedKeyTypes : type de clefs publiques autorisées

PubkeyAuthentication : autoriser ou non l'authentification par clef

StrictModes : vérifie les fichiers et directories avant d'accepter la connexion

SyslogFacility : format des logs

UsePAM (Pluggable Authentication Module) : utilisation du module PAM

X11Forwarding : authoriser le forward x11 (serveur graphique)

A savoir qu’une partie de ces paramètres peuvent être spécifiques à certains utilisateurs ou groupes. Attention pour réaliser ce cas d’utilisation vous devez utiliser 2 Match. Le premier pour spécifier votre bloc aux caractéristiques particulières, le second pour revenir à ALL c’est à dire applicable à tous les utilisateurs.

Match User xavki
Banner /etc/banner.txt
X11Forwarding no
Match All

Je le répète si vous modifiez une configuration SSH ouvrez toujours deux sessions. Cela vous évitera de vous couper la patte et en cas d’erreur de revenir en arrière.

Une fois la modification réalisée vous pouvez redémarrer le service systemd qui le gère :

sudo systemctl restart sshd

Ne vous inquiétez pas, le restart maintient les connexions actives.

Connexion avec un client

Là encore très simplement on va utiliser apt notre gestionnaire de paquets :

sudo apt install openssh-client

Ensuite c’est très facile de vous connecter à un serveur ssh. Si celui-ci accepte une connexion avec le mot de passe du user distant vous pouvez tester et que le port ssh (22) accepte les connexions externes (ou au moins la votre) :

ssh myuser@monhost

Bien sûr il n’est pas recommandé d’utiliser le mot de passe pour vous connecter. En général on autorise peu d’utilisateurs à se connecter avec un mot de passe sur un serveur ssh (voir pas du tout).

Nous apprendrons dans un prochain article comment créer ce que l’on appelle une clef ssh qui finalement repose sur deux clefs : publique et privée.

N’hésitez pas à regarder les tutoriels de la chaine xavki ;). Vous pouvez aussi me soutenir en devenant membre de celle-ci ou encore simplement liker et partager ces vidéos.