ssh

NOM
     ssh — Client SSH OpenSSH (programme de connexion à distance)

SYNOPSIS
     ssh [-1246AaCfgkMNnqsTtVvXxY] [-b adr_assoc] [-c crypt_spec] [-D port]
         [-e char_echap] [-F fich_config] [-i fich_identite] [-L
         port:host:hostport] [-l nom_login] [-m mac_spec] [-o option] [-p port]
         [-R port:host:hostport] [-S ctl] [utilisateur@]hostname [commande]

DESCRIPTION
     ssh (client SSH) est un programme qui permet de se connecter sur une
     machine distante, ou d'exécuter des commandes sur une machine distante.  Il
     a pour objectif de remplacer rlogin et rsh, et fournit des transmissions
     sécurisées et cryptées entre deux machines qui ne sont pas sûres, et ce à
     travers un réseau non sécurisé.  On peut transférer des connexions X11 et
     des ports TCP/IP arbitraires à travers un tunnel sécurisé.

     ssh se connecte et ouvre une session sur la machine hostname (avec
     éventuellement un nom d' utilisateur ).  L'utilisateur doit prouver son
     identité sur la machine distante à l'aide d'une méthode parmi plusieurs qui
     dépendent de la version du protocole SSH utilisée :

     Si commande est spécifiée, alors commande est exécutée sur la machine
     distante à la place du shell de login.

   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.

FICHIERS DE CONFIGURATION
     ssh peut accessoirement obtenir des données de configuration depuis des
     fichiers utilisateur, ou depuis un fichier de configuration pour le
     système.  Le format du fichier et les options de configuration sont décrits
     dans ssh_config(5).

ENVIRONNEMENT
     ssh règle normalement les variables d'environnement suivantes :

     DISPLAY  La variable d'environnement DISPLAY indique l'emplacement du
              serveur X11. Elle est réglée automatiquement par ssh à une valeur
              comme « hostname:n » où hostname indique la machine sur laquelle
              s'exécute l'interpréteur de commandes, et n est un entier
              strictement positif (n ≥ 1).  ssh utilise cette valeur spéciale
              pour transférer les connexions X11 à travers le canal sécurisé.
              Normalement, l'utilisateur ne doit pas modifier cette variable
              explicitement, ce qui aurait pour résultat de rendre la connexion
              non sécurisée (et obligerait l'utilisateur à copier manuellement
              les cookies d'accréditation).

     HOME     Règle l'emplacement du répertoire personnel de l'utilisateur.

     LOGNAME  Synonyme pour USER.  Utilisé pour la compatibilité avec les
              systèmes qui utilisent cette variable.

     MAIL     Emplacement de la boîte à lettres de l'utilisateur.

     PATH     Réglé à la valeur de la variable PATH, spécifiée lors de la
              compilation de ssh.

     SSH_ASKPASS
              Si ssh nécessite une phrase de passe, il la lit depuis le terminal
              en cours s'il est exécuté depuis un terminal.  Si ssh n'est pas
              associé à un terminal, mais peut lire les variables
              d'environnement DISPLAY et SSH_ASKPASS, il exécute le programme
              spécifié dans SSH_ASKPASS et ouvre une fenêtre X11 pour lire la
              phrase de passe.  C'est particulièrement utile lors d'un appel de
              ssh depuis .Xsession ou un script équivalent.  (Note : sur
              certaines machines, il peut être nécessaire de rediriger l'entrée
              depuis /dev/null pour que tout fonctionne.)

     SSH_AUTH_SOCK
              Identifie le chemin de la socket unix-domain utilisée pour
              communiquer avec l'agent.

     SSH_CONNECTION
              Identifie les deux bouts de la connexion (le client et le
              serveur). La variable contient quatre valeurs séparées par des
              espaces : l'adresse IP du client, le numéro de port du client,
              l'adresse IP du serveur et le numéro de port du serveur.

     SSH_ORIGINAL_COMMAND
              Cette variable contient la ligne de commande originale si une
              commande a été fournie.  On peut utiliser cette variable pour
              extraire les arguments originaux.

     SSH_TTY  Contient le nom du terminal (emplacement du fichier spécial)
              associé à l'interpréteur de commandes ou à la commande en cours.
              Si la session n'a pas de terminal, la variable n'existe pas.

     TZ       Cette variable indique le fuseau horaire si la variable était
              réglée lors du démarrage du démon.  (c'est à dire que le démon la
              passe aux nouvelles connexions).

     USER     Contient le nom de l'utilisateur connecté.

     En outre, ssh lit le fichier $HOME/.ssh/environment, et ajoute les lignes
     qui possèdent le format « NOMDEVARIABLE=valeur » à l'environnement, si le
     fichier existe que les utilisateurs sont autorisés à modifier leur
     environnement. Pour plus d'information, veuillez vous rapporter à l'option
     PermitUserEnvironment dans sshd_config(5).

FICHIERS
     $HOME/.ssh/known_hosts
             Enregistre les clefs de tous les hôtes sur lesquelles l'utilisateur
             s'est connecté et qui n'apparaissent pas dans le fichier
             /etc/ssh/ssh_known_hosts.  Voir sshd(8).

     $HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa
             Contiennent les identités d'authentification de l'utilisateur,
             respectivement pour
              RSA du protocole 1, DSA du protocole 2 et RSA du protocole 2. Ces
             fichiers contiennent des données sensibles et ne doivent être
             lisibles que par l'utilisateur et non accessibles aux autres
             utilisateurs (en lecture, écriture et exécution).  Note : ssh
             ignore purement et simplement un fichier de clef, s'il est
             accessible aux autres utilisateurs.  On peut spécifier une phrase
             de passe (passphrase) lors de la création de la clef.  La phrase de
             passe (passphrase) est utilisée pour crypter la partie sensible de
             ce fichier à l'aide de 3DES.

     $HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub
             Contiennent les clefs publiques utilisées pour l'authentification
             (partie publique du fichier d'identité lisible par un humain). Il
             faut ajouter le contenu du fichier $HOME/.ssh/identity.pub dans le
             fichier $HOME/.ssh/authorized_keys sur chacune des machines sur
             lesquelles l'utilisateur souhaite se connecter à l'aide de la
             méthode d'authentification RSA de la version 1 du protocole.  Il
             faut ajouter le contenu des fichiers $HOME/.ssh/id_dsa.pub et
             $HOME/.ssh/id_rsa.pub dans le fichier $HOME/.ssh/authorized_keys
             sur chacune des machines sur lesquelles l'utilisateur souhaite se
             connecter à l'aide de la méthode d'authentification DSA et RSA de
             la version 2 du protocole.  Le contenu de ces fichiers n'est pas
             sensible et peut rester accessible aux autres utilisateurs (mais ce
             n'est pas obligatoire).  Ces fichiers ne sont pas nécessaires, et
             de toute façon jamais utilisés automatiquement.  C'est juste une
             commodité pour l'utilisateur.

     $HOME/.ssh/config
             C'est le fichier de configuration utilisateur. Le format de ce
             fichier ainsi que les options de configuration sont décrits dans
             ssh_config(5).  Étant donné les abus potentiels, ce fichier doit
             avoir strictement comme permission : lecture/écriture pour
             l'utilisateur, et inaccessible aux autres utilisateurs.

     $HOME/.ssh/authorized_keys
             Liste les clefs publiques (RSA/DSA) utilisables pour se connecter
             en tant que cet utilisateur. Le format de ce fichier est décrit
             dans la page de manuel sshd(8).  Dans le cas le plus simple, le
             format est semblable à celui des fichiers d'identité « .pub ». Ce
             fichier n'est pas très sensible, mais il est recommandé qu'il soit
             accessible en lecture/écriture à l'utilisateur, et inaccessible aux
             autres utilisateurs.

     /etc/ssh/ssh_known_hosts
             La liste pour tout le système des clefs des machines. Ce fichier
             doit être préparé par l'administrateur système pour contenir les
             clefs publiques de toutes les machines accessibles. Ce fichier doit
             être lisible par tout le monde.  Ce fichier contient les clefs
             publiques (une par ligne) au format suivant (les champs sont
             séparés par des espaces) : le nom de la machine, la clef publique,
             et un commentaire optionnel. Si des noms différents sont utilisés
             pour la même machine, tous les noms doivent être listés, séparés
             par des virgules. Le format est décrit dans la page de manuel
             sshd(8).

             Le nom canonique de la machine (tel que celui qui est retourné par
             les serveurs de noms) est utilisé par sshd(8) pour vérifier la
             machine client lors de la connexion ; les autres noms sont
             nécessaires car ssh ne convertit pas les noms fournis par
             l'utilisateur en forme canonique avant de vérifier la clef, parce
             qu'un utilisateur malintentionné ayant accès au serveur de noms
             pourrait falsifier l'authentification par machine.

     /etc/ssh/ssh_config
             Le fichier de configuration pour toute la machine.  Le format de ce
             fichier et les options de configuration sont décrits dans
             ssh_config(5).

     /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key
             ces trois fichiers contiennent les parties privées des clefs de
             machines et sont utilisés par les options RhostsRSAAuthentication
             et HostbasedAuthentication.  Si on utilise la méthode
             d'authentification de la version 1 du protocole
             RhostsRSAAuthentication, ssh doit être exécuté avec root comme UID
             effectif (setuid root), puisque la clef de la machine n'est lisible
             que par root. Pour la version 2 du protocole, ssh utilise
             ssh-keysign(8) pour accéder à la clef de la machine avec
             HostbasedAuthentication.  Ceci supprime la contrainte d'exécuter en
             tant que root le programme ssh lorsque cette méthode
             d'authentification est utilisée. Par défaut, ssh n'a pas le bit
             setuid positionné.

     $HOME/.rhosts
             Ce fichier est utilisé par l'authentification par rhosts pour
             lister les paires machine/utilisateur autorisées à se connecter.
             Note : rlogin et rsh utilisent également ce fichier, ce qui rend
             son utilisation avec ssh peu fiable.  Chaque ligne du fichier
             contient un nom de machine (dans la forme canonique retournée par
             les serveurs de noms), puis un nom d'utilisateur de cette machine,
             séparés par un espace.  Sur certaines machines, ce fichier doit
             être lisible par tous les utilisateurs, si le répertoire personnel
             de l'utilisateur est sur une partition NFS, parce que sshd(8) lit
             ce fichier en tant que root. En outre, ce fichier doit être la
             propriété de l'utilisateur, et ne doit autoriser l'écriture pour
             personne d'autre. Les permissions recommandées pour la plupart des
             machines sont : lecture/écriture pour l'utilisateur, et non
             accessible pour les autres utilisateurs.

             Note : par défaut, sshd(8) est installé de telle manière qu'il
             nécessite une authentification RSA par machine avant d'autoriser
             une authentification par rhosts.  Si la machine serveur n'a pas la
             clef de la machine cliente dans son fichier
             /etc/ssh/ssh_known_hosts, elle peut être enregistrée dans le
             fichier $HOME/.ssh/known_hosts.  La manière la plus simple pour
             l'enregistrer est de se connecter à la machine cliente depuis la
             machine serveur à l'aide de ssh : ceci ajoute automatiquement la
             clef de la machine au fichier $HOME/.ssh/known_hosts.

     $HOME/.shosts
             Ce fichier est utilisé exactement de la même façon que le fichier
             .rhosts.  Le but de ce fichier est de pouvoir utiliser les
             authentifications par rhosts avec ssh sans autoriser de connexions
             avec rlogin(1) ou rsh(1).

     /etc/hosts.equiv
             Ce fichier est utilisé lors des authentifications rhosts.  Il
             contient les noms de machine canoniques, un par ligne (le format
             complet est décrit dans la page de manuel de sshd(8) ). Si la
             machine cliente apparaît dans ce fichier, la connexion est
             autorisée automatiquement, si le nom de l'utilisateur est le même
             côté client et serveur. En outre, une authentification RSA par
             machine est normalement nécessaire. Seul root doit avoir la
             permission d'écrire dans ce fichier.

     /etc/ssh/shosts.equiv
             Ce fichier est traité exactement comme le fichier /etc/hosts.equiv.
             Il peut servir à autoriser des connexions avec ssh mais sans
             utiliser rsh/rlogin.

     /etc/ssh/sshrc
             Les commandes contenues dans ce fichier sont exécutées par ssh lors
             de la connexion de l'utilisateur, juste avant l'exécution de
             l'interpréteur de commande ou de la commande.  Voir la page de
             manuel de sshd(8) pour plus d'information.

     $HOME/.ssh/rc
             Les commandes contenues dans ce fichier sont exécutées par ssh lors
             de la connexion de l'utilisateur, juste avant l'exécution de
             l'interpréteur de commande ou de la commande.  Voir la page de
             manuel de sshd(8) pour plus d'informations.

     $HOME/.ssh/environment
             Contient des définitions de variables d'environnement
             supplémentaires. Voir la section ENVIRONNEMENT ci-avant.

DIAGNOSTICS
     ssh se termine avec le code de retour de la commande distante, ou 255 en
     cas d'erreur.

VOIR AUSSI
     gzip(1), rsh(1), scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
     telnet(1), hosts.equiv(5), ssh_config(5), ssh-keysign(8), sshd(8)

     T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH Protocol
     Architecture, draft-ietf-secsh-architecture-12.txt, January 2002, work in
     progress material.

AUTEURS
     OpenSSH est dérivé de la version originale et libre ssh 1.2.12 par Tatu
     Ylonen.  Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de
     Raadt et Dug Song ont corrigé de nombreux bugs, ré-ajouté des nouvelles
     fonctionnalités et créé OpenSSH.  Markus Friedl a contribué au support des
     versions 1.5 et 2.0 du protocole SSH.

TRADUCTION FRANÇAISE
     Laurent Gautrot <l dot gautrot at free dot fr> 25/10/2002. Mise à jour par
     Éric Piel <eric dot piel at tremplin-utc dot net> 14/03/2005.