Utiliser SSH sur votre serveur distant

L'utilisation de SSH pour se connecter à ses serveurs semble être quelque chose de fondamental, mais pour beaucoup SSH reste un logiciel/protocole obscur. Nous allons tenter d'éclaircir tout ça et nous en profiterons pour faire un peu de prévention.

Qu'est-ce que SSH ?

Voici la définition donnée par Wikipédia :

Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication sécurisé. [...] Tous les segments TCP sont authentifiés et chiffrés. Il devient donc impossible d'utiliser un sniffer pour voir ce que fait l'utilisateur.

Pour faire simple, SSH est un « Shell » sécurisé qui nous permettra de prendre le contrôle sur nos serveurs distants.

Il permet aussi de faire une multitude d'autres choses, mais nous ne les verrons pas ici.

Installation de SSH

Pour pouvoir utiliser SSH, il va falloir l'installer sur la machine serveur et sur les machines clientes.

Sur la plupart des machines Unix (comprenez Linux et Mac) SSH est un paquet installé par défaut. Si toutefois sur votre machine ce n'est pas le cas, vous pouvez lancer une commande du type :

sudo apt-get install ssh 

Changez le gestionnaire de paquets et sa syntaxe par celui de votre distribution.

Pour ceux qui ont une machine client sous Windows, vous pouvez installer des clients SSH comme PuTTY ou OpenSSH.

Configuration

Maintenant que vous avez installé SSH, il va falloir le configurer.

Par défaut, tous les utilisateurs du serveur peuvent lancer une connexion distante avec SSH. Très bien, nous pouvons déjà utiliser notre machine à distance. Par contre, nous ne voudrions pas qu'un petit malin réussisse à se connecter en tant que root sur notre serveur.

Pour empêcher ça, nous allons commencer par créer un nouvel utilisateur sur le serveur.

# Serveur
adduser nomDeVotreUser

Répondez aux questions posées par l'utilitaire et votre nouvel utilisateur sera créé et utilisable par SSH.

# Serveur
adduser nomDeVotreUser sudo

Nous ajoutons notre nouvel utilisateur à la liste des utilisateurs ayant le droit d'effectuer certaines tâches normalement dédiées au super-utilisateur sans en être un.

Connexion par clés

Beaucoup d'attaques utilisant le protocole SSH utilisent la méthode de « brute force ». De ce fait, les connexions basées sur un mot de passe sont moins sûres que les connexions basées sur une paire de clés.

Donnons à notre utilisateur la possibilité de se connecter par clés.

# Client
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Cette commande permet de créer une clé de chiffrement RSA de 4 096 bytes. ssh-keygen génère une clé publique et une clé privée. La clé privée ne devra jamais sortir de votre machine et n'être partagée avec personne.

# Serveur
mkdir ~/.ssh
# Client
ssh-copy-id -i adresse/de/votre/clepublique.pub user@server

La clé publique que nous venons de créer doit être transférée sur le serveur distant et ajoutée à la liste des clés autorisées à se connecter avec le nouvel utilisateur.

Si vous faites un test maintenant (ssh user@server) SSH ne devrait pas vous demander de mot de passe pour lancer la connexion.

Si un mot de passe vous est demandé, cela veut dire que quelque chose s'est mal passé dans les étapes ci-dessus. Je vous conseille de ne pas passer à la suite sans avoir résolu le problème.

☝️
Si la connexion échoue sans raison apparente, vérifiez que la clé PubkeyAuthentication soit bien marqué à yes dans le fichier /etc/ssh/sshd_config. 

De petits réglages de sécurité supplémentaires

À présent que notre nouvel utilisateur est prêt, empêchons root de se connecter et modifions quelques petits trucs.

# Serveur
vim /etc/ssh/sshd_config

Changer la valeur de Port à une valeur numérique quelconque (retenez-la) au-dessus de 1024, celle de PermitRootLogin et PasswordAuthentication à no. Vous devriez avoir :

Port 2923
PermitRootLogin no
PasswordAuthentication no

Ainsi, les hackers qui chercheront à se connecter à votre serveur sur le port 22 échoueront. Ils ne pourront pas non plus se connecter directement à root et avoir tous les droits trop facilement.

La dernière ligne empêche l'authentification par mot de passe. Finies donc les attaques par « brute force », les tentatives de petits malins qui pensent avoir trouvé votre mot de passe. Toute personne qui voudra se connecter à votre serveur devra avoir sa clé (ou une de ses clés) publique enregistrée dans votre machine.

Pour résumer :

# Client
ssh user@server.com -p 2923 # pour se connecter 

ssh user@server.com # ne fonctionne pas
ssh root@server.com -p 2923 # ne fonctionne pas

.ssh/config : simplifiez-vous la vie

Imaginez que vous ayez plusieurs serveurs à gérer, que pour chacun, vous ayez une paire de clés différentes, un utilisateur différent : il est facile de voir le bazar que cela peut devenir. Une solution existe, le fichier ~/.ssh/config.

# Client
vim ~/.ssh/config
Host sous.domaine.com
  IdentityFile /home/user/.ssh/cleprive

Host domaine.org
  IdentityFile /home/user/.ssh/cleprive2

Grâce à la clé IdentityFile SSH sait maintenant quelle clé privée utiliser pour les hosts domaine.org et sous.domaine.com.

Host sous.domaine.com
  IdentityFile /home/user/.ssh/cleprive

Host nomPersonnalisable
  HostName github.com
  IdentityFile /home/user/.ssh/cleprive3

Host nomPersonnalisable2
  HostName github.com
  IdentityFile /home/user/.ssh/cleprive2

Si vous avez deux comptes chez GitHub (ou deux utilisateurs sur un serveur quelconque) et des paires de clés différentes pour chaque compte, vous pouvez ajouter la clé HostName avec en valeur le nom de domaine et changer Host en un nom personnalisable. Ainsi, vous pourrez avoir deux configurations SSH différentes pour un même serveur.

Host gitserver
  HostName git.com
  User Mindsers
  Port 2923
  IdentityFile /home/user/.ssh/cleprive2

Deux autres clés intéressantes à connaitre sont les clés User et Port. Leur nom est, on ne peut plus clair et l'exemple parle de lui-même.

C'est une config simple qui nous permettra de nous connecter à notre serveur en tapant :

ssh gitserver

Vous pouvez comparer les deux versions de la commande de connexion, il n'y a pas photo.