NOM ssh − Client SSH OpenSSH (programme de connexion à

NOM
ssh − Client SSH OpenSSH (programme de connexion à distance)
SYNOPSIS
ssh [ −l login_name
] hostname
| user@hostname
[command
]
ssh [ −afgknqstvxACNPTX1246
] [ −b bind_address
] [ −c cipher_spec
]
[ −e escape_char
] [ −i identity_file
] [ −l login_name
] [ −m mac_spec
[ −o option ] [ −p port ] [ −F configfile
] [ −L port :host :hostport ] [ −R
port :host :hostport ] [ −D port ] hostname
| user@hostname
[command ]
]
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 est supposé 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 le tunnel sécurisé.
ssh se connecte et ouvre une session sur la machine hostname . L’utilisateur peut prouver son identité sur
la machine distante à l’aide de plusieurs méthodes, qui dépendent de la version du protocole SSH utilisée :
Version 1 du protocole SSH
Tout d’abord, si la machine sur laquelle l’utilisateur veut 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 nom
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 de base (home directory) de l’utilisateur sur la machine distante, 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
,
/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 ).
méthode d’authentification comble les failles de sécuritées liées à l’usurpation d’adresses IP, 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 on ne peut pas 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 signale au serveur la paire de clefs qu’il souhaite
utiliser pour la phase d’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 (challenge) ne peut être relevé qu’à l’aide de la clef
privée (qui permet de décrypter tout message crypté à l’aide de la clef publique). Le client de l’utilisateur
relève le défi (challenge) 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 doit 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épertoir
base (home directory) de l’utilisateur. L’utilisateur peut alors copier identity.pub
vers
$HOME/.ssh/authorized_keys
dans son répertoire de base (home directory) 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. Jetez un coup
d’oeil à 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 clair se promener 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 dans quel ordre
utiliser les différentes méthodes d’authentification. Tout d’abord, le client tente une authentification avec la
méthode basée sur les machines connues (known_hosts). 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 l
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
données sont cryptées à l’aide de 3DES, Blowfish, CAST128 or Arcfour) et l’intégrité (hmac-md5, hmacsha1) 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 (shell) distant sont cryptées automatiquement.
Dans le cas où l’utilisateur dispose d’un pseudo-terminal (session connectée 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, en réglant le caractère d’échappement à
« none », on rend la session transparente, même si on utilise un terminal.
La session prend fin quand la commande ou l’interpréteur de commandes (shell) sur la machine distante se
termine, et que toutes les connexions X11 ou TCP/IP sont fermées. Le code de sortie du programme distant
est retourné comme code de sortie de ssh .
Caractères d’échappement
Quand on utilise un peudo-terminal, ssh supporte quelques fonctions à travers l’utilisation de caractères
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 interpréter un caractère d’échappement de manière spéciale, le tilde doit toujours
commencer une nouvelle ligne. On peut 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 (dans cette liste, on considère que « ˜ » est le caractère d’échappement par défaut) sont :
˜.
˜ˆZ
˜#
˜&
˜?
Déconnecte
Fait passer ssh en arrière-plan
Liste les connexions transférées
Fait passer ssh en arrière-plan à la déconnexion, si des connexions ou des sessions X11 transférées
sont toujours en cours.
Affiche la liste des caractères d’échappement
˜C
Ouvre une ligne de commande (utile pour ajouter des transferts de port/port forwarding à l’aide des
options −L et −R , et seulement dans ce cas)
˜R
Demande un reverrouillage de 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 ciaprè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 (shell), 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 . On configure le transfert des connexions X11 sur la ligne de commande ou à l’aide de 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 dans le canal crypté.
ssh régle aussi automatiquement les données 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. On n’envoie jamais le vrai cookie d’authentification au serveur (et on n’envoie pas les cookies en clair).
Si l’utilisateur se sert d’un agent d’authentification, la connexion à l’agent est transférée automatiquement de
la même manière, sauf si cette fonction est désactivée sur la ligne de commandes ou dans un fichier de configuration.
On peut spécifier le transfert de connexions TCP/IP arbitraires dans 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-feus (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 de base de l’utilisateur (home directory). 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 interdire 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é.
Les options sont les suivantes :
−a
−A
Désactive le transfert de connexion de l’agent d’authentification.
Active le transfert de connexion de l’agent d’authentification. Peut être précisé pour une machine
dans un fichier de configuration.
−b bind_address
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 blowfish|3des|des
Choisit un cryptage pour la session. Par défaut 3des . C’est un bon choix, du point de vue de la
sécurité. 3des (triple-des) est un algorithme de cryptage-décryptage-cryptage triple qui utilise trois
clefs différentes. blowfish
est un cryptage de bloc rapide. Il semble 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
implémentations 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.
−c cipher_spec
On peut en outre spécifier dans une liste de valeurs séparées par des virgules, une liste de cryptages
à utiliser par ordre de préférence. Ne fonctionne qu’avec la version 2 du protocole. Voir l’option
Ciphers de ssh_config pour plus d’information.
−e ch|ˆch|none
Spécifie le caractère d’échappement pour des sessions avec des pseudo-terminaux (pty). Par
défaut « ˜ ». Le carctè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
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, mais que l’utilisateur ne les veut pas à l’avantplan. 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 identity_file
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 auss
spécifier l’emplacement des fichiers d’identité pour une machine dans le fichier de configuration.
On peut spécifier plusieurs options −i (et plusieurs identités dans les fichiers de configuration).
−I smartcard_device
Spécifie un lecteur de carte à puces à utiliser. Le paramètre est le fichier spécial du lecteur de carte à
puces que le programme ssh utilisera pour stocker la clef privée RSA de l’utilisateur.
−k
Désactive les transferts de tickets Kerberos et des jetons AFS. On peut aussi le spécifier pour une
machine dans le fichier de configuration.
−l login_name
Spécifie un nom d’utilisateur à utiliser pour la connexion sur la machine distante. On peut aussi le
spécifier pour une machine dans le fichier de configuration.
−m mac_spec
Pour la version 2 du protocole, spécifie une liste de codes d’authentification de message (MAC :
message authentication code) séparés par des virgules, par ordre de préférence. Voir le mot-clef
MACs pour plus d’information.
−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 ; Voir l’option −f
−N
N’exécute aucune commande distante. Utilisé pour les transferts de ports (seulement dans la version
2 du protocole).
−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.
−p port
Port à connecter sur la machine distante. On peut aussi le spécifier pour une machine dans le fichier
de configuration.
−P
−q
Utilise un port non privilégié pour les connexions sortantes. Peut servir si on est derrière un parefeu (firewall) qui refuse les connexions depuis des ports privilégiés. Note : Cette option désactive
les options RhostsAuthentication
et RhostsRSAAuthentication
des vieux serveurs.
Mode silencieux. Supprime tous les messages d’avertissement et de diagnostic.
−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). La commande distante spécifie le sous-système.
−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.
−T
−v
Désactive l’allocation de pseudo-terminal.
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
Désactive le transfert X11.
−X
Active le transfert X11. On peut aussi le spécifier pour une machine dans le fichier de configuration.
−C
Active la compression de toutes les données (entrée standard, sortie standard, erreur standard, et
toutes les données de transfert X11 ou TCP/IP). 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 peut être souhaitable sur les lignes modem ou les connexions lentes, mais ralentit
considérablement tous les transferts si elle est activée sur les réseaux rapides. On peut aussi
spécifier la valeur par défaut pour une machine dans le fichier de configuration. Voir l’option
Compression
.
.
−F configfile
Spécifie un autre fichier de configuration pour un 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
.
−L port:host:hostport
Spécifie que le port port sur la machine locale (client) sera transféré sur le port hostport
de la
machine distante host . 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 sur le port hostport
de la machine distante host . 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. On peut spécifier des adresses IPv6 à l’aide d’une autre syntaxe :
port/host/hostport
−R port:host:hostport
Spécifie que le port donné hostport
de la machine distante host sera transféré au port port de
la machine locale. Ceci fonctionne grâce à l’allocation d’une socket qui écoute sur le port
hostport
de la machine distante host, et qui, dès qu’une connexion est établie sur ce port, la
transfère à travers le canal sécurisé, et se connecte sur le port port de 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. On
peut spécifier des adresses IPv6 à l’aide d’une autre syntaxe : port/host/hostport
−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é, et le protocole applicatif est utilisé pour
déterminer où se connecter sur la machine distante. Pour l’instant, seul le protocole SOCKS4 est
supporté, et ssh se comporte alors comme un serveur SOCKS4. Seul root peut tranférer des ports
privilégiés. On peut aussi spécifier un transfert de port dynamique dans le fichier de configuration.
−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.
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 de base de l’utilisateur (home directory).
LOGNAME
Synonyme pour USER . Réglé pour 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 , telle qu’elle était lors de la compilation de ssh .
SSH_ASKPASS
Si ssh nécessite un mot de passe (passphrase), il le 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
ouvre une fenêtre X11 pour lire le mot de passe. C’est particulièrement utile lors d’un appel de ssh
depuis .Xsession
ou un script lié. (Note : sur certaines machines, il peut être nécessaire de
et
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_CLIENT
Identifie le bout de la connexion du client. La variable contient trois valeurs séparées par des
espaces : l’adress ip du client, le numéro de port du client 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
Réglé au nom du terminal (emplacement du fichier spécial) associé à l’interpréteur de commandes
(shell) ou à la commande en cours. Si la session n’a pas de terminal, la variable n’existe pas.
TZ
USER
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).
Contient le nom de l’utilisateur qui se connecte.
En outre, ssh lit le fichier $HOME/.ssh/environment
« VARNAME=value » à l’environnement.
, et ajoute les lignes qui possèdent le format
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
Contient les identités d’authentification de l’utilisateur, respectivement pour les version RSA 1,
DSA 2 et RSA 2 du protocole. 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 un mot de passe (passphrase) lors de la création de la clef. Le mot de passe
(passphrase) est utilisé 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
les fichiers $HOME/.ssh/authorized_keys
sur toutes les 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 les fichiers $HOME/.ssh/authorized_keys
sur
les 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).
$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. Il contient les clefs publiques de toutes les machines accessibles. Ce fichier doit être lisible
par tout le monde. Ce fichier contient les clefs publique (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étho
d’authentification de la version 1 du protocole RhostsRSAAuthentication
, ssh doit être
exécuté en tant que root (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 (setuid
root) le programme ssh pour utiliser cette méthode d’authentification. Par défaut, on n’exécute pas
ssh en tant que root.
$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 de
base (home directory) 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 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
des connexions avec ssh mais sans utiliser rsh/rlogin.
. Il peut servir à autoriser
/etc/ssh/sshrc
Les commandes contenues dans ce fichier sont exécutées ssh exécute les commandes contenues
dans ce fichier à la connexion de l’utilisateur, juste avant l’exécution de l’interpréteur de commande
(shell) ou de la commande. Voir la page de manuel de sshd (8) pour plus d’information.
$HOME/.ssh/rc
exécute les commandes contenues dans ce fichier à la connexion de l’utilisateur, juste avant
l’exécution de l’interpréteur de commande (shell) 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 sortie de la commande distante, ou 255 en cas d’erreur.
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 nou-
velles fonctionnalité 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
VOIR AUSSI
rsh (1), scp (1), sftp (1), ssh-add (1), ssh-agent
(1), ssh-keygen
(1), telnet
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.