Utiliser SSH sur votre serveur distant

L'utilisation de SSH pour se connecter à ses serveurs semble être quelque chose de basique mais pour beaucoup SSH reste un logiciel/protocole obscure. 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 serveur distants1.

Il permet aussi de faire plein 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 malheureusement sur votre machine ce n'est pas le cas vous pouvez lancer une commande du type :

sudo apt-get install ssh  

Il faut changer 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 installer 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 utilisateur2 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  

On ajoute 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 4096 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
scp adresse/de/votre/clepublique.pub user@server:~/.ssh/clepublique.pub  

La clé publique que nous venons de créer doit être transférée sur le serveur distant...

# Serveur
cat ~/.ssh/clepublique.pub >> ~/.ssh/authorized_keys  

... 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 conseil de ne pas passer à la suite sans avoir résolu le problème.

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

Maintenant 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 serveur à 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.

  1. Je précise "serveur distant" car une connexion SSH a moins d'intérêt pour un serveur auquel on peut avoir un accès physique.

  2. Ceci est utile si vous n'utilisez pas d'autre utilisateur que root. En effet, utiliser root comme utilisateur principal est une très mauvaise pratique.

Nathanaël Cherrier

Ingenieur de développement mobile et web pour Econocom. Passionné par le développement en général, mais plus particulièrement par le développement web et mobile, je vous raconte mes petits secrets.

Subscribe to Mindsers IT

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!