Version 1 du protocole SSH¶

Tout d'abord, si la machine à partir de laquelle l'utilisateur tente de se connecter est listée dans le fichier /etc/hosts.equiv ou le fichier /etc/ssh/shosts.equiv de la machine distante, et que les noms d'utilisateurs sont identiques des deux côtés, l'utilisateur est immédiatement autorisé à se connecter. Ensuite, si le fichier .rhosts ou .shosts existe dans le répertoire personnel de l'utilisateur sur la machine distante et qu'il contient une ligne avec le nom de la machine cliente et le nom de l'utilisateur sur cette machine, l'utilisateur est autorisé à se connecter. Cette méthode d'authentification utilisée toute seule est normalement refusée par le serveur parce qu'elle n'est pas sécurisée.

La seconde méthode d'authentification utilise les fichiers rhosts ou hosts.equiv avec une authentification par machine basée sur RSA. Ce qui signifie que la connexion est autorisée, si et seulement si la connexion est autorisée par les fichiers $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, ou /etc/ssh/shosts.equiv, et qu'en plus le serveur peut vérifier la clef d'hôte (cf. les fichiers /etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts dans la section FICHIERS ). Cette méthode d'authentification comble les failles de sécurité liées à l'usurpation d'adresses IP et la falsification de DNS ou de routage. [Note aux administrateurs : /etc/hosts.equiv, $HOME/.rhosts, et les protocoles rlogin/rsh en général ne sont pas sécurisés de par leur conception. Par conséquent, s'il y a un besoin de sécurité, il est judicieux de les désactiver.]

La troisième méthode d'authentification de ssh est une authentification basée sur RSA. Cette méthode utilise la cryptographie par clef publique : dans certains cryptosystèmes, on crypte et décrypte à l'aide de clefs différentes, et il n'est pas possible de déduire la clef de décryptage à partir de la clef de cryptage. Le système RSA fonctionne de cette manière. Chaque utilisateur crée une paire clef publique/clef privée à des fins d'authentification. Le serveur connaît la clef publique, mais seul l'utilisateur connaît sa clef privée.

Le fichier $HOME/.ssh/authorized_keys contient la liste des clefs publiques autorisée à se connecter. Quand un utilisateur se connecte, le programme ssh indique au serveur la paire de clefs qu'il souhaite utiliser lors de l'authentification. Le serveur vérifie si la clef est autorisée, et si c'est le cas, envoie à l'utilisateur (en fait, au programme ssh lancé par l'utilisateur) un défi (challenge) : un nombre aléatoire crypté à l'aide de la clef publique de l'utilisateur. Ce défi ne peut être décrypté qu'à l'aide de la bonne clef privée. Le client de l'utilisateur relève le défi en le décryptant à l'aide de la clef privée. Il prouve ainsi qu'il connaît la clef privée, mais il ne la révèle pas pour autant au serveur.

ssh implémente en standard le protocole d'authentification RSA. L'utilisateur peut créer une paire de clef RSA à l'aide du programme ssh-keygen(1). Ce programme enregistre la clef privée dans $HOME/.ssh/identity et la clef publique dans $HOME/.ssh/identity.pub dans le répertoire personnel de l'utilisateur. L'utilisateur peut alors copier identity.pub vers $HOME/.ssh/authorized_keys dans son répertoire personnel sur la machine distante (le fichier authorized_keys est l'équivalent du fichier $HOME/.rhosts et contient une clef par ligne, par conséquent les lignes sont parfois très longues). Grâce à ça, l'utilisateur peut se connecter sans fournir de mot de passe. L'authentification RSA est beaucoup plus sécurisée que l'authentification à l'aide des fichiers rhosts.

En utilisant un agent d'authentification, on rend l'authentification RSA encore plus pratique. Référez-vous à ssh-agent(1) pour plus d'informations à ce sujet.

Si ces autres méthodes d'authentifications échouent, ssh réclame un mot de passe à l'utilisateur. Ce mot de passe est alors envoyé par le réseau à la machine distante. Toutefois, comme toutes les transmissions sont cryptées, on ne peut pas voir le mot de passe en surveillant le réseau.

Version 2 du protocole SSH¶

Si un utilisateur se connecte à l'aide de la version 2 du protocole, il a à sa disposition des méthodes semblables. Les valeurs par défaut de la variable PreferredAuthentications précisent que tout d'abord, le client tente une authentification à l'aide de la méthode basée sur les machines connues (hostbased). En cas d'échec, il tente une authentification par clef publique. Si l'authentification n'est toujours pas possible, il tente une authentification par saisie interactive au clavier et par mot de passe.

La méthode d'authentification par clef publique est semblable à celle de l'authentification RSA décrite dans la section précédente, et peut utiliser les algorithmes RSA ou DSA : Le client utilise sa clef privée $HOME/.ssh/id_dsa ou $HOME/.ssh/id_rsa, pour signer l'identifiant de session, puis envoie le résultat au serveur. Le serveur vérifie si la clef publique correspondante apparaît dans $HOME/.ssh/authorized_keys et accorde l'accès si la clef existe et que sa signature est correcte. L'identifiant de session est dérivé d'une valeur partagée de Diffie-Hellman et n'est connue que du client et du serveur.

Si l'authentification par clef publique échoue ou n'est pas disponible, l'utilisateur peut envoyer un mot de passe crypté pour prouver son identité.

En outre, ssh supporte l'authentification par machine et l'authentification par défi (challenge response).

La version 2 du protocole fournit des mécanismes supplémentaires pour assurer la confidentialité (les communications sont cryptées à l'aide de AES, 3DES, Blowfish, CAST128 ou Arcfour) et l'intégrité (hmac-md5, hmac-sha1, hmac-ripemd160) des données. Il est à noter que la version 1 du protocole ne fournit pas de mécanisme fiable pour garantir l'intégrité de la connexion.

Connexion et exécution de commandes à distance¶

Quand un utilisateur a prouvé son identité, le serveur exécute une commande donnée ou connecte l'utilisateur en lui fournissant un interpréteur de commandes (shell) normal sur la machine distante. Toutes les communications avec la commande distante ou l'interpréteur de commandes distant sont automatiquement cryptées.

Dans le cas où l'utilisateur dispose d'un pseudo-terminal (session de connexion normale), on peut utiliser les caractères d'échappement listés ci-après.

Si l'utilisateur ne dispose pas de pseudo-terminal, la session est transparente, et peut servir à transmettre de manière fiable des données binaires. Sur la plupart des systèmes, si le caractère d'échappement est réglé à « none », la session est transparente, même si on utilise un terminal.

La session prend fin quand la commande ou l'interpréteur de commandes sur la machine distante se termine, et que toutes les connexions X11 ou TCP/IP ont été fermées. Le code de retour du programme distant est retourné comme code de retour de ssh.

Caractères d'échappement¶

Quand on utilise un pseudo-terminal, ssh supporte quelques fonctions via l'utilisation du caractère d'échappement.

Pour envoyer un simple tilde, il faut taper ~~ ou faire suivre un unique tilde d'un caractère différent de ceux énumérés ci-après. Pour que le caractère d'échappement soit interprété de manière spéciale, il doit toujours être précédé d'un retour à la ligne. Il est possible de changer le caractère d'échappement dans les fichiers de configuration à l'aide la directive EscapeChar ou sur la ligne de commande à l'aide de l'option -e.

Les séquences d'échappement supportées (on considère que « ~ » est le caractère d'échappement, la configuration par défaut) sont :

~.

Déconnecte.

~^Z

Fait passer ssh en arrière-plan.

~#

Liste les connexions transférées.

~&

Fait passer ssh en arrière-plan lors de la déconnexion, si des transferts de connexions ou des sessions X11 sont toujours en cours.

~?

Affiche la liste des caractères d'échappement.

~B

Émet un BREAK au système distant (uniquement pour la version 2 du protocole SSH, et si la machine d'en face le supporte).

~C

Ouvre une ligne de commande. Utile pour ajouter des transferts de port (port forwarding) à l'aide des options -L et -R (cf ci-après). Cela permet également la fermeture de transfert de port en cours, en utilisant -KR hostport. Une aide rudimentaire est disponible avec l'option -h.

~R

Demande un nouvel échange de clef pour la connexion (uniquement pour la version 2 du protocole SSH, et si la machine d'en face le supporte).

Transfert X11 et TCP (X11 and TCP forwarding)¶

Si la variable ForwardX11 est réglée à « yes » (voir, à ce sujet, la description des options -X et -x ci-après) et que l'utilisateur utilise X11 (la variable d'environnement DISPLAY est réglée), la connexion à l'affichage X11 est transférée automatiquement à la machine distante. De cette manière, tout programme X11 démarré depuis l'interpréteur de commandes, ou depuis une commande, passe par le canal crypté, et la connexion au serveur X est réalisée sur la machine locale. On ne doit pas régler manuellement la variable DISPLAY. Le transfert des connexions X11 peut être configuré en la ligne de commande ou à l'aide des fichiers de configuration.

La valeur de la variable DISPLAY réglée par ssh pointe vers la machine serveur, mais avec un numéro d'affichage plus grand que zéro. C'est normal, puisque ssh crée un serveur X « mandataire » (proxy) qui sert à transférer les connexions à travers le canal crypté.

ssh règle aussi automatiquement Xauthority sur la machine serveur. Pour ce faire, il génère un cookie d'authentification aléatoire, l'enregistre dans le Xauthority du serveur, puis vérifie que toutes les connexions sont bien porteuses de ce cookie, et le remplace par le vrai cookie lors de l'ouverture de la connexion. Le vrai cookie d'authentification n'est jamais envoyé au serveur (et aucun cookie n'est envoyé en clair).

Si la variable ForwardAgent est réglée à « yes » (voir, à ce sujet, la description des options -A et -a ci-après) et que l'utilisateur se sert d'un agent d'authentification, la connexion à l'agent est transférée automatiquement vers la machine distante.

On peut spécifier le transfert de connexions TCP/IP arbitraires via le canal sécurisé sur la ligne de commande, ou dans un fichier de configuration. Une application possible du transfert TCP/IP est la connexion à une bourse électronique. Le transfert TCP/IP peut aussi permettre de passer à travers des pare-feux (firewalls).

Authentification du serveur¶

ssh maintient automatiquement une base de données qui contient les identifiants de toutes les machines déjà visitées. Les clefs des machines sont enregistrées dans le fichier $HOME/.ssh/known_hosts du répertoire personnel de l'utilisateur. ssh vérifie en plus automatiquement le fichier /etc/ssh/ssh_known_hosts pour contrôler si des machines sont connues. Les nouvelles machines sont ajoutées automatiquement au fichier de l'utilisateur. En cas de changement dans un identifiant de machine, ssh le signale, et désactive la méthode d'authentification par mot de passe pour empêcher la capture du mot de passe par un cheval de Troie, par exemple. Ce mécanisme a aussi pour but d'éviter les attaques de type « man-in-the-middle » qui permettraient autrement de contourner le cryptage. L'option StrictHostKeyChecking permet d'empêcher de se connecter à des machines dont la clef d'hôte serait inconnue ou aurait changé.

ssh peut être configuré pour vérifier l'identité d'une machine distante à l'aide d'une base de ressource d'empreintes (SSHFP) publiée par un DNS. L'option VerifyHostKeyDNS peut être utilisée pour contrôler la manière avec laquelle les requêtes DNS sont effectuées. Une base de ressource d'empreintes peut être générée en utilisant ssh-keygen(1).

Les options sont les suivantes :

-1

Force ssh à n'essayer que la version 1 du protocole.

-2

Force ssh à n'essayer que la version 2 du protocole.

-4

Force ssh à n'utiliser que des adresses IPv4.

-6

Force ssh à n'utiliser que des adresses IPv6.

-A

Active le transfert de connexion de l'agent d'authentification. Peut aussi être spécifié machine par machine dans un fichier de configuration.

Il ne faut activé le transfert d'agent qu'avec précaution. En effet, les utilisateurs capables de contourner les permissions des fichiers sur la machines distante (pour obtenir la socket unix-domain de l'agent) peuvent accéder à l'agent local via le transfert de connexion. Un attaquant ne peut pas obtenir d'information sur les clefs à partir de l'agent, en revanche il peut effectuer des opérations sur les clefs lui permettant de s'authentifier avec l'identité chargée dans l'agent.

-a

Désactive le transfert de connexion de l'agent d'authentification.

-b adr_assoc

Précise une interface réseau émettrice sur une machine qui en possède plusieurs, ou qui a des alias d'adresses réseau.

-C

Active la compression de toutes les données (entrée standard, sortie standard, erreur standard, et toutes les connexion X11 et TCP/IP transférées). L'algorithme de compression est le même que celui de gzip(1), et le « niveau » de compression peut être défini par l'option CompressionLevel. La compression est souvent souhaitable sur les lignes modem ou les connexions lentes, mais elle ne cause que le ralentissement du trafic si elle est activée sur un réseau rapide. On peut aussi spécifier la valeur par défaut pour une machine donnée dans les fichiers de configuration. Voir l'option Compression.

-c crypt_spec

Choisit une spécification de cryptage pour la session.

La version 1 du protocole ne supporte la sélection que d'un cryptage. Les valeurs disponibles sont « 3des », « blowfish » et « des ». 3des (triple-des) est un algorithme de cryptage-décryptage-cryptage triple qui utilise trois clefs différentes. C'est un bon choix, du point de vue de la sécurité. blowfish est un cryptage de bloc rapide. Il semble très bien sécurisé et est beaucoup plus rapide que 3des. des n'est supporté dans le client ssh que pour l'interopérabilité avec les implantations de la version 1 du protocole qui ne supportent pas le cryptage 3des. Compte tenu de ses faiblesses cryptographiques, son utilisation est fortement déconseillée. L'option par défaut est « 3des ».

En ce qui concerne la version 2 du protocole, crypt_spec est une liste des cryptages classés par ordre de préférence et séparés par des virgules. Les cryptages supportés sont « 3des-cbc », « aes128-cbc », « aes192-cbc », « aes256-cbc », « aes128-ctr », « aes192-ctr », « aes256-ctr », « arcfour », « blowfish-cbc » et « cast128-cbc ». La valeur par défaut est

  « aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc »

-D port

Spécifie un transfert « dynamique » des ports au niveau applicatif. Ceci fonctionne grâce à l'allocation d'une socket qui écoute sur le port port de la machine locale, et qui, dès qu'une connexion est établie sur ce port, la transfère à travers le canal sécurisé. Le protocole applicatif est alors utilisé pour déterminer vers où se connecter à partir de la machine distante. À l'heure actuelle, les protocoles SOCKS4 et SOCKS5 sont supportés, et ssh se comporte alors comme un serveur SOCKS. Seul root peut transférer des ports privilégiés. On peut aussi spécifier un transfert de port dynamique dans le fichier de configuration.

-e ch | ^ch | none

Spécifie le caractère d'échappement pour les sessions avec un pseudo-terminal (pty). Par défaut « ~ ». Le caractère d'échappement est reconnu uniquement en début de ligne. Le caractère d'échappement suivi d'un point (« . ») ferme la connexion ; suivi de Contrôle-Z suspends la connexion, et suivi de lui-même, envoie le caractère d'échappement une seule fois. En réglant le caractère d'échappement à « none », on supprime tout caractère d'échappement, et on rend la session totalement transparente.

-F fich_config

Spécifie un autre fichier de configuration utilisateur. Si on fournit un chemin vers un fichier sur la ligne de commande, le fichier (/etc/ssh/ssh_config), qui est utilisé pour toute la machine, est ignoré. L'emplacement par défaut pour le fichier de configuration utilisateur est $HOME/.ssh/config.

-f

Demande à ssh de basculer en arrière-plan juste avant d'exécuter la commande. C'est particulièrement utile si ssh demande des mots de passe ou des phrases de passe, mais que l'utilisateur veuille que le reste de son exécution s'effectue en arrière-plan. Cela implique l'option -n. La méthode recommandée pour exécuter des programmes X11 d'un site distant ressemble à quelque chose comme : ssh -f host xterm.

-g

Permet à des machines distantes de se connecter à des ports transférés locaux.

-I periph_carte_puce

Spécifie quel lecteur de carte à puces utiliser. Le paramètre est le fichier spécial correspondant au lecteur de carte à puces que le programme ssh utilisera pour stocker la clef privée RSA de l'utilisateur.

-i fich_identite

Spécifie un fichier qui contient l'identité (la clef privée) à utiliser pour l'authentification RSA ou DSA. Par défaut $HOME/.ssh/identity pour la version 1 du protocole, et $HOME/.ssh/id_rsa et $HOME/.ssh/id_dsa pour la version 2 du protocole. On peut aussi spécifier l'emplacement des fichiers d'identité pour une machine donnée dans le fichier de configuration. On peut spécifier plusieurs options -i (et plusieurs identités dans les fichiers de configuration).

-k

Désactive les transferts (délégation) d'identifiants GSSAPI vers le serveur.

-L port:host:hostport

Spécifie que le port donné de la machine locale (client) sera transféré vers l'hôte et le port donné depuis la machine distante. Ceci fonctionne grâce à l'allocation d'une socket qui écoute sur le port port de la machine locale, et qui, dès qu'une connexion est établie sur ce port, la transfère à travers le canal sécurisé, et se connecte à host sur le port hostport depuis la machine distante. On peut aussi spécifier des transferts de port (port forwardings) dans le fichier de configuration. Seul root peut transférer des ports privilégiés. Il est possible de spécifier des adresses IPv6 à l'aide d'une autre syntaxe : N°port/N°host/hostport.

-l nom_login

Spécifie un nom d'utilisateur à utiliser pour la connexion sur la machine distante. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.

-M

Place le client ssh en mode « maître » pour effectuer du partage de connexion. Pour de plus amples détails, veuillez vous référer à la description de ControlMaster dans ssh_config(5).

-m mac_spec

Pour la version 2 du protocole, spécifie une liste d'algorithmes MAC (Message Authentification Code, code d'authentification de message) séparés par des virgules et classés par ordre de préférence. Voir le mot-clef MACs pour plus d'information.

-N

N'exécute aucune commande distante. Utilisé pour les transferts de ports (seulement dans la version 2 du protocole).

-n

redirige l'entrée standard vers /dev/null (en fait, empêche la lecture depuis l'entrée standard). À utiliser lors d'une utilisation de ssh en arrière-plan. On peut s'en servir pour exécuter des programmes X11 sur une machine distante. Par exemple, ssh -n shadows.cs.hut.fi emacs & démarre un emacs sur shadows.cs.hut.fi, et la connexion X11 est transférée automatiquement dans le canal crypté. Le programme ssh est basculé en arrière-plan. Ne fonctionne pas si ssh a besoin d'un mot de passe ou d'une phrase de passe ; Voir l'option -f.

-o option

Utilisé pour passer des options dans le format du fichier de configuration. Par exemple, pour spécifier des options qui n'ont pas d'équivalent en ligne de commande. Pour obtenir des détails sur les options listées ci-après, ainsi que les valeurs autorisées, veuillez vous référer à ssh_config(5).

AddressFamily

 

BatchMode

 

BindAddress

 

ChallengeResponseAuthentication

 

CheckHostIP

 

Cipher

 

Ciphers

 

ClearAllForwardings

 

Compression

 

CompressionLevel

 

ConnectionAttempts

 

ConnectTimeout

 

ControlMaster

 

ControlPath

 

DynamicForward

 

EscapeChar

 

ForwardAgent

 

ForwardX11

 

ForwardX11Trusted

 

GatewayPorts

 

GlobalKnownHostsFile

 

GSSAPIAuthentication

 

GSSAPIDelegateCredentials

 

Host

 

HostbasedAuthentication

 

HostKeyAlgorithms

 

HostKeyAlias

 

HostName

 

IdentityFile

 

IdentitiesOnly

 

LocalForward

 

LogLevel

 

MACs

 

NoHostAuthenticationForLocalhost

 

NumberOfPasswordPrompts

 

PasswordAuthentication

 

Port

 

PreferredAuthentications

 

Protocol

 

ProxyCommand

 

PubkeyAuthentication

 

RemoteForward

 

RhostsRSAAuthentication

 

RSAAuthentication

 

SendEnv

 

ServerAliveInterval

 

ServerAliveCountMax

 

SmartcardDevice

 

StrictHostKeyChecking

 

TCPKeepAlive

 

UsePrivilegedPort

 

User

 

UserKnownHostsFile

 

VerifyHostKeyDNS

 

XAuthLocation

 

-p port

Port à connecter sur la machine distante. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.

-q

Mode silencieux. Supprime tous les messages d'avertissement et de diagnostic.

-R port:host:hostport

Spécifie que le port donné de la machine distante (serveur) sera transféré vers l'hôte et le port donné depuis la machine locale. Ceci fonctionne grâce à l'allocation d'une socket qui écoute sur le port port de la machine distante, et qui, dès qu'une connexion est établie sur ce port, la transfère à travers le canal sécurisé, et se connecte à host sur le port hostport depuis la machine locale. On peut aussi spécifier des transferts de port (port forwardings) dans le fichier de configuration. On ne peut transférer des ports privilégiés que si on se connecte en tant que root sur la machine distante. Il est possible de spécifier des adresses IPv6 à l'aide d'une autre syntaxe : N°port/N°host/hostport.

-S ctl

Indique l'emplacement de la socket de contrôle pour le partage de connexion. Voir les descriptions de ControlPath et ControlMaster dans ssh_config(5) pour plus de détails.

-s

Invoque un sous-système sur la machine distante. Les sous-systèmes sont une fonctionnalité de la version 2 du protocole, et simplifient l'utilisation de SSH pour la transmission sécurisée d'autres applications (par exemple sftp(1) ). La commande distante spécifie le sous-système.

-T

Désactive l'allocation de pseudo-terminal.

-t

Force l'allocation d'un pseudo-terminal. Utilisé pour exécuter des programmes en mode écran sur la machine distante. En particulier, c'est fort utile pour les applications qui implémentent des services de menu. En ajoutant des options -t, on force l'allocation de terminaux, même si ssh n'a pas de terminal local.

-V

Affiche le numéro de version et quitte.

-v

Mode bavard. ssh affiche des messages de diagnostic sur ce qu'il fait. Fort utile pour résoudre des problèmes de connexion, d'authentification ou de configuration. En ajoutant des options -v, ssh devient de plus en plus bavard. Au maximum 3.

-X

Active le transfert X11. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.

Le transfert X11 doit être activé avec précaution. En effet, les utilisateurs capables de contourner les permissions des fichiers sur la machines distante (pour accéder à la base de donnée d'accréditation de X) peuvent accéder au à l'écran X11 local via le transfert de connexion. Un attaquant pourrait alors effectuer des opérations telles qu'enregistrer la frappe.

-x

Désactive le transfert X11.

-Y

Active un transfert X11 de confiance.