Administration réseau sous Linux/SSH

SSH signifie Secure SHell. C'est un protocole qui permet de faire des connexions sécurisées (i.e. cryptées) entre un serveur et un client SSH.

Tcpdump

Routage

Une proposition de fusion est en cours entre Le système d'exploitation GNU-Linux/Le serveur de shell distant SSH et en:OpenSSH.

Les avis sur cette proposition sont rassemblés dans une section de Wikilivres:Pages à fusionner. Les modifications majeures apportées, entre temps, aux pages doivent être commentées sur la même page.

À faire après la pose du bandeau

Vous venez d’apposer le modèle {{à fusionner}}, suivez ces étapes :

1.

Apposez le bandeau sur l’(les) autre(s) page(s) à fusionner.

Utilisez ce texte :

{{à fusionner|Le système d'exploitation GNU-Linux/Le serveur de shell distant SSH|:en:OpenSSH}}

2.

Important : ajoutez une section dans Pages à fusionner en motivant votre proposition.

Utilisez ce texte :

== [[Le système d'exploitation GNU-Linux/Le serveur de shell distant SSH]] et [[:en:OpenSSH]] ==

Votre motivation ici. ~~~~

3.

Pensez à informer le(s) contributeur(s) principal(ux) de la page.

Utilisez ce texte :

{{subst:Avertissement fusion|Le système d'exploitation GNU-Linux/Le serveur de shell distant SSH|:en:OpenSSH|7=~~~~}}

On peut l'utiliser pour se connecter à une machine distante comme avec telnet, pour transférer des fichiers de manière sécurisée ou pour créer des tunnels. Les tunnels permettent de sécuriser des protocoles qui ne le sont pas en faisant passer les données par une connexion SSH.

Le système de clés de SSH

Cryptographie asymétrique

SSH utilise la cryptographie asymétrique RSA ou DSA. En cryptographie asymétrique, chaque personne dispose d'un couple de clé : une clé publique et une clé privée. La clé publique peut être librement publiée tandis que chacun doit garder sa clé privée secrète. La connaissance de la clé publique ne permet pas d'en déduire la clé privée.

Si la personne A veut envoyer un message confidentiel à la personne B, A crypte le message avec la clé publique de B et l'envoie à B sur un canal qui n'est pas forcément sécurisé. Seul B pourra décrypter le message en utilisant sa clé privée.

Cryptographie symétrique

SSH utilise également la cryptographie symétrique. Son principe est simple : si A veut envoyer un message confidentiel à B, A et B doivent d'abord posséder une même clé secrète. A crypte le message avec la clé sécrète et l'envoie à B sur un canal qui n'est pas forcément sécurisé. B décrypte le message grâce à la clé secrète.

Toute autre personne en possession de la clé secrète peut décrypter le message.

La cryptographie symétrique est beaucoup moins gourmande en ressources processeur que la cryptographie asymétrique, mais le gros problème est l'échange de la clé secrète entre A et B. Dans le protocole SSL, qui est utilisé par les navigateurs Web et par SSH, la cryptographique asymétrique est utilisée au début de la communication pour que A et B puissent s'échanger une clé secrète de manière sécurisée, puis la suite la communication est sécurisée grâce à la cryptographie symétrique en utilisant la clé secrète échangée.

Configuration du serveur SSH

Pour manipuler le daemon (le lancer, l'arrêter, recharger la configuration...), on utilise la commande

/etc/init.d/ssh

Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config. À ne pas confondre avec /etc/ssh/ssh_config qui est le fichier de configuration du client SSH.

Parmi les multiples options, on peut noter :

Port 22: Signifie que le serveur SSH écoute sur le port 22, qui est le port normal de SSH. Il est possible de le faire écouter sur un autre port en changeant cette ligne.
Protocol 2: Signifie que le serveur SSH accepte uniquement la version 2 du protocole SSH. C'est une version plus sécurisée que la version 1 du protocole. Pour accepter les deux protocoles, change la ligne en : Protocol 2,1
PermitRootLogin no: Signifie que l'on ne peut pas se logger en root par SSH. Pour se logger en root, il suffit de se logger en utilisateur normal et d'utiliser la commande su.
X11Forwarding yes: Autorise le transfert par SSH de l'affichage graphique.
LoginGraceTime 600: Temps de connexion maximum
RSAAuthentication yes: Méthode d'authentification.
AuthorizedKeysFile .ssh/authorized_keys fichier utilisé pour 'l'autologin'
PermitEmptyPasswords no: permet ou non les mots de passe vide

Si le fichier de configuration du serveur a été modifié, il faut indiquer au démon sshd de relire son fichier de configuration, avec la commande /etc/init.d/ssh restart.

Se logguer par SSH

Deux types d'authentification sont possibles : par mot de passe et par clé. Dans les deux cas on utilise une des commandes suivantes :

ssh -l <login> <adresse du serveur SSH> 
ssh <login>@<adresse du serveur SSH>

Authentification par mot de passe

C'est la méthode la plus simple. Lors de la connexion, le client ssh demande le mot de passe du compte. Dans ce cas, ssh chiffre le mot de passe ce qui évite de le voir circuler en clair sur le réseau.

Authentification par clé

Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clés privée/publique, comme le fait le serveur SSH auprès du client SSH. La clé publique est placée sur le serveur dans le home du compte sur lequel on souhaite se connecter. La clé privée reste sur le poste client. Dans ce cas, aucun mot de passe ne circule sur le réseau.

Générer une clé

Pour générer un couple de clés, on utilise la commande :

ssh-keygen -t rsa

Deux clés vont être générées, une clé publique (par défaut ~/.ssh/id_dsa.pub) et une clé privée (par défaut ~/.ssh/id_dsa). C'est la clé publique qu'il faudra copier sur le serveur.

Les clés générées ont par défaut une longueur de 1024 bits, ce qui est aujourd'hui considéré comme suffisant pour une bonne protection.

La commande demande un nom de fichier pour sauvegarder la clé privée et un nom de fichier pour sauvegarder la clé publique. Par défaut, la clé privée est stockée dans le fichier $HOME/.ssh/id_dsa.

La clé privée est enregistrée avec les permissions 600. La clé publique porte le même nom de fichier suivi de ".pub", avec les permissions 644.

Lors de la création de la clé, l'utilitaire demande une pass phrase qui est un mot de passe pour protéger la clé privée (2eme protection). Cette pass phrase sert à crypter la clé privée. La pass phrase sera alors demandée à chaque utilisation de la clé privée, c'est à dire à chaque fois que vous vous connecterez en utilisant cette méthode d'authentification. Un mécanisme appelé ssh-agent permet de ne pas rentrer le mot de passe à chaque fois (voir les docs).

Il est possible de changer la pass phrase qui protège la clé privée avec la commande ssh-keygen -p.

Autoriser sa clé publique

Pour autoriser une clé à se connecter à un compte, il faut placer sa partie publique dans le fichier $HOME/.ssh/authorized_keys du compte en question, sur le serveur SSH. Si vous souhaitez vous connecter au serveur sur le compte sasa, le fichier est /home/sasa/.ssh/authorized_keys.

Pour transférer la clé publique, on peut utiliser ftp, scp (copie de fichier par ssh), ou un simple copier/coller entre deux terminaux (c'est simplement une longue ligne de caractères ASCII).

Chaque ligne du fichier authorized_keys correspond à une clé publique autorisée à se connecter. Il faut vérifier que chaque clé est bien sur une seule ligne, sinon ça ne fonctionne pas.

Le répertoire $HOME/.ssh' devrait être protégé en écriture, avec les permissions 755 (ou 705). De la même manière, le fichier authorized_keys ne doit pas être lisible par tous (600 par exemple).

Ensuite, pour se logger, il suffit de procéder comme précédemment.

Si la clé privée a été enregistré dans un autre fichier que $HOME/.ssh/id_dsa, il faut le préciser au client ssh :

ssh -i <nom du fichier contenant la clé privée> <login>@<serveur>

Agent SSH

Un agent SSH est un programme qui garde en mémoire des clés privées. Le principe est le suivant :

on lance un agent
on lui ajoute des clés (si les clés sont cryptées, elles sont décryptées avec la passphrase avant d'être ajoutées)
à chaque connexion ssh, les clé de l'agent sont utilisées en priorité

Les avantages principaux sont :

que la passphrase n'est demandée qu'une seule fois au moment où elle est ajoutée à l'agent,
et que l'agent est capable de faire suivre la clé sur plusieurs connexions.

Pour lancer un agent on utilise généralement une commande qui ressemble à :

ssh-agent /bin/bash

L'agent SSH lance un nouveau shell ("/bin/bash") dans lequel il sera actif. Il ne sera utilisable qu'à partir de ce shell et dans les programmes qui y seront lancés.

Pour ajouter une clé on utilise

ssh-add [<fichier>]

Si on ne précise aucun fichier, il utilisera la clé par défaut ("~/.ssh/id_dsa" pour SSH 2).

Si la clé est crypté, la passphrase sera demandée et la clé décryptée sera ajoutée à l'agent.

Toutes les connexions SSH (avec ssh, scp...) lancées à partir de ce shell utiliseront l'agent et ne demanderont donc plus la passphrase.

Depuis Windows

Pour se connecter en SSH à un serveur Linux sous Windows, il existe le logiciel gratuit Putty^{Télécharger}.

Une fois lancé, dans le champ Host Name (or IP address), rentrer l'adresse IP ou le nom d'hôte du serveur distant. Le port est par défaut (et par norme) égal à 22 en protocole SSH.

Lors de la première connexion, un security warning peut être affiché, il faut juste cliquer sur oui.

Les options de connexion du menu de gauche permettent éventuellement d'enregistrer un mot de passe ou une clé SSH de connexion, afin de se connecter en quelque clics.

Sinon, des émulateurs Unix comme Cygwin ou Git Bash peuvent exécuter la commande ssh.

Créer un "tunnel" crypté entre deux stations

SSH est également capable de fournir un encryptage à d'autres services (ftp par exemple) par le biais du port forwarding.

(options -L et -R de la commande ssh), de la manière suivante:

Considérons deux stations HOST1 et HOST2. Supposons que sur la machine HOST1, vous utilisiez la commande :

ssh -L p1:HOST2:p2 HOST2

ou sur HOST2:

ssh -R p1:HOST2:p2 HOST1

alors vous obtenez un tunnel sécurisé dans lequel vous pouvez passer toute connexion, lesquelles seront automatiquement cryptées.

Sur HOST1, ssh -L p1:HOST2:p2 HOST2 signifie, que lorsqu'on se connecte au port p1, les paquets sont retransmis vers le port p2 de la machine HOST2 via HOST2.