SSH : telnet sécurisé et bien plus encore

23 avril 2006

SSH (Secure Shell) est une application réseau utilisée pour les connexions distantes sécurisées. En effet, ssh permet non seulement une connexion distante mais permet également le transfert de fichier et la redirection de ports cryptée. Nous allons ici nous intéresser à la version libre de SSH : OpenSSH (www.openssh.org). SSH utilise le port 22/tcp. Il est basé sur un principe de clef public et privé.

I.Fonctionnement

SSH se sert de chiffrement à clé publique pour l'authentification et de chiffrement à clé privée pour la communication : c'est le principe des clés de session.

a)Types de clés

SSH utilise plusieurs types de clés :

• les « user key » permettent de se connecter avec authentification par clés publiques. Elles sont générées par l'utilisateur (une paire publique/privée) de façon permanente et donc stockées dans une fichier.

• les « host key » permettent d'identifier les machines entre elles. C'est l'administrateur qui les génère (une paire publique/privée) et les installe dans un fichier.

• Les « server key » permettent de transmettre les clés de session dans la version 1 de SSH. Elles sont régénérées toutes les heures et stockées uniquement en mémoire.

• Les « session key » servent pour l'algorithme de chiffrement symétrique utilisé pour la communication (le ou les canaux sécurisés). Elle(s) est (sont) générée(s) à chaque connexion. Il en existe une par sens de communication pour chaque connexion dans la version 2 de SSH (donc 2 clés) contre une seule pour la version 1 (donc une seule pour les deux sens).

En plus de ces clés, SSH permet de crypter avec un algorithme symétrique toutes les paires de clés afin de les protéger. Pour cela, il demande une passphrase et crypte la clé privée avec.

b)Protocoles SSH version 1 et SSH version 2

Il existe deux versions, bien évidemment incompatibles, du protocole SSH : les versions 1.x (1.3 et 1.5), et la version 2.0. Tant que le serveur et le client supportent la même version du protocole, l'utilisateur ne s'aperçoit de rien.

Dans la version 1, le protocole est défini en une seul et unique couche, tandis que dans SSH version 2, on distingue en trois « couches » (dans le même esprit que la division de la couche Liaison de la pile TCP/IP):

1. SSH Transport Layer Protocol (SSH-TRANS) : elle prend en charge l'intégrité des données transitant par le canal, le chiffrement de celles-ci et leur éventuelle compression et enfin l'authentification des machines entre elles.

2. SSH Authentication Protocol (SSH-AUTH) : elle prend en charge ... l'authentification (mot de passe, par hôte, clés publiques et autres)

3. SSH Connection Protocol (SSH-CONN) : elle assure la gestion du tunnel (shell, agent SSH, redirection de ports, contrôle de flux).

On trouvera tous les détails normalisés à l'adresse (et possiblement immangeables) : http://www.ietf.org/html.charters/secsh-charter.html

Les différences techniques essentielles entre les versions 1 et 2 sont :

SSH version 1	SSH version 2
conception en une seule couche	séparation des couches authentification, connexion et transport
Intégrité des données via CRC32 (peu fiable)	intégrité via HMAC (hash cryptographique)
un UNIQUE canal par session	nombre indéterminé de canaux par session
négociation du seul chiffrement symétrique du tunnel et de la clé de session UNIQUE pour les deux sens de communication du canal	négociations plus détaillées (chiffrement symétrique, clé-publiques, compression, ...) et une clé de session par sens de communication ainsi que le choix de la compression et de l'intégrité aussi par sens
RSA seulement pour l'algorithme à clés-publiques	RSA et DSA pour l'algorithme à clés-publiques
clé de session transmise par le client	clés de session négociées avec un protocole Diffie-Hellman
clé de session valable pour toute la session	clés de session renouvelées

A partir de maintenant je considérerai principalement la version 2 du protocole SSH.

c)Etapes de connexion

Une connexion SSH se fait en plusieurs étapes :

• accord sur les moyens de transmission : le serveur envoie une liste au client qui renvoie son choix. Cela permet au client et au serveur de s'entendre sur :

  • la version de SSH

  • l'algorithme de chiffrement (SSH en supporte beaucoup)

  • l'algorithme de compression

  • le type d'authentification

• Le serveur envoie sa clé d'hôte (/etc/ssh/ssh_host_key.pub ou /etc/ssh/ssh_host_dsa_key.pub ou /etc/ssh/ssh_host_rsa_key.pub) afin de s'authentifier vis à vis du client. Si le client connaît la clé il poursuit la connexion, sinon, il demande à l'utilisateur s'il est sûr de connaître le serveur auquel il veut se connecter. Une empreinte (un hash) de la clé est fournie avec la clé. Il serait alors nécessaire de vérifier auprès du responsable du serveur que l'empreinte est la bonne. La clé d'hôte du serveur sert à crypter la clé de session du sens serveur vers client.

• Réciproquement, le client envoie sa clé d'hôte afin de crypter la clé de session du sens client vers serveur.

• Puis on utilise le principe des clés de session à la différence près qu'il y a deux clés de session du moins dans la version 2. Dans la version 1, les clés de session sont cryptées avec la clés d'hôte puis avec la clé de serveur du serveur. Pour crypter les clés de session, on utilise le système RSA (SSH version 1 et 2) ou DSA (SSH version 2). Dans la version 2, il y a une clé de session par sens de circulation des données. Ces clés sont générées à chaque connexion et parfois régénérées pendant la connexion.

A partir de cette étape, les communications sont cryptées dans les deux sens.

• authentification de l'utilisateur client un des deux types de méthodes :

  • les méthodes par mot de passe : plus faible protection car le mot de passe est censé être relativement court.

  • les méthodes par clé publique : plus fort pour deux rasions. Partant d'une clé publique, il est impossible de deviner la clé privée. Les passphrases utilisées pour crypter les clés privées sont censées être relativement longs.

• Une fois l'authentification effectuée et la clé privée aléatoire échangée, on utilise un système à clé privée pour le cryptage des données. Il en existe un grand nombre. Par défaut : 3DES.

d)Types d'authentification

Il existe principalement quatre types d'authentification pour SSH :

• authentification par mot de passe : le client soumet son login et son mot de passe comme sur une connexion par console. Le login/mot de passe sont ceux configurés dans PAM (et donc principalement dans /etc/passwd et /etc/shadow).

• authentification par clé publique de client : le client soumet son login et un sceau de sa clé publique (.ssh/id_dsa.pub ou .ssh/id_rsa.pub) au serveur, c'est à dire un hash de sa clé publique crypté avec sa clé privée. C'est à ce moment, si la clé privée est cryptée localement que SSH demande la passphrase qui a servie à l'encryption de cette clé. Il regarde dans le fichier .ssh/authorized_keys du dossier de l'utilisateur passé en login pour voir si une des clés publiques envoyées peut décrypter le sceau reçu et correspondre à ce hash décrypté. La procédure d'installation de la clé publique est la suivante :

  • on génère une paire de clé privée/publique sur la machine client: elle peut ou pas être protégé par une passphrase : ssh-keygen -t dsa.

  • On garde la clé privée générée dans le dossier : ~/.ssh

  • On place la clé publique (fichier .pub) dans le fichier ~/.ssh/authorized_keys

  • A la prochaine reconnexion, la passphrase sera demandée à la place du mot de passe.

• authentification par challenge : le client soumet son login et le serveur lui envoie un hash d'un texte crypté à déchiffrer. Il est nécessaire, pour cela, de transmettre la clé publique du client au serveur dans son dossier de connexion distant dans le fichier .ssh/authorized_keys. Le client décrypte le challenge avec sa clé privée pour s'authentifier et le renvoie au serveur. C'est à ce moment, si la clé privée est cryptée en locale que la passphrase d'encryption est demandée. Si le hash que le serveur reçoit en retour correspond à celui envoyé par le serveur, c'est que le client a la bonne clé privée donc que c'est bien lui.

  • Dans le fichier de configuration du serveur, on met ChallengeResponseAuthentication à yes.

• authentification par hôte : C'est le même principe que pour l'authentification par clé publique mais en envoyant la clé publique d'hôte. Le serveur regarde alors dans son fichier /etc/ssh/ssh_known_hosts pour voir s'il possède une ligne avec le nom de la machine cliente et la clé publique correspondante (/etc/ssh/ssh_host_key.pub sur le client) qui permette de décrypter le hash reçu afin qu'il corresponde au hash de cette clé. Si oui, l'utilisateur est autorisé à se connecter car sa machine est connue. Si la clé n'est pas présente ou est différente, l'authentification échoue.

  • Le fichier doit être préparé par l'administrateur afin de ne contenir les clés publiques des seuls machines autorisées à se connecter. Si pour un nom de machine la clé installée et la clé réelle sont différente, l'utilisateur de la machine ne pourra pas se connecté à la machine. Si une machine non référencée se connecte, elle n'aura pas l'authentification par clé mais par mot de passe.

  • Le format des fichiers /etc/ssh/ssh_known_hosts et .ssh/known_hosts est le suivant pour la version 2 :

    • liste de noms de machines séparés par des virgules

    • ssh-dss ou ssh-rsa suivant le type de clé DSA ou RSA

    • la clé

  • On peut aussi rajouter une couche qui est réalisée par les fichiers /etc/shosts.equiv et les fichiers ~/.shosts sur le serveur. Ces fichiers contiennent des listes d'association de nom de machine et nom d'utilisateurs autorisés à se connecter sur le serveur.

On peut autoriser un ou plusieurs de ces types d'authentification. Sshd essayera en priorité le type le plus sûr et si le client ne veut pas de ce type d'authentification, il descendra le niveau de sécurité vers une autre méthode d'authentification.

Lorsque la clé publique du serveur n'est pas connue, le client demande à l'utilisateur s'il est sûr de vouloir se connecter au serveur. Si l'option StrictHostKeyChecking yes est indiquée dans le fichier ssh_config, alors si la clé n'est pas présente ou différente dans l'un des fichiers known_hosts du client, celui-ci se voit refuser la connexion.

Lorsque l'authentification réussi, la clé publique du serveur auquel on se retrouve connecté est ajoutée au fichier .ssh/known_hosts. Si la clé du serveur a changé à la prochaine connexion, il faudra supprimer la clé du serveur pour pouvoir tenter de se connecter au serveur. Cela permet d'être averti que la clé du serveur a changé : cela peut venir d'un formattage, d'un changement de serveur ou d'un pirate « man-in-the-middle » où une autre personne cherche à se faire passer pour le serveur.

Les types d'authentification autorisés se règlent dans le fichier /etc/ssh/sshd_config par les directives (détaillées plus bas) :

• PasswordAuthentication : indique l'autorisation de l'authentification par mot de passe

  • AuthorizedKeysFile permet de régler le fichier qui contient les clés publiques des utilisateurs autorisés à se connecter à la machine.

• HostbasedAuthentication : indique l'autorisation de l'authentification par clé publique d'hôte

• ChallengeResponseAuthentication : indique l'autorisation de l'authentification par challenge

• PubkeyAuthentication/RSAAuthentication : indique l'autorisation de l'authentification par clé publique de client

e)Algorithmes cryptographiques utilisables

SSH supporte les algorithmes de cryptographie suivants :

• DES : Data Encryption Standard est un chiffrage par blocs de 64 bits. SSH version 1. Peu sûr.

• 3DES : Le triple DES est une amélioration de DES qui applique DES 3 fois. SSH version 1 et 2. Il doit être implémenté et est le système par défaut.

• IDEA : International Data Encryption Algorithm est une méthode rapide d'encryption. SSH version 1.

• BLOWFISH : C'est un autre chiffrage par blocs de 64 bits qui peut être utilisé à la place de DES ou IDEA. SSH version 1 et 2.

• TWOFISH, ARCFOUR et CAST128-CBC. SSH version 2.

• AES : il est conçu pour SSH : il devrait être choisi de préférence

f)Etapes d'une connexion après une authentification réussie

Lorsqu'un utilisateur se connecte avec succès, sshd procède comme suit :

• Si la connexion est sur un terminal et qu'aucune commande n'a été spécifiée, affiche la date de dernière connexion et le contenu du fichier /etc/motd (si accepté dans le fichier de configuration ou en l'absence de $HOME/.hushlogin).

• Si la connexion est sur un terminal, enregistre la date et l'heure de connexion.

• Vérifie le fichier /etc/nologin ; s'il existe, en affiche le contenu et sort (sauf pour root).

• Bascule pour s'exécuter avec les privilèges d'un utilisateur normal.

• Paramètre un environnement de base.

• Lit le contenu du fichier $HOME/.ssh/environment s'il existe. Ce fichier contient les variables d'environnement spécifiques à l'utilisateur connecté

• Va dans le répertoire de l'utilisateur (home directory). Il ne se chroot pas dedans.

• Si le fichier $HOME/.ssh/rc existe, l'exécute ; sinon, si le fichier /etc/ssh/sshrc existe, l'exécute ; sinon, exécute xauth. Les fichiers « rc » reçoivent le protocole d'authentification et le cookie X11 en entrée standard. C'est une étape antérieur et indépendante de tout bashrc ou profile du shell invoqué dans l'étape suivante.

• Exécute l'interpréteur de commandes (shell) indiqué dans /etc/passwd ou la commande.

II.Installation

Vérifier d'abord que ssh est bien installé sur votre systeme, le client ainsi que le serveur, ssh nécessite ssl (openssl).

[root]# rpm -q openssl openssh

Pour pouvoir se connecter en ssh depuis une machine extérieur sur son ordinateur, il faut :

[root]# yum install openssh-server

[root]# service sshd start

[user]$ ssh hôte.domaine

III.Fichier de ssh et sshd

Ssh et sshd utilisent les fichiers suivants :

• /etc/ssh_config et /etc/sshd_config : ces fichiers contiennent la configuration de ssh et de sshd

• /etc/ssh_host_dsa_key et /etc/ssh_host_dsa_key.pub : ces fichiers contiennent les clés privée et publique de SSHv2 de type DSA

• /etc/ssh_host_rsa_key et /etc/ssh_host_rsa_key.pub : ces fichiers contiennent les clés privée et publique de SSHv2 de type RSA

• /etc/ssh_host_key et /etc/ssh_host_key.pub : ces fichiers contiennent les clés privée et publique de SSHv1

• $HOME/.ssh/authorized_keys : ce fichier contient la liste des clés des utilisateurs autorisés à se connecter avec le login de $HOME au serveur SSH

• /etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts :

• $HOME/.ssh/environment : ce fichier peut contenir uniquement des définitions de variables d'environnement

• $HOME/.ssh/rc : ce fichier est exécuté par /bin/sh avant de démarrer le shell de l'utilisateur du login.

• /etc/ssh/sshrc : idem que le fichier précédent

Les fichiers de clés privées doivent avoir les droits 600 sinon sshd ne démarre pas.

IV.Configuration

Les différents fichiers de configuration se trouvent dans /etc/ssh/, voici les différents paramètres de configuration possibles pour le serveur ainsi que pour le client (sshd_config et ssh_config) :

a)Serveur SSH

• Fichier /etc/ssh/sshd_config : configuration du serveur

Option	Description
AllowGroups liste	Suivi de la liste des groupes autorisés à se connecter au serveur (peut contenir * ou ?)
AllowUsers liste	Suivi de la liste des utilisateurs autorisés à se connecter au serveur (peut contenir * ou ?)
AuthorizedKeysFile path_filename	Chemin et nom de fichier absolu ou relatif au dossier de l'utilisateur, qui contient la liste des clés publiques recevables pour une identification par challenge ou clé publique
ClientAliveInterval number	Nombre de secondes d'inactivité avant test de réponse du client
DenyGroups liste	Suivi de la liste des groupes interdits de se connecter au serveur (peut contenir * ou ?)
DenyUsers liste	Suivi de la liste des utilisateurs interdits de se connecter au serveur (peut contenir * ou ?)
GatewayPorts port_number	Indique si les ports forwardés par le clients sur le serveur sont visible de l'extérieur du serveur (yes) ou non (no).
HostKey path_filename	Indique le chemin de la clé privée du serveur
IgnoreUserKnownHosts yes|no	Indique au serveur sshd de na pas tenir compte des fichiers de machines connus dans les répertoires des utilisateurs.
ListenAddress IP	Adresse sur laquelle le serveur écoute
LoginGraceTime number	Délai en secondes pour l'authentification
PermitRootLogin yes|no	Indique si root peut se connecter en ssh sur le serveur (yes ou no)
Port port_number	Spécifie le port d'écoute pour les connexions SSH au serveur
Subsystem subsys_name commandline	Met en place un sous système hébergé par sshd (par ex : sftp)
UsePrivilegeSeparation yes|no	Indique si sshd diminue ses privilèges à ceux de l'utilisateur connecté (yes) ou reste root (no)
UsePAM yes|no	Permet d'utiliser PAM pour l'authentification. Dans ce cas, il faut choisier entre PasswordAuthentication et ChallengeResponseAuthentication
Authentification
PasswordAuthentication yes|no	Indique si l'authentification par mot de passe est autorisé
HostbasedAuthentication yes|no	Indique si l'authentification par hôte est autorisée
PubkeyAuthentication/RSAAuthentication yes|no	Indique si l'authentification par clés publique est autorisée
ChallengeResponseAuthentication yes|no	Indique si l'authentification par challenge est autorisée

b)Client SSH

• Fichier /etc/ssh/ssh_config ou ~/.ssh/config : configuration du client

Option	Description
Host nom_machine	Indique que toutes les autres options qui se trouvent en dessous de ce tag sont relatifs à nom_machine (jusqu'à la fin ou au prochain Host). nom_machine peut comprendre * et ? pour donner un pattern.
GatewayPorts yes ou no ou IP_locale	Autorise les autres machines à se connecter à tous les ports forwardés.
HostName nom_machine	Nom de la machine à laquelle on veut se connecter.
LocalForward port_connexion_locale serveur_distant:port_serveur_distant	Une fois la connexion SSH mise en place, on pourra se connecter à localhost:port_connexion_locale ce qui représente en fait une connexion à serveur_distant:port_serveur_distant par le canal sécurisé.
RemoteForward port_serveur_local serveur_local:port_connexion_distante	Une fois la connexion SSH mise en place, une personne, ayant accès au serveur auquel vous êtes connecté, pourra se connecter à localhost:port_connexion_distante ce qui représentera en fait une connexion à port_serveur_local:serveur_local
NumberOfPasswordPrompts number	Nombre de fois que l'on autorise une erreur d'authentification à la connexion avant de stopper la connexion.
Port port	Indique le port de connexion sur la machine distante
StrictHostKeyChecking yes ou no	Refuse ou pas la connexion à des machines dont la clé a changé depuis la dernière connexion.
User username	Indique le nom de l'utilisateur sur la machine distante.

c)Port forwarding et authentification d'hôte

Si vous êtes amené à vous connecter à la fois sur une passerelle et sur une machine se trouvant derrière la passerelle (celle-ci faisant un port forwarding entre, par exemple, son port 2222 et le port 22 de la machine interne), vous allez rencontrer un problème. En effet, la première fois que vous vous connecter en SSH à une machine, votre client SSH associe (de façon cryptée) son IP avec la clé publique d'hôte de la machine contactée mais pas avec le numéro de port (dans le fichier ~/.ssh/known_hosts). Lorsque vous allez vous connecter, à la machine interne par le port 2222 de la passerelle (ssh -p 2222 passerelle), le client SSH va enregistrer l'IP de la passerelle associée avec la clé d'hôte de la machine interne. Si vous vous connecter ensuite directement à la passerelle sur son port 22, vous allez obtenir un message d'erreur vous disant que la clé d'hôte a changée et vous ne pourrait pas vous connecter.

Il faudra donc mettre la configuration suivante dans votre fichier ~/.ssh/config :

Host passerelle

Hostname nom_DNS_passerelle

CheckHostIP no

Port 22

HostKeyAlias passerelle

Host machine_interne

Hostname nom_DNS_passerelle

CheckHostIP no

Port 2222

HostKeyAlias machine_interne

Ensuite, il vous suffira de taper ssh passerelle ou ssh machine_interne pour vous connecter à la bonne machine.

CheckHostIP no permet de ne pas vérifier l'IP de la machine à laquelle on se connecte. Utile si la passerelle a une IP dynamique.

HostKeyAlias permet de donner un nom à la clé afin qu'elle soit associée à ce nom et non à l'IP de la machine distante.

V.Utilisation

d)Connexion à la telnet : commande ssh

Pour se connecter, il suffit de taper :

[user]$ ssh utilisateur@hôte

On peut aussi utiliser l'option -l pour spécifier le nom d'utilisateur distant.

Les options -v, -vv et -vvv permettent, en cas d'erreur par exemple, de voir ce que fait ssh pendant la connexion.

e)Copie de fichiers ponctuellement : commande scp

Pour copier un fichier se trouvant sur une machine accessible en ssh :

[user]$ scp user@serveur:fichier_source fichier_destination

Les options suivantes peuvent être utiles :

• -p : préserve les attributs, les droits et les permissions des fichiers copiés

• -r : copie récursivement un répertoire

• -C : compresse les données avant la copie pour gagner du temps de transfert

f)FTP sécurisé de SSH : commande sftp

Note : SFTP n'est pas une version de FTP sécurisée à travers SSH mais bien un protocole à part entière qui reprend une grande partie des commandes FTP.

Il existe aussi un « mode ftp » sftp. Elle a les mêmes commande que la commande ftp.

[user]$ sftp serveur

sftp> ls

sftp> bye

Il existe des clients SFTP graphiques comme lftp ou krusader.

g)SSH et les tubes

1Principe

On peut se servir de SSH pour exécuter une commande à distance en lui passant un contenu local sur son STDIN distant et récupérer le résultat de la commande localement :

[user]$ ssh utilisateur@machine_distante « commande » < fichier_stdin > fichier_stdout

ou

[user]$ commande | ssh utilisateur@machine_distante « commande » | commande

ou n'importe quelle autre combinaison de > , < ou |

2Exemple : sauvegarde de données

On peut par exemple faire une sauvegarde distante :

[user]$ ssh utilisateur@machine_distante « tar czf - dossier_distant » > sauvegarde.tar.gz

ou locale :

[user]$ tar czf - dossier_local | ssh utilisateur@machine_distante « cat sauvegarde.tar.gz »

Le - dans la commande tar sert à lui dire d'envoyer le contenu gzippé sur stdout au lieu de la mettre dans un fichier.

3Exemple : restauration de données

On peut par exemple faire une restauration distante :

[user]$ ssh utilisateur@machine_distante « tar xzf » < sauvegarde.tar.gz

ou locale :

[user]$ ssh utilisateur@machine_distante « cat sauvegarde.tar.gz » | tar xzf

h)Montage de partition par SSH

1FUSE

FUSE est un projet permettant de développer des modules de systèmes de fichiers dans la ring 3 (utilisateur) et non dans le ring 0 (noyau). Cela permet notament d'éviter les kernels panics lors du dysfonctionnement d'un module.

Pour installer ce module, reporter vous à la page d'installation du site du projet : http://fuse.sourceforge.net.

Pour pouvoir monter et démonter des partitions avec FUSE vous devez vous ajouter dans le groupe fuse. (en root, éditer le fichier /etc/group et ajouter vous à la fin de la ligne commençant par fuse).

2SSHFS

SSHFS vous permet de monter des dossiers distants au travers d'un canal SSH.

Pour l'installer, reportez vous à la page suivante : http://fuse.sourceforge.net/sshfs.html

Pour monter un dossier distant :

[user]$ mkdir point_montage

[user]$ sshfs utilisateur@machine_distante:/chemin/dossier point_montage

Pour démonter :

[user]$ fusermount -u machine_distante

VI.Configuration d'une authentification par clés

Vous avez pu constater que ssh utilise toujours le mot de passe comme identification. Or cette méthode n'est pas très sécurisée. Il existe un autre mode de fonctionnement utilisant des clés publics et privés. Pour générer une paire de clés utilisez la commande ssh-keygen -t dsa. Cette commande vous demande une passphrase qui se doit d'être une phrase relativement longue. Une fois cette commande tapée vous avez deux clés de générées dans le répertoire .ssh/.

a)Génération d'une paire de clés pour l'authentification

Génération d'une paire de clés Privées/Publics :

[utilisateur votre_machine]$ ssh-keygen -t dsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/utilisateur/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): votre_passphrase
Enter same passphrase again: encore_votre_passphrase
Your identification has been saved in /home/utilisateur/.ssh/id_rsa.
Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub.
The key fingerprint is:
25:d1:ff:34:da:ef:2b:ed:9e:95:04:bc:56:81:2a:3c utisateur@votre_machine

Pendant la génération de la paire de clé et afin de protéger (encrypter) la clé privée, une passphrase vous sera demandée. Elle sert en quelque sorte de mot de passe. Elle doit être une vraie phrase donc relativement longue. Attention, vous ne voyez pas ce que vous tapez, donc faites bien attention.

b)Configuration sur la machine distante

Dans les deux cas suivant, ce sera bien sûr le mot de passe qui vous sera demmandé et pas la passphrase de la clé que vous copiez.

Il existe deux méthodes pour transférer sa clé publique dans son répertoire distant :

• ssh-copy-id -i nom_fichier_clé.pub serveur : méthode automatique : copie automatiquement le contenu du fichier nom_fichier_clé.pub dans le fichier .ssh/authorized_keys de votre répertoire de connexion sur le serveur serveur. nom_fichier_clé.pub peut prendre la valeur : .ssh/identity.pub (SSHv1), .ssh/id_rsa.pub (SSHv2 et ssh-keygen -t rsa) ou .ssh/id_dsa.pub (SSHv2 et ssh-keygen -t dsa).

• à la main :

La clé public est dans le fichier ~/.ssh/id_dsa.pub et la clé privée dans ~/.ssh/id_dsa. Cette dernière doit normalement avoir les droits 0600 (lecture et écriture pour vous seulement).

Il suffit alors d'envoyer la clé public dans votre répertoire de connexion sur le serveur distant, puis d'exécuter la commande suivante :

[user]$ cat id_dsa.pub >> ~/.ssh/authorized_keys.

Dans le fichier authorized_keys, en début de chaque ligne, vous pouvez ajouter une ou plusieurs des options suivantes :

options	Définition
from="liste"	Liste de machines depuis lesquelles on est autorisé à se connecter, séparées par des virgules
command="commande"	Commande à exécuter à la connexion
no-port-forwarding	Interdit le Port Forwarding. Voir plus bas.
no-X11-forwarding	Interdit la redirection X11 (pas de connexion en graphique possible)
permitopen="host:port"	Limite le forwarding le Port Forwarding vers/depuis host:port. On peut en mettre plusieurs permitopen en les séparant par des virgules.

c)Connexion et authentification

Maintenant lorsque vous vous connectez sur la machine distante sur votre compte, vous n'avez plus besoin de rentrer votre mot de passe mais la passphrase que vous a demandé ssh-keygen.

Le contenu du fichier /etc/motd peut être affiché et la date et ehure de votre connexion loggé.

d)Simplification des connexions multiples

Toutefois, cette méthode nécessite de retaper à chaque fois votre passphrase ce qui peut être fastidieux si vous utilisez plusieurs connexions. Pour remédier à ce problème il existe un utilitaire ssh-agent qui peut s'occuper de l'authentification.

[utilisateur@machine dossier]$ ssh-agent $SHELL
[utilisateur@machine dossier]$ ssh-add
Enter passphrase for /home/utilisateur/.ssh/id_dsa:
Identity added: /home/utilisateur/.ssh/id_dsa (/home/utilisateur/.ssh/id_dsa)
[utilisateur@machine dossier]$ ssh-add -l
1024 61:42:00:98:0c:9b:4a:76:90:18:34:ef:09:12:45:fd /home/utilisateur/.ssh/id_dsa (DSA)
[utilisateur@machine dossier]$ ssh utilisateur@machine
Last login: Sat Apr  1 20:34:35 2006 from autre_machine
...
[utilisateur@machine dossier]$ exit

Cependant ssh-agent n'agit que pendant le temps de vie de la console donc pas après un redémarrage.

VII.Telnet et co

TELNET assure les mêmes fonctionnalités que SSH mais en version NON CRYPTE. CE PROTOCOLE EST DONC A PROSCRIRE POUR LES CONNEXIONS A DISTANCE à moins que l'appareil auquel on se connecte ne gère pas SSH (routeur, switch...). A noter que la commande telnet permet aussi de tester un service non crypté (non SSL) comme SMTP, POP ou IMAP.

Dans tous les cas, il faut vérifier que le service telnetd n'est pas présent dans le dossier /etc/xinetd.d. On devrait aussi désactiver le telnet de kerberos (krb5-telnet)...

VIII.Tunnels SSH

SSH permet également la création d'un tunnel crypté entre deux machines. SSH s'arrange pour multiplexer les données des différents tunnels et du tunnels par défaut (le contrôle à distance) pour assurer une sécurité à des protocoles non sécurisés.

Par exemple, pour mapper le port 110 du serveur machine.domain sur le port 3002 de la machine locale en passant par la machine autre_machine.domain sur laquelle vous avez un compte, et le tout de façon à ce que ce port 3002 soit accessible par le voisinage réseau de la machine locale (-g) :

[user]$ ssh -g -L 3002:machine.domain:110 user_distant@autre_machine.domain

Autre options intéressantes :

• option -N permet d'interdire l'exécution de commandes à distance, par exemple, si vous ne voulez que du port forwading.

• option -f permet de faire travailler ssh en tâche de fond, par exemple pour les tunnels.

La syntaxe suivante permet de faire fermer la connexion, par exemple dans le cas des tunnels, au bout d'un certain temps (en secondes) :

[user]$ ssh -f autres_options sleep nb_secondes

a)Principe de fonctionnement

Le tunneling est le fait de pouvoir accéder, en plus de la connexion Shell distante, à d'autres services comme le mail, le partage de fichier ou le FTP au travers de la connexion sécurisée établie avec le serveur.

Un tunnel SSH a un seul but : sécuriser des protocoles qui ne sont pas prévus à la base pour l'être : par exemple, SMTP, X...

Note : pour ne pas avoir à taper toutes les options à chaque fois, on peut utiliser le fichier de configuration /etc/ssh/ssh_config ou un fichier de configuration personnel que l'on passe en paramètre avec l'option -F. L'option -g permet d'exposer les « ports forwardés » à toutes les machines qui ont accès à votre machine, sinon ils ne seront accessibles que depuis la boucle locale.

Redirection locale de port

Cela permet d'accéder à des services exposés sur la machine distante (serveur SSHD auquel on est connecté) ou sur des machines internes au réseau du serveur SSHD : option -L port_connexion_locale:serveur_distant:port_serveur_distant. Une fois la connexion SSH mise en place, on pourra se connecter à localhost:port_connexion_locale ce qui représente en fait une connexion à serveur_distant:port_serveur_distant par le canal sécurisé.

Ceci autorise à se connecter à distance depuis l'extérieur, à sa machine située dans un réseau interne, à condition d'avoir un accès SSH sur un serveur exposé de ce réseau. Cela n'est pas possible si le réseau ne laisse pas passer les connexions entrantes ou que vous n'avez pas de compte SSH sur une serveur exposé.

Redirection distante de port

Cela permet d'exposer des services de la machine locale ou de son voisinage réseau sur le serveur auquel elle est connecté : option -R port_serveur_local:serveur_local:port_connexion_distante. Une fois la connexion SSH mise en place, une personne, ayant accès au serveur auquel vous êtes connecté, pourra se connecter à localhost:port_connexion_distante ce qui représentera en fait une connexion à port_serveur_local:serveur_local

Ceci autorise à se connecter depuis chez soi à se machine interne à plusieurs conditions :

• il faut que vous puissiez vous connecter en SSH sur votre machine qui se trouve chez vous, depuis une machine du réseau interne.

• Il faut que la connexion Internet entre les deux machines ne soit pas coupées.

IX.Redirection X11

La redirection X11 permet de faire passer la connexion entre le serveur X (situé sur le client SSH) et le client X (situé sur le serveur SSH) au travers du canal sécurisé de SSH. Cela permet de lancer une application graphique sur le serveur SSH et de voir le résultat sur l'écran du client SSH (ce que permet X11) et le tout d'une manière sécurisée (ce que permet SSH).

a)Configuration du serveur

Pour autoriser les clients SSH à rediriger les programmes graphiques sur leurs écrans (redirection X11), les directives suivantes doivent prendre la valeur yes :

• X11Forwarding doit être à yes pour autoriser la redirection X11 par le canal SSH

• X11UseLocalhost doit être à yes afin d'éviter les tentatives de hacks sur les clients liés à l'existance d'un serveur X proxy en sortie côté client du canal SSH. Cela n'autorise le serveur X proxy qu'à attendre les connexions sur la boucle locale (inaccessible depuis l'extérieur), ce qui permet au canal de communiquer avec lui mais pas au voisinage du client. Ceci peut se rapprocher en opposé à l'option -g qui permet d'exposer à l'extérieur les redirections de ports.

b)Configuration du client

Pour autoriser les clients à recevoir la redirection X11, le client doit :

• soit configurer la directive ForwardX11 yes dans le fichier /etc/ssh_config ou autre fichier de configuration personnel

• soit passer l'option -X en ligne de commande de ssh

c)Fonctionnement

D'abord, petite précision, pour X Window, le concept de client et serveur est inversé. Le client X est tout programme graphique lancé par le client sur le serveur SSH. Et le serveur X est le serveur tournant que le client qui permet l'affichage local au client. Voir tutoriel sur X.

Si le terminal depuis lequel on a appelé ssh dispose d'un affichage graphique :

• il extrait le cookie du fichier $HOME/.Xauthority afin de pouvoir s'authentifier plus tard pour communiquer avec le serveur X local

• il génère un cookie aléatoire pour fournir aux clients X sur le serveur SSH distant. Ce cookie servira à l'authentification des clients X sur le pseudo serveur X lancé sur le serveur SSH. En effet, il est plus sûr de ne pas transmettre le cookie réel d'authentification local pour ne pas permettre à un éventuel intru de récupérer ce cookie (par le système de fichier distant si les permissions sont mal réglées) et de se connecter directement au serveur X du client.

• il transporte ce cookie au travers du canal sécurisé et le transmet au serveur SSHD

• celui-ci lance un pseudo serveur X auquel les programmes graphiques lancés sur le serveur SSHD vont se connecter

• il place le cookie aléatoire reçu dans le fichier .Xauthority dossier de l'utilisateur connecté

• il règle la variable d'environnement DISPLAY pour pointer vers le pseudo serveur X lancé pour l'occasion (par exemple localhost:10.0 si le pseudo serveur X écoute sur le port 6010 du serveur SSH)

• ainsi, quand un programme veut se connecter pour recevoir les entrées clavier/souris et envoyer des commandes d'affichage au client :

  • il récupère le cookie aléatoire dans le fichier .Xauthority

  • il l'envoie au pseudo serveur

  • celui-ci le fait transiter par le canal sécurisé

  • le client SSH vérifie que c'est bien le cookie aléatoire qu'il a généré

    • si oui, il autorise le client X à se connecter au serveur X du client pour affichage et entrées

    • sinon, il s'agit sûrement d'un intrus qui veut se connecter au pseudo serveur pour accéder au client

  • une fois l'authentification réalisée, il retransmet tout le traffic venant

    • du client X au serveur X : le client X envoie ses données au pseudo serveur X de SSHD qui les envoie par le canal sécurisé. SSH les reçoit et les retransmet au vrai serveur X du client

    • du serveur X vers le client X : le serveur envoie ses données à SSH qui les transmet au pseudo serveur X de SSHD qui lui-même les retransmet au client X.

Note sur la sécurité de l'opération : il est très important que l'utilisateur connecté soit le seul (à part root) à pouvoir lire le fichier .Xauthority situé dans son répertoire de connexion, autrement dit avec les droits rw------- (600). Sans cela, n'importe qui qui aurait accès à ce fichier pourrait se connecter au pseudo serveur X du serveur SSHD et ainsi voir ce que voit le client SSH saisies souris et clavier compris.

Note technique :

• le pseudo serveur X est partie intégrante du serveur SSHD.

• du côté du client SSH, la connexion au serveur X local se fait par le biais d'un socket Unix (par exemple le fichier /tmp/.X11-unix/X0).

• du côté du pseudo serveur X et des clients X lancés sur le serveur SSHD, les connexions se font en TCP/IP sur le port 6000+unité_affichage_choisie sur l'interface lo (127.0.0.1). Ceci est du au fait que seul root peut créer ce type de socket dans ce répertoire.

d)Utilisation

Il est recommander d'utiliser l'option -C pour permettre la compression des données circulant dans le canal.

On peut l'utiliser de plusieurs manières :

• en ligne de commande unique : ssh -f -X -C serveur application_graphique. Cela permet de lancer en tâche de fond (-f) l'application_graphique. L'affichage se fera sur votre écran. La compression (-C) permettra d'accélérer l'affichage. La connexion SSH sera automatiquement fermée à la fermeture de l'application_graphique.

• On lance un ssh normal : ssh -X -C serveur. Puis une fois authentifié, on lance les programmes en tâches de fond : [user distant]$ application_graphique &.

Il est nécessaire de l'assurer (en cas de problème) que les précautions suivantes sont prises :

• S'assurer que la variable DISPLAY est bien initialisée sur la machine locale (dont vous avez la console sous les yeux), par exemple à :0.0

• S'assurer que le serveur SSH auquel on se connecte accepte de transférer les connexions X-Window. Voir section configuration.

• S'assurer que sur le client SSH le transfert X11 est activé. Voir configuration ou option -X.

• Sur la machine distante il faut bien faire attention de NE PAS y modifier la variable d'environnement DISPLAY initialisée par SSH

• SSH protège l'accès à ce pseudo-DISPLAY en plaçant une entrée adéquate dans votre fichier $HOME/.Xauthority sur la machine distante; il ne faut donc pas effacer cette ligne aussi longtemps que le DISPLAY correspondant est actif.

e)Mode Untrusted et Trusted

Le modèle de sécurité X11 fait une distinction entre des clients « trusted » et « untrusted ». Sans rentrer dans le détail, les clients X11 « untrusted » ne peuvent pas agir avec les fenêtre et ressources possédées par des clients « trusted ».

Depuis la version 3.8, OpenSSH supporte la sécurité X11 et fait une redirection X11 « untrusted » par défaut. Cependant, la plus part des applications quelles sont des clients X « trusted » et peuvent ne pas fonctionner correctement ou crasher de manière inattendue en mode « untrusted ». Il est seulement nécessaire de configurer la redirection X11 en mode « trusted » dans les cas précédents. Cela peut se faire de deux façons différentes suivant le caractère permanent à donner ou pas :

• Mode « trusted » au cas par cas : utiliser le commutateur -Y à la place de -X

• Mode « trusted » pour toutes les connexions : ajoute la ligne suivante au fichier ssh_config :
  ForwardX11Trusted yes

X.Et pour Windows...ben oui ça existe...

Le client PUTTY est un ssh gratuit pour Windows...sa configuration est graphique donc cela ne devrait pas poser de problèmes. SI vous voulez de la redirection X11, installer Cygwin en plus pour avoir un serveur X.

WinSCP est l'équivalent Windows de scp.

Bibliographie

Pages de man de ssh, sshd, ssh_config, sshd_config

OpenSSH

PuTTY: a free telnet/ssh client

Utilisation de SSH

Cryptographie - Secure Shell (protocole SSH)

SSH Filesystem

HSC - Brève - SSH et redirection X11

Relayage SSH