SSH(1) General Commands Manual SSH(1) NOM ssh - Client de connexion a distance d'OpenSSH SYNOPSIS ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B interface_sortie] [-b adr_sortie] [-c algos_chiffrement] [-D [adr_sortie:]port] [-E fichier_journal] [-e caractere_echappement] [-F fichier_configuration] [-I pkcs11] [-i fichier_identite] [-J destination] [-L adresse] [-l nom_connexion] [-m algos_MAC] [-O commande_de_controle] [-o option] [-P symbole] [-p port] [-R adresse] [-S socket_controle] [-W machine:port] [-w tunnel_local[:tunnel_distant]] destination [commande [argument ...]] ssh [-Q option_requete] DESCRIPTION ssh (le client SSH) est un programme permettant de se connecter a une machine distante et d'executer des commandes sur cette derniere. Il a pour but d'etablir des communications chiffrees securisees entre deux machines non dignes de confiance sur un reseau non securise. Les connexions X11, les ports TCP arbitraires et les sockets de domaine UNIX peuvent aussi transiter par le canal securise. ssh se connecte et s'identifie sur la machine destination qui peut etre specifiee a l'aide de [utilisateur@]nommachine ou d'un URI de la forme ssh://[utilisateur@]nommachine[:port]. L'utilisateur doit prouver son identite aupres de la machine distante en utilisant une methode parmi plusieurs (voir ci-dessous). Si une commande est specifiee, elle sera executee sur la machine distante a la place d'un interpreteur de commande de connexion. commande peut correspondre a une ligne de commande complete ou posseder des arguments additionnels. S'ils sont presents, ces arguments seront ajoutes a la commande, separes par des espaces, avant que cette derniere soit envoyee a la machine distante pour y etre executee. Les options sont les suivantes : -4 Forcer ssh a n'utiliser que des adresses IPv4. -6 Forcer ssh a n'utiliser que des adresses IPv6. -A Active la redirection des connexions depuis un agent d'authentification comme ssh-agent(1). Cette option peut aussi etre definie machine par machine dans un fichier de configuration. La redirection d'agent doit etre activee avec precaution. En effet, les utilisateurs capables de court-circuiter les permissions de fichier sur la machine distante (pour le socket de domaine UNIX de l'agent) peuvent acceder a l'agent local a travers la connexion transferee. Meme si un attaquant ne pourra pas obtenir de cles depuis l'agent, il pourra tout de meme effectuer des operations sur les cles qui lui permettront de s'authentifier en utilisant les identites chargees dans l'agent. Une alternative plus sure consiste a utiliser une machine de saut (voir -J). -a Desactive la redirection de connexion de l'agent d'authentification. -B interface_sortie Preciser l'adresse de l'interface interface_sortie avant de tenter une connexion vers la machine distante. Cette option n'est utile que sur les systemes qui possedent plusieurs adresses. -b adr_sortie Utiliser l'adresse adr_sortie sur la machine locale comme adresse source de la connexion. Cette option n'est utile que sur les systemes qui possedent plusieurs adresses. -C Requiert la compression de toutes les donnees (y compris stdin, stdout, stderr et les donnees pour les connexions redirigees X11, TCP et de domaine UNIX). L'algorithme de compression est le meme que celui utilise par gzip(1). La compression est souhaitable sur les lignes modem ou autres connexions lentes, mais elle ne fera que ralentir le trafic si elle est activee sur un reseau rapide. On peut aussi specifier la valeur par defaut machine par machine dans les fichiers de configuration ; voir l'option Compression dans ssh_config(5). -c algos_chiffrement Specifie les algorithmes de chiffrement a utiliser pour chiffrer la session. algos_chiffrement est une liste d'algorithmes de chiffrement separes par des virgules et presentes par ordre de preference. Voir le mot-cle Ciphers dans ssh_config(5) pour plus d'informations. -D [adr_sortie:]port Specifie une redirection de port local << dynamique >> au niveau applicatif. Le fonctionnement consiste a allouer un socket pour ecouter le port cote local, optionnellement associe a l'adresse adr_sortie indiquee. Chaque fois qu'une connexion est effectuee vers ce port, elle est transferee par le canal securise et le protocole applicatif est alors utilise pour determiner vers ou se connecter depuis la machine distante. Actuellement, les protocoles SOCKS4 et SOCKS5 sont pris en charge et ssh se comporte comme un serveur SOCKS. Seul le superutilisateur peut rediriger des ports privilegies. On peut aussi specifier des redirections de port dynamiques dans le fichier de configuration. On peut specifier des adresses IPv6 en les entourant de crochets. Seul le superutilisateur peut rediriger des ports privilegies. Par defaut, le port local est lie en accord avec la definition de GatewayPorts. On peut cependant utiliser une adresse adr_sortie explicite pour lier la connexion a une adresse specifique. L'adresse adr_sortie de << localhost >> indique que le port d'ecoute ne pourra etre lie que pour un usage local, alors qu'une adresse vide ou << * >> indique que le port sera disponible depuis toutes les interfaces. -E fichier_journal Ajoute les informations de debogage au fichier_journal au lieu de les envoyer sur la sortie d'erreur standard. -e caractere_echappement Specifie le caractere d'echappement pour les sessions avec un pseudo-terminal (pty). Le caractere par defaut est << ~ >>. Le caractere d'echappement suivi d'un point << . >> ferme la connexion ; suivi de Controle-Z, il la suspend et suivi de lui- meme, il envoie le caractere d'echappement une fois. En definissant le caractere d'echappement a << none >>, on desactive tout echappement et on rend la session totalement transparente. -F fichier_configuration Specifie un autre fichier de configuration par utilisateur. Si on fournit un fichier de configuration dans la ligne de commande, le fichier global (/etc/ssh/ssh_config) est ignore. L'emplacement par defaut pour le fichier de configuration utilisateur est ~/.ssh/config. Si cette option est definie a << none >>, aucun fichier de configuration ne sera lu. -f Demande a ssh de basculer en arriere-plan juste avant d'executer la commande. Cette option est particulierement utile si ssh est appele a demander des mots de passe ou des phrases de passe, alors que l'utilisateur souhaite que cela s'effectue en arriere- plan. Elle implique l'option -n. La methode recommandee pour executer des programmes X11 sur une machine distante pourrait ressembler a : ssh -f machine xterm. Si l'option de configuration ExitOnForwardFailure est definie a << yes >>, un client demarre avec l'option -f attendra que toutes les redirections de port distant soient effectuees avec succes avant de se placer lui-meme en arriere-plan. Voir la description de ForkAfterAuthentication dans ssh_config(5) pour les details. -G Demande a ssh d'afficher sa configuration apres evaluation des blocs Host et Match puis de quitter. -g Permet a des machines distantes de se connecter a des ports rediriges locaux. Si elle est utilisee sur une connexion multiplexee, cette option doit etre specifiee sur le processus maitre. -I pkcs11 Specifie la bibliotheque partagee PKCS#11 que ssh devra utiliser pour communiquer avec un jeton PKCS#11 fournissant des cles pour l'authentification utilisateur. -i fichier_identite Specifie un fichier a partir duquel l'identite (la cle privee) pour l'authentification de la cle publique est lue. Vous pouvez aussi specifier un fichier de cle publique pour utiliser la cle privee correspondante chargee dans ssh-agent(1) lorsque le fichier de la cle privee n'est pas present en local. Les fichiers par defaut sont ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, et ~/.ssh/id_ed25519_sk. On peut aussi specifier l'emplacement des fichiers d'identite pour une machine donnee dans le fichier de configuration. On peut specifier plusieurs options -i (et plusieurs identites dans les fichiers de configuration). Si aucun certificat n'a ete explicitement specifie a l'aide de la directive CertificateFile, ssh va tenter de charger les informations de certificat a partir du fichier dont le nom sera obtenu en ajoutant -cert.pub aux noms des fichiers d'identite. -J destination Se connecter a la machine cible en etablissant tout d'abord une connexion ssh vers la machine de saut indiquee par destination, puis en effectuant une redirection TCP vers la destination finale depuis la machine de saut. Il est possible de specifier plusieurs sauts successifs en les separant par des virgules. Il est possible de specifier des adresses IPv6 en les entourant de crochets. Cette option est un raccourci pour definir une directive de configuration ProxyJump. Notez que les directives de configuration fournies sur la ligne de commande s'appliquent en general a la machine de destination et a aucune des machines de saut eventuellement indiquees. Pour definir des directives de configuration qui s'appliquent aux machines de saut, utilisez le fichier ~/.ssh/config. -K Active l'authentification basee sur GSSAPI et les transferts (delegations) d'identifiants GSSAPI vers le serveur. -k Desactive les transferts (delegations) d'identifiants GSSAPI vers le serveur. -L [adr_sortie:]port:machine:port_machine -L [adr_sortie:]port:socket_distant -L socket_local:machine:port_machine -L socket_local:socket_distant Indique que les connexions vers le port TCP ou le socket Unix donne de la machine locale (client) seront transferees vers la machine et le port donnes ou le socket Unix sur la machine distante. Ce processus fonctionne grace a l'allocation d'un socket qui ecoute soit un port TCP de la machine locale eventuellement lie a l'adresse adr_sortie specifiee, soit un socket Unix. Des qu'une connexion est etablie sur le port local ou le socket, elle est transferee a travers le canal securise, et une connexion est etablie vers le port_machine de la machine ou le socket Unix socket_distant depuis la machine distante. Les redirections de port peuvent aussi etre definies dans le fichier de configuration. Seul le superutilisateur peut transferer des ports privilegies. Il est possible de specifier des adresses IPv6 en les entourant de crochets. Par defaut, le port local est lie en accord avec la definition de GatewayPorts. On peut cependant indiquer une adresse adr_sortie explicite pour lier la connexion a une adresse specifique. L'adresse adr_sortie << localhost >> indique que le port local ne peut etre lie que pour un usage local, alors qu'une adresse vide ou << * >> indique que le port sera disponible sur toutes les interfaces. -l nom_connexion Indique le nom d'utilisateur sous lequel se connecter a la machine distante. Il peut aussi etre specifie pour une machine donnee dans le fichier de configuration. -M Place le client ssh en mode << master >> pour le partage de connexion. Specifier plusieurs options -M place le client ssh en mode << master >>, mais avec demande de confirmation en utilisant ssh-askpass(1) avant toute operation qui modifie l'etat du multiplexage (par exemple ouvrir une nouvelle session). Voir la description de ControlMaster dans ssh_config(5) pour les details. -m algos_MAC Une liste d'algorithmes MAC (message authentication code, code d'authentification de message) separes par des virgules et classes par ordre de preference. Voir le mot-cle MACs dans ssh_config(5) pour plus d'informations. -N N'execute aucune commande distante. Utilise pour les redirections de ports. Voir la description de SessionType dans ssh_config(5) pour les details. -n Redirige l'entree standard vers /dev/null (en fait, empeche la lecture depuis l'entree standard). A utiliser lorsque ssh s'execute en arriere-plan. Cette option peut s'averer utile pour executer des programmes X11 sur une machine distante. Par exemple, ssh -n shadows.cs.hut.fi emacs & demarre emacs sur shadows.cs.hut.fi, et la connexion X11 est transferee automatiquement a travers un canal crypte. Le programme ssh est bascule en arriere-plan. Ne fonctionne cependant pas si ssh necessite un mot de passe ou une phrase de passe ; voir aussi l'option -f. Consulter la description de StdinNull dans ssh_config(5) pour les details. -O commande_de_controle Control an active connection multiplexing master process. When the -O option is specified, the ctl_cmd argument is interpreted and passed to the master process. Valid commands are: "check" (check that the master process is running), "conninfo" (report information about the master connection), "channels" (report information about open channels), "forward" (request forwardings without command execution), "cancel" (cancel forwardings), "proxy" (connect to a running multiplexing master in proxy mode), "exit" (request the master to exit), and "stop" (request the master to stop accepting further multiplexing requests). -o option Cette option permet de specifier des options dans le format du fichier de configuration et qui n'ont pas d'equivalent en ligne de commande. Pour plus de details sur les options listees ci- apres, ainsi que les valeurs autorisees, veuillez vous referer a ssh_config(5). AddKeysToAgent AddressFamily BatchMode BindAddress BindInterface CASignatureAlgorithms CanonicalDomains CanonicalizeFallbackLocal CanonicalizeHostname CanonicalizeMaxDots CanonicalizePermittedCNAMEs CertificateFile ChannelTimeout CheckHostIP Ciphers ClearAllForwardings Compression ConnectTimeout ConnectionAttempts ControlMaster ControlPath ControlPersist DynamicForward EnableEscapeCommandline EnableSSHKeysign EscapeChar ExitOnForwardFailure FingerprintHash ForkAfterAuthentication ForwardAgent ForwardX11 ForwardX11Timeout ForwardX11Trusted GSSAPIAuthentication GSSAPIDelegateCredentials GatewayPorts GlobalKnownHostsFile HashKnownHosts Host HostKeyAlgorithms HostKeyAlias HostbasedAcceptedAlgorithms HostbasedAuthentication Hostname IPQoS IdentitiesOnly IdentityAgent IdentityFile IgnoreUnknown Include KbdInteractiveAuthentication KbdInteractiveDevices KexAlgorithms KnownHostsCommand LocalCommand LocalForward LogLevel LogVerbose MACs NoHostAuthenticationForLocalhost NumberOfPasswordPrompts ObscureKeystrokeTiming PKCS11Provider PasswordAuthentication PermitLocalCommand PermitRemoteOpen Port PreferredAuthentications ProxyCommand ProxyJump ProxyUseFdpass PubkeyAcceptedAlgorithms PubkeyAuthentication RekeyLimit RemoteCommand RemoteForward RequestTTY RequiredRSASize RevokedHostKeys SecurityKeyProvider SendEnv ServerAliveCountMax ServerAliveInterval SessionType SetEnv StdinNull StreamLocalBindMask StreamLocalBindUnlink StrictHostKeyChecking SyslogFacility TCPKeepAlive Tag Tunnel TunnelDevice UpdateHostKeys User UserKnownHostsFile VerifyHostKeyDNS VisualHostKey XAuthLocation -P symbole Specifier un nom de symbole (tag) a utiliser pour selectionner une configuration dans ssh_config(5). Voir les mots-cles Tag et Match dans ssh_config(5) pour plus d'informations. -p port Le port auquel se connecter sur la machine distante. On peut aussi le specifier pour une machine donnee dans le fichier de configuration. -Q option_requete Requerir les algorithmes de chiffrement pris en charge par une des fonctionnalites suivantes : cipher (algorithmes symetriques), cipher-auth (algorithmes symetriques qui prennent en charge le chiffrement authentifie), help (termes de requete pris en charge a utiliser avec l'option -Q), mac (codes d'integrite de message pris en charge), kex (algorithmes d'echange de cles), key (types de cle), key-ca-sign (algorithmes de signature d'Autorites de Certification (CA) valables pour les certificats), key-cert (types de cle de certificat), key-plain (types de cle hors certificats), key-sig (tous les types de cle et algorithmes de signature), protocol-version (versions du protocole SSH prises en charge) et sig (algorithmes de signature pris en charge). Autrement, tout mot-cle de ssh_config(5) ou sshd_config(5) qui prend une liste d'algorithmes peut etre utilise comme alias pour l'option de requete correspondante. -q Mode silencieux. Supprime la plupart des messages d'avertissement et de diagnostic. -R [adr_sortie:]port:machine:port_machine -R [adr_sortie:]port:socket_local -R socket_distant:machine:port_machine -R socket_distant:socket_local -R [adr_sortie:]port Specifie que les connexions vers le port TCP ou le socket Unix donne de la machine distante (serveur) seront transferees vers la machine locale. A cet effet, un socket est alloue qui ecoute un port TCP ou un socket Unix sur la machine distante. Des qu'une connexion est etablie sur ce port ou ce socket Unix, elle est transferee a travers le canal securise, et une connexion est effectuee depuis la machine locale vers une destination explicite specifiee par le port de la machine ou socket_local, ou, si aucune destination explicite n'a ete specifiee, ssh se comportera comme un mandataire SOCKS 4/5 et transferera les connexions vers les destinations requises par le client SOCKS distant. On peut aussi specifier des redirections de port (port forwardings) dans le fichier de configuration. On ne peut transferer des ports privilegies que si on se connecte en tant que superutilisateur sur la machine distante. Il est possible de specifier des adresses IPv6 en les entourant de crochets. Par defaut, les sockets d'ecoute TCP sur le serveur ne peuvent etre lies qu'a l'interface loopback. Pour modifier ce comportement, on peut specifier une adresse adr_sortie. Une adresse adr_sortie vide ou l'adresse << * >> indique que le socket distant doit ecouter toutes les interfaces. Specifier une adresse adr_sortie distante ne reussira que si l'option GatewayPorts est activee sur le serveur (voir sshd_config(5)). Si l'argument port est egal a 0, le port d'ecoute sera alloue dynamiquement sur le serveur et indique au client a l'execution. Si utilise en combinaison avec -O forward, le port alloue sera envoye sur la sortie standard -S socket_controle Indique l'emplacement d'un socket de controle pour le partage de connexion, ou la chaine << none >> pour desactiver le partage de connexion. Voir les descriptions de ControlPath et ControlMaster dans ssh_config(5) pour les details. -s Permet d'invoquer un sous-systeme sur la machine distante. Les sous-systemes simplifient l'utilisation de SSH comme transport securise pour d'autres applications (par exemple sftp(1)). Le sous-systeme est specifie a l'aide de la commande distante. Voir la description de SessionType dans ssh_config(5) pour les details. -T Desactive l'allocation d'un pseudo-terminal. -t Force l'allocation d'un pseudo-terminal. Utilise pour executer des programmes en mode ecran sur la machine distante, ce qui peut s'averer fort utile, par exemple, pour les applications qui implementent des services de menu. En ajoutant des options -t, on force l'allocation de terminaux, meme si ssh n'a pas de terminal local. -V Affiche le numero de version et quitte. -v Mode prolixe. Avec cette option, ssh affiche des messages de debogage sur les actions qu'il effectue. Fort utile pour deboguer les problemes de connexion, d'authentification ou de configuration. Ajouter des options -v augmente la prolixite. Le maximum est de 3. -W machine:port Demande que les entree et sortie standards sur le client soient transferees vers le port de machine par le canal securise. Implique -N, -T, ExitOnForwardFailure et ClearAllForwardings, bien que ces options puissent etre surchargees dans le fichier de configuration ou en utilisant l'option de ligne de commande -o. -w tunnel_local[:tunnel_distant] Demande la redirection par dispositif de tunnel avec les dispositifs tun(4) specifies entre le client (tunnel_local) et le serveur (tunnel_distant). Les dispositifs peuvent etre specifies par un ID numerique ou le mot-cle << any >>, auquel cas c'est le premier dispositif de tunnel disponible qui sera utilise. La valeur par defaut de tunnel_distant est << any >> au cas ou il ne serait pas specifie. Voir aussi les directives Tunnel et TunnelDevice dans ssh_config(5). Si la directive Tunnel n'est pas definie, elle prendra pour valeur le mode de tunnel par defaut, a savoir << point-to- point >>. Si un autre mode de redirection Tunnel est souhaite, il devra etre specifie avant -w. -X Active la redirection X11. On peut aussi le specifier pour une machine donnee dans le fichier de configuration. La redirection X11 doit etre activee avec precaution. En effet, les utilisateurs capables de contourner les permissions des fichiers sur la machine distante (pour acceder a la base de donnees d'accreditation de X) peuvent acceder au << display >> X11 local par l'intermediaire de la connexion transferee. Un attaquant pourrait alors effectuer des operations telles que l'enregistrement de la frappe. C'est pour cette raison que par defaut, la redirection X11 est assujettie aux restrictions de l'extension X11 SECURITY. Veuillez vous referer a l'option -Y de ssh et a la directive ForwardX11Trusted dans ssh_config(5) pour plus d'informations. -x Desactive la redirection X11. -Y Active une redirection X11 de confiance. Les redirections X11 de confiance ne sont pas assujetties aux controles de l'extension X11 SECURITY. -y Envoyer les informations de journalisation en utilisant le module systeme syslog(3). Par defaut, ces informations sont envoyees a stderr. ssh peut aussi obtenir les donnees de configuration depuis un fichier de configuration d'utilisateur particulier et depuis un fichier de configuration global. Le format du fichier et les options de configuration sont decrits dans ssh_config(5). AUTHENTIFICATION Le client SSH OpenSSH prend en charge la version 2 du protocole SSH. Pour l'authentification, les methodes disponibles sont : l'authentification basee sur GSSAPI, l'authentification basee sur la machine, l'authentification par cle publique, l'authentification par interaction au clavier (keyboard-interactive) et l'authentification par mot de passe. Les methodes d'authentification sont essayees selon l'ordre dans lequel elles sont indiquees ci-dessus, mais cet ordre par defaut peut etre modifie a l'aide de la directive PreferredAuthentications. L'authentification basee sur la machine fonctionne comme suit : si la machine sur laquelle l'utilisateur est connecte est enregistree dans /etc/hosts.equiv ou /etc/ssh/shosts.equiv sur la machine distante, si l'utilisateur est autre que le superutilisateur et si les noms d'utilisateur sont les memes des deux cotes, ou si le fichier ~/.rhosts ou ~/.shosts existent dans le repertoire personnel de l'utilisateur sur la machine distante et comporte une ligne contenant le nom de la machine cliente et le nom de l'utilisateur sur cette machine, l'utilisateur est autorise a se connecter. De plus, le serveur doit pouvoir verifier la cle de la machine du client (voir la description de /etc/ssh/ssh_known_hosts et ~/.ssh/known_hosts ci-dessous) pour que la connexion soit autorisee. Cette methode d'identification bouche les trous de securite dus aux usurpations d'adresse IP, de DNS et de routage. [Note a l'attention de l'administrateur : /etc/hosts.equiv, ~/.rhosts et le protocole rlogin/rsh dans sa globalite sont intrinsequement non securises et doivent etre desactives si vous attachez de l'importance a la securite.] L'authentification par cle publique fonctionne comme suit : son principe est base sur la cryptographie a cle publique et utilise des systemes cryptographiques ou le chiffrement et le dechiffrement utilisent des cles separees et avec lesquels il est impossible de determiner la cle de dechiffrement a partir de la cle de chiffrement. L'idee de base est la suivante : chaque utilisateur cree une paire de cles publique/privee a des fins d'authentification ; le serveur connait la cle publique, mais seul l'utilisateur connait la cle privee. ssh implemente automatiquement le protocole d'authentification par cle publique en utilisant un des algorithmes ECDSA, Ed25519 ou RSA. Le fichier ~/.ssh/authorized_keys liste les cles publiques qui sont autorisees a se connecter. Lorsque l'utilisateur se connecte, le programme ssh indique au serveur quelle paire de cles il souhaiterait utiliser pour l'authentification. Le client prouve qu'il a acces a la cle privee et le serveur verifie si la cle publique correspondante est autorisee a accepter le compte. Le serveur pourra eventuellement indiquer au client les erreurs qui ont fait echouer l'authentification par cle publique lorsque l'authentification a reussi en utilisant une autre methode. Ces erreurs peuvent etre vues en augmentant le niveau de journalisation LogLevel a DEBUG ou plus (par exemple en utilisant l'option -v). L'utilisateur cree sa paire de cles a l'aide de ssh-keygen(1). Ce programme enregistre la cle privee dans ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (cle ECDSA hebergee par un authentificateur), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (cle Ed25519 hebergee par un authentificateur) ou ~/.ssh/id_rsa (RSA) et la cle publique dans ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (cle ECDSA hebergee par un authentificateur), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (cle Ed25519 hebergee par un authentificateur) ou ~/.ssh/id_rsa.pub (RSA) dans le repertoire personnel de l'utilisateur. L'utilisateur doit alors copier la cle publique dans ~/.ssh/authorized_keys dans son repertoire personnel sur la machine distante. Le fichier authorized_keys est equivalent au fichier ~/.rhosts traditionnel et il comporte une cle par ligne, meme si ces dernieres peuvent etre tres longues. Cela fait, l'utilisateur peut se connecter sans avoir a presenter de mot de passe. L'authentification par certificat est une variante de l'authentification par cle publique : a la place de la paire de cles publique/privee, elle utilise des certificats signes, ce qui a pour avantage de ne necessiter qu'une seule autorite de certification de confiance au lieu de nombreuses paires de cles publiques/privees. Voir la section CERTIFICATS de ssh-keygen(1) pour plus d'informations. La meilleure methode pour mettre en oeuvre l'authentification par cle publique ou par certificat consiste a utiliser un agent d'authentification. Voir ssh-agent(1) et eventuellement la directive AddKeysToAgent dans ssh_config(5) pour plus d'informations. L'authentification par interaction au clavier (keyboard-interactive) fonctionne comme suit : le serveur envoie une "question" arbitraire sous forme de texte et attend une reponse, eventuellement plusieurs fois. On peut citer comme exemples d'authentification par interaction au clavier l'authentification BSD (voir login.conf(5)) et l'authentification PAM (certains systemes non-OpenBSD). En fin de compte, si les autres methodes d'authentification echouent, ssh demandera un mot de passe a l'utilisateur. Ce mot de passe sera alors envoye a la machine distante pour verification, et comme toutes les communications sont chiffrees, un individu qui ecouterait le reseau ne pourra pas le voir. ssh entretient et verifie automatiquement une base de donnees contenant l'identification pour toutes les machines avec lesquelles il a deja ete utilise. Les cles d'hote sont stockees dans ~/.ssh/known_hosts dans le repertoire personnel de l'utilisateur. De plus, une verification des machines connues est automatiquement effectuee dans le fichier /etc/ssh/ssh_known_hosts. Toute nouvelle machine est ajoutee au fichier de l'utilisateur. Si l'identification d'une machine est modifiee, ssh emet un avertissement et desactive l'authentification par mot de passe pour empecher toute usurpation de serveur ou attaque de type << homme du milieu >> qui pourrait sans cela etre utilisee pour contourner le chiffrement. L'option StrictHostKeyChecking permet de controler les connexions aux machines dont la cle d'hote est inconnue ou a ete modifiee. Lorsque l'identite de l'utilisateur a ete acceptee par le serveur, soit une commande a ete specifiee et le serveur l'execute dans le cadre d'une session non interactive, soit aucune commande n'a ete specifiee et le serveur connecte l'utilisateur a la machine et lui ouvre un interpreteur de commande normal dans le cadre d'une session interactive. Toutes les communications avec la commande ou l'interpreteur distants sont automatiquement chiffrees. Si une session interactive est requise, par defaut, ssh ne demandera qu'un pseudo-terminal (pty) pour les sessions interactives lorsque le client en possede un. Les options -T et -t permettent d'outrepasser ce comportement. Si un pseudo-terminal a ete alloue, l'utilisateur peut utiliser les caracteres d'echappement notes ci-dessous. Si aucun pseudo-terminal n'a ete alloue, la session est transparente et permet de transmettre des donnees binaires de maniere fiable. Sur la plupart des systemes, definir le caractere d'echappement a << none >> rendra aussi la session transparente, meme si un tty est utilise. La session est fermee lorsque la commande ou l'interpreteur de commande sur la machine distante quitte et si toutes les connexions X11 et TCP ont ete fermees. CARACTERES D'ECHAPPEMENT Lorsqu'un pseudo-terminal a ete demande, ssh prend en charge un certain nombre de fonctions a l'aide de caracteres d'echappement. Pour envoyer un simple caractere tilde, on peut utiliser ~~ ou faire suivre le tilde d'un caractere autre que ceux decrits ci-dessous. Le caractere d'echappement doit toujours etre precede d'un caractere nouvelle ligne pour etre considere comme special. Il peut etre change en ligne de commande a l'aide de l'option -e ou dans les fichiers de configuration a l'aide de la directive EscapeChar. Les echappements pris en charge (en comptant l'echappement par defaut << ~ >>) sont : ~. Deconnecter. ~^Z ssh en arriere-plan. ~# Lister les connexions transmises. ~& ssh en arriere-plan a la deconnexion lorsqu'on attend la fin d'une connexion redirigee ou d'une session X11. ~? Afficher une liste des caracteres d'echappement. ~B Envoyer un BREAK au systeme distant (pertinent seulement si la machine distante le prend en charge). ~C Ouvrir une ligne de commande. Actuellement, cette action permet d'ajouter des redirections de port en utilisant les options -L, -R et -D (voir ci-dessus). Elle permet aussi d'annuler des redirections de port existants a l'aide de -KL[adr_sortie:]port pour la machine locale, -KR[adr_sortie:]port pour la machine distante et -KD[adr_sortie:]port pour les redirections de port dynamiques. !commande permet a l'utilisateur d'executer une commande locale si la directive PermitLocalCommand est definie dans ssh_config(5). L'option -h permet d'afficher une aide succincte. ~I Afficher des informations sur la connexion SSH en cours. ~R Demander une nouvelle saisie des informations de connexion (pertinent seulement si la machine distante le prend en charge). ~V Diminue la prolixite (LogLevel) quand les erreurs sont affichees sur stderr. ~v Augmente la prolixite (LogLevel) quand les erreurs sont affichees sur la sortie d'erreur. TRANSFERT TCP Il est possible de specifier la redirection de connexions TCP arbitraires sur un canal securise soit en ligne de commande, soit dans un fichier de configuration. La connexion securisee a un serveur de messagerie est un exemple d'application de la redirection TCP ; passer par des pare-feux en est un autre. Dans l'exemple ci-dessous, on cherche a chiffrer les communications pour un client IRC, meme si le serveur IRC auquel il se connecte ne prend pas directement en charge les communications chiffrees. Le fonctionnement est le suivant : l'utilisateur se connecte a la machine distante a l'aide de ssh en specifiant le port a utiliser pour transferer la connexion. Cela fait, il est possible de demarrer le programme en local, et ssh chiffrera et transferera la connexion vers le serveur distant. L'exemple suivant fait passer par un tunnel une session IRC depuis le client vers un serveur IRC a << server.example.com >> en rejoignant le canal << #users >>, avec le pseudo << pinky >>, en utilisant le port IRC standard 6667 : $ ssh -f -L 6667:localhost:6667 server.example.com sleep 10 $ irc -c '#users' pinky IRC/127.0.0.1 L'option -f fait passer ssh en arriere-plan et la commande distante << sleep 10 >> est specifiee pour accorder un certain temps (10 secondes dans l'exemple) avant de demarrer le programme qui est sur le point d'utiliser le tunnel. Si aucune connexion n'est effectuee dans ce laps de temps, ssh quittera. TRANSFERT X11 Si la variable ForwardX11 est definie a << yes >> (ou voir la description des options -X, -x et -Y ci-dessus) et si l'utilisateur utilise X11 (la variable d'environnement DISPLAY est definie), la connexion au << display >> X11 est automatiquement transferee a la machine distante de facon que tout programme X11 demarre depuis l'interpreteur de commande (ou a l'aide d'une commande) passera par le canal chiffre, et la connexion au veritable serveur X sera etablie depuis la machine locale. L'utilisateur ne doit pas definir manuellement DISPLAY. La redirection des connexions X11 peut etre configuree en ligne de commande ou dans les fichiers de configuration. Comme ssh cree un serveur X << mandataire >> sur la machine serveur pour transferer les connexions sur le canal chiffre, il est normal que la valeur de DISPLAY definie par ssh pointe vers la machine serveur, mais avec un numero de << display >> superieur a zero. ssh va aussi definir automatiquement les donnees Xauthority sur la machine serveur. A cet effet, il va generer un cookie d'autorisation aleatoire, le stocker dans Xauthority sur le serveur et verifier que toute connexion transferee transporte bien ce cookie et le remplace par le veritable cookie lorsque la connexion est ouverte. Le veritable cookie d'authentification n'est jamais envoye a la machine serveur (et aucun cookie n'est envoye en clair). Si la variable ForwardAgent est definie a << yes >> (ou voir la description des options -A et -a ci-apres) et si l'utilisateur utilise un agent d'authentification, la connexion a l'agent est transferee automatiquement vers la machine distante. VERIFIER LES CLES D'HOTE Lorsqu'il se connecte a un serveur pour la premiere fois, une empreinte de la cle publique du serveur est presentee a l'utilisateur (a moins que l'option StrictHostKeyChecking n'ait ete desactivee). Les empreintes peuvent etre determinees en utilisant ssh-keygen(1) : $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key Si l'empreinte est deja connue, elle peut etre verifiee et la cle acceptee ou rejetee. Si les empreintes traditionnelles (MD5) sont les seules disponibles pour le serveur, l'option -E de ssh-keygen(1) permet de degrader l'algorithme d'empreinte pour qu'il convienne. Comme il est difficile de comparer les cles d'hote en regardant simplement les chaines d'empreinte, la comparaison visuelle des cles d'hote est aussi prise en charge en utilisant random art. En definissant l'option VisualHostKey a << yes >>, un petit graphisme ASCII est affiche a chaque connexion a un serveur, et cela que la session elle-meme soit interactive ou non. En memorisant le motif que produit un serveur connu, un utilisateur peut aisement detecter que la cle d'hote a change si un motif totalement different est affiche. Comme ces motifs ne sont pas depourvus d'ambiguite, un motif qui paraitra identique au motif memorise ne constituera cependant qu'une bonne probabilite pour que la cle d'hote soit la meme, non une preuve irrefutable. La ligne de commande suivante permet d'obtenir une liste des empreintes et de leurs motifs aleatoires pour toutes les machines connues : $ ssh-keygen -lv -f ~/.ssh/known_hosts Si l'empreinte n'est pas connue, il existe une autre methode de verification : les empreintes SSH verifiees par DNS. Un enregistrement ressource (RR), SSHFP, est ajoute a un fichier de zone et le client qui se connecte est alors en mesure de comparer l'empreinte avec celle de la cle presentee. Dans cet exemple, un client se connecte au serveur << host.example.com >>. L'enregistrement ressource SSHFP doit avoir ete ajoute au fichier de zone pour host.example.com : $ ssh-keygen -r host.example.com. Les lignes en sortie devront etre ajoutees au fichier de zone. Pour verifier si la zone repond aux demandes d'empreinte : $ dig -t SSHFP host.example.com Finalement, le client se connecte : $ ssh -o "VerifyHostKeyDNS ask" host.example.com [...] Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? Voir l'option VerifyHostKeyDNS dans ssh_config(5) pour plus d'informations. VPN BASE SUR SSH ssh prend en charge les tunnels par VPN (Reseau Prive Virtuel) a l'aide du pseudo-peripherique reseau tun(4) qui permet de relier deux reseaux de maniere securisee. L'option de configuration PermitTunnel de sshd_config(5) permet de controler la prise en charge par le serveur de cette fonctionnalite et a quel niveau (trafic de couche 2 ou 3). Dans l'exemple suivant, le reseau client 10.0.50.0/24 est relie au reseau distant 10.0.99.0/24 en utilisant une connexion point-a-point de 10.1.1.1 a 10.1.1.2, a condition que le serveur SSH qui s'execute sur la passerelle (d'adresse 192.168.1.15) vers le reseau distant le permette. Sur le client : # ssh -f -w 0:1 192.168.1.15 true # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 # route add 10.0.99.0/24 10.1.1.2 Sur le serveur : # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 # route add 10.0.50.0/24 10.1.1.1 L'acces du client peut etre configure plus finement a l'aide du fichier /root/.ssh/authorized_keys (voir plus loin) et de l'option de serveur PermitRootLogin. L'entree suivante permet des connexions sur le dispositif tun(4) numero 1 depuis l'utilisateur << jane >> et sur le dispositif tun de numero 2 depuis l'utilisateur << john >> si PermitRootLogin est definie a << forced-commands-only >> : tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john Une configuration basee sur SSH impliquant une surcharge consequente, elle est plus adaptee aux configurations temporaires comme les VPN sans fil. Pour des VPN plus persistants, il est preferable d'utiliser des outils comme ipsecctl(8) ou isakmpd(8). ENVIRONNEMENT Normalement, ssh va definir les variables d'environnement suivantes : DISPLAY La variable DISPLAY indique l'emplacement du serveur X11. Elle est automatiquement definie par ssh a une valeur de la forme << nom_machine:n >> ou << nom_machine >> indique la machine sur laquelle l'interpreteur de commande s'execute, et ou << n >> est un entier >= 1. ssh utilise cette valeur speciale pour transferer les connexions X11 sur le canal securise. Normalement, l'utilisateur ne doit pas definir explicitement DISPLAY, car la connexion ne serait alors plus securisee (et l'utilisateur devrait copier manuellement tout cookie d'autorisation requis). HOME Definie au chemin du repertoire personnel de l'utilisateur. LOGNAME Synonyme de USER ; definie a des fins de compatibilite avec les systemes qui utilisent cette variable. MAIL Definie au chemin de la boite aux lettres de l'utilisateur. PATH Definie a la valeur par defaut de PATH specifiee lors de la compilation de ssh. SSH_ASKPASS Si ssh necessite une phrase de passe, il la lit depuis le terminal en cours s'il est execute depuis un terminal. Si ssh n'est pas associe a un terminal, alors que les variables d'environnement DISPLAY et SSH_ASKPASS sont definies, il execute le programme specifie dans SSH_ASKPASS et ouvre une fenetre X11 pour lire la phrase de passe, ce qui s'avere particulierement utile lors d'un appel de ssh depuis .xsession ou un script equivalent (notez que sur certaines machines, il peut etre necessaire de rediriger l'entree depuis /dev/null pour que cela fonctionne). SSH_ASKPASS_REQUIRE Permet un controle plus fin de l'utilisation d'un programme de demande de mot de passe. Si cette variable est definie a << never >>, ssh n'essaiera jamais d'en utiliser un. Si elle est definie a << prefer >>, ssh preferera l'utilisation du programme de demande de mot de passe a celle du TTY si un mot de passe est requis. Enfin, si elle est definie a << force >>, le programme de demande de mot de passe sera utilise pour toute saisie de phrase de passe, et cela que la variable DISPLAY soit definie ou non. SSH_AUTH_SOCK Identifie le chemin du socket de domaine UNIX utilise pour communiquer avec l'agent. SSH_CONNECTION Identifie les deux bouts de la connexion (le client et le serveur). La variable contient quatre valeurs separees par des espaces : l'adresse IP du client, le numero de port du client, l'adresse IP du serveur et le numero de port du serveur. SSH_ORIGINAL_COMMAND Cette variable contient la ligne de commande originelle si une commande forcee est executee. On peut l'utiliser pour extraire les arguments originels. SSH_TTY Definie au nom du terminal tty (chemin du fichier de peripherique) associe a l'interpreteur de commande ou a la commande en cours. Si la session en cours n'a pas de terminal, la variable n'est pas definie. SSH_TUNNEL Eventuellement definie par sshd(8) pour contenir les noms d'interface assignes si le client a demande une redirection de tunnel. SSH_USER_AUTH Eventuellement definie par sshd(8), cette variable peut contenir le chemin d'un fichier qui contient la liste des methodes d'authentification qui ont ete utilisees avec succes lors de l'etablissement de la connexion, ainsi que toute cle publique qui a ete utilisee. TZ Cette variable indique le fuseau horaire actuel si elle etait definie au demarrage du demon. (c'est-a-dire que le demon transmet la valeur aux nouvelles connexions). USER Definie au nom de l'utilisateur qui se connecte. En outre, ssh lit le fichier ~/.ssh/environment et ajoute des lignes au format << NOM_VAR=valeur >> a l'environnement, si le fichier existe, et si les utilisateurs sont autorises a modifier leur environnement. Pour plus d'informations, voir l'option PermitUserEnvironment dans sshd_config(5). FICHIERS ~/.rhosts Ce fichier est utilise dans le cadre de l'authentification basee sur la machine (voir plus haut). Sur certaines machines, ce fichier devra eventuellement etre lisible par tout le monde si le repertoire personnel de l'utilisateur est sur une partition NFS, car sshd(8) le lit en tant que superutilisateur. En outre, ce fichier doit etre la propriete de l'utilisateur et ne doit etre accessible en ecriture pour personne d'autre. Les permissions recommandees sur la plupart des machines sont lecture/ecriture pour l'utilisateur et aucun acces pour les autres. ~/.shosts Ce fichier est utilise exactement de la meme facon que .rhosts, mais il permet l'authentification basee sur la machine sans autoriser les connexions avec rlogin/rsh. ~/.ssh/ Ce repertoire correspond a l'emplacement par defaut de toutes les informations de configuration et d'authentification specifiques a l'utilisateur. Il n'est globalement pas necessaire de garder secret l'ensemble du contenu de ce repertoire, mais les permissions recommandees sont lecture/ecriture/execution pour l'utilisateur et aucun acces pour les autres. ~/.ssh/authorized_keys Ce fichier enumere les cles publiques (ECDSA, Ed25519, RSA) qui peuvent etre utilisees pour se connecter sous l'identite de cet utilisateur. Le format de ce fichier est decrit dans la page de manuel de sshd(8). Le contenu de ce fichier n'est pas hautement sensible, mais les permissions recommandees sont lecture/ecriture pour l'utilisateur et aucun acces pour les autres. ~/.ssh/config C'est le fichier de configuration specifique a l'utilisateur. Le format du fichier et les options de configuration sont decrits dans ssh_config(5). Comme il y a risque d'intrusion, ce fichier doit avoir des permissions strictes : lecture/ecriture pour l'utilisateur et pas d'acces en ecriture pour les autres. ~/.ssh/environment Ce fichier contient des definitions de variables d'environnement additionnelles ; voir ENVIRONNEMENT ci-dessus. ~/.ssh/id_ecdsa ~/.ssh/id_ecdsa_sk ~/.ssh/id_ed25519 ~/.ssh/id_ed25519_sk ~/.ssh/id_rsa Ces fichiers contiennent la cle privee pour l'authentification. Ils contiennent des donnees sensibles et doivent etre lisibles par l'utilisateur mais inaccessibles pour les autres (lecture/ecriture/execution). ssh ignorera tout simplement un fichier de cle privee s'il est accessible pour les autres. Il est possible de specifier une phrase de passe lors de la generation de la cle qui sera utilisee pour chiffrer la partie sensible de ces fichiers en utilisant AES-128. ~/.ssh/id_ecdsa.pub ~/.ssh/id_ecdsa_sk.pub ~/.ssh/id_ed25519.pub ~/.ssh/id_ed25519_sk.pub ~/.ssh/id_rsa.pub Ces fichiers contiennent la cle publique pour l'authentification. Ils ne contiennent pas de donnees sensibles et peuvent (mais cela n'est pas necessaire) etre lisibles par tout le monde. ~/.ssh/known_hosts Ce fichier contient une liste des cles d'hote pour toutes les machines auxquelles l'utilisateur s'est connecte et qui ne sont pas deja presentes dans la liste des cles d'hote connues de tout le systeme. Voir sshd(8) pour plus de details a propos du format de ce fichier. ~/.ssh/rc Les commandes que contient ce fichier sont executees par ssh lorsque l'utilisateur se connecte, juste avant le lancement de l'interpreteur de commande (ou la commande) de l'utilisateur. Voir la page de manuel de sshd(8) pour plus d'informations. /etc/hosts.equiv Ce fichier est utilise dans le cadre de l'authentification basee sur la machine (voir plus haut). Il ne doit etre accessible en ecriture que pour le superutilisateur. /etc/ssh/shosts.equiv Ce fichier est utilise exactement de la meme maniere que hosts.equiv, mais il permet l'authentification basee sur la machine sans autoriser les connexions avec rlogin/rsh. /etc/ssh/ssh_config C'est le fichier de configuration global du systeme. Le format du fichier et les options de configuration sont decrits dans ssh_config(5). /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ed25519_key /etc/ssh/ssh_host_rsa_key Ces fichiers contiennent les parties privees des cles d'hote et sont utilises dans le cadre de l'authentification basee sur la machine. /etc/ssh/ssh_known_hosts Ce fichier contient la liste des cles d'hote connues globale a tout le systeme. Il doit etre prepare par l'administrateur systeme de facon a contenir les cles d'hote publiques de toutes les machines de l'organisation. Il doit etre accessible pour tout le monde. Voir sshd(8) pour plus de details a propos du format de ce fichier. /etc/ssh/sshrc Les commandes que contient ce fichier sont executees par ssh lorsque l'utilisateur se connecte, juste avant le lancement de l'interpreteur de commande (ou la commande) de l'utilisateur. Voir la page de manuel de sshd(8) pour plus d'informations. CODE DE RETOUR ssh quitte avec le code de retour de la commande distante ou 255 si une erreur est survenue VOIR AUSSI scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8) NORMES S. Lehtinen et C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, janvier 2006. T. Ylonen et C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, janvier 2006. T. Ylonen et C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, janvier 2006. T. Ylonen et C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, janvier 2006. T. Ylonen et C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, janvier 2006. J. Schlyter et W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, janvier 2006. F. Cusack et M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, janvier 2006. J. Galbraith et P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, janvier 2006. M. Bellare, T. Kohno et C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, janvier 2006. B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, janvier 2006. M. Friedl, N. Provos et W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, mars 2006. J. Galbraith et R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, novembre 2006. D. Stebila et J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, decembre 2009. A. Perrig et D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99). AUTEURS OpenSSH est un derive de la version originale et libre 1.2.12 de ssh par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrige de nombreux bogues, rajoute de nouvelles fonctionnalites et cree OpenSSH. Markus Friedl a contribue a la prise en charge des versions 1.5 et 2.0 du protocole SSH. TRADUCTION La traduction francaise de cette page de manuel a ete creee par Laurent Gautrot , Eric Piel et Lucien Gentis Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3: https://www.gnu.org/licenses/gpl-3.0.html concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a debian-l10n-french@lists.debian.org Linux 6.12.107+deb13-amd64 $Mdocdate: 22 decembre 2025 $ Linux 6.12.107+deb13-amd64