![[OpenSSH]](../images/smalltitle.gif){kind=small}
1.0 - Qu'est-ce que OpenSSH et où puis-je l'obtenir ?
- 1.1 - Qu'est-ce que OpenSSH et où puis-je l'obtenir ?
- 1.2 - Pourquoi devrait-on l'utiliser ?
- 1.3 - Quels sont les systèmes d'exploitation supportés ?
- 1.4 - Qu'en est-il des droits d'auteur, de l'utilisation et des brevets ?
- 1.5 - Comment obtenir de l'aide ?
- 1.6 - J'ai trouvé un bogue. Comment puis-je le rapporter ?
2.0 - Questions Générales
- 2.1 - Pourquoi ssh/scp établit des connexions à partir de ports privilégiés. Mon pare-feu bloque ceux-ci.
- 2.2 - Pourquoi le client ssh est setuid root ?
- 2.3 - Pourquoi SSH 2.3 a des problèmes d'interopérabilité avec OpenSSH 2.1.1 ?
- 2.4 - Pourquoi OpenSSH affiche : Dispatch protocol error: type 20
- 2.5 - Les anciennes versions de SSH commercial utilisent IDEA pour le cryptage des clés de hôtes.
- 2.6 - À quoi correspondent les messages d'avertissement concernant les longueurs de clé ?
- 2.7 - X11 et/ou agent forwarding ne fonctionne pas.
- 2.8 - Après la mise à jour de OpenSSH, j'ai perdu le support SSH2.
- 2.9 - sftp/scp échoue à la connexion mais ssh fonctionne.
- 2.10 - Allez-vous ajouter la fonctionnalité [foo] à scp ?
- 2.11 - Comment utiliser le "port forwarding" ?
- 2.12 - Ma connexion ssh se fige ou s'arrête après N minutes d'inactivité.
- 2.13 - Comment puis-je utiliser scp pour copier un fichier dont le nom comporte deux-points ?
- 2.14 - Pourquoi OpenSSH annonce sa version aux clients ?
3.0 - Questions sur la version portable de OpenSSH
- 3.1 - Faux messages d'authentification dans les journaux systèmes.
- 3.2 - Mots de passe vides non permis par l'authentification PAM.
- 3.3 - ssh(1) nécessite beaucoup de temps pour effectuer une connexion ou ouvrir une session interactive
- 3.4 - Messages d'erreur "Can't locate module net-pf- 10" dans les journaux système sous Linux.
- 3.5 - L'authentification par mot de passe ne fonctionne pas (sous Slackware 7.0 ou Red Hat Linux 6.x par exemple)
- 3.6 - Configure ou sshd(8) se plaignent de l'absence du support RSA
- 3.7 - Erreurs "scp: command not found"
- 3.8 - Incapable de lire la phrase de protection (passphrase)
- 3.9 - 'configure' manquant ou make échoue
- 3.10 - Connexions suspendues quand on quitte ssh
- 3.11 - Pourquoi ssh suspend la connexion durant la phase de sortie du programme ?
- 3.12 - J'ai effectué une mise à jour vers OpenSSH 3.1 et X11 forwarding cesse de fonctionner.
- 3.13 - J'ai mis à jour OpenSSH en version 3.8 et certains programmes X11 ne fonctionnent plus.
- 3.14 - J'ai copié ma clé dans le fichier authorized_keys mais l'authentification par clés ne fonctionne toujours pas.
- 3.15 - Les versions d'OpenSSH et leur comportement vis-à-vis de PAM.
- 3.16 - Pourquoi "w" et "who" ne montrent pas les utilisateurs logués via ssh sur AIX 5.x ?
OpenSSH fournit un chiffrement de bout en bout pour remplacer des applications comme telnet, rlogin et ftp. À l'opposé de ces applications, OpenSSH ne fait jamais passer quelque chose (incluant les identifiants et mots de passe) sur le réseau en clair, et fournit une authentification par hôte, pour vérifier que vous communiquez véritablement au bon système que vous pensez être et personne ne peut récupérer votre session.
La suite OpenSSH inclut le programme ssh(1) qui remplace rlogin et telnet et scp(1) qui remplace rcp(1) et ftp(1). OpenSSH a ajouté sftp(1) et sftp-server(8) qui implémentent une méthode plus facile de transfert de fichiers, en se basant sur l'ébauche secsh-filexfer de l'IETF.
OpenSSH est constitué d'un certain nombre de programmes.
La version la plus récente d'OpenSSH est incluse avec la distribution courante de OpenBSD, et installée par défaut dans l'installation de base.
Aujourd'hui, la plupart des systèmes d'exploitation incluent une version d'OpenSSH (souvent renommée ou nommé de manière interne), donc la plupart des utilisateurs peuvent l'utiliser immédiatement. Cependant, quelquefois les versions incluses sont assez anciennes, et il manque des fonctionnalités de la version courante de OpenSSH, et vous désirez installer la version courante, ou l'installer sur un des OSs ou il n'est pas disponible, et ou l'auteur de l'OS ne fournit pas une version récente disponible. Vous pouvez aussi désirer utiliser OpenSSH dans votre système embarqué.
Les utilisateurs Non-OpenBSD pourront télécharger, compiler et installer la distribution multiplate-forme Portable d'un miroir près de chez vous.
OpenSSH est une suite d'outils dont l'objectif est de vous aider à sécuriser vos connexions réseau. Voici une liste de fonctionnalités :
Actuellement, pratiquement toutes les communications dans les réseaux informatiques sont effectuées sans cryptage. Par conséquent, n'importe quelle personne qui a un accès à n'importe quelle machine connectée au réseau peut écouter n'importe quelle communication. C'est ce que font les pirates, les administrateurs curieux, les employés, les criminels, les espions industriels et les gouvernements. Certains réseaux ont assez de fuites de radiations électromagnétiques pour permettre des captures de données à distance.
Quand vous vous loguez, votre mot de passe transite dans le réseau en clair. Ainsi, n'importe quelle personne à l'écoute peut alors utiliser votre compte pour effectuer des opérations malintentionnées. Plusieurs incidents ont été constatés au niveau mondial lorsque des pirates ont démarré des programmes sur des stations de travail sans que les propriétaires en prennent connaissance juste pour écouter le réseau et collecter des mots de passe. Des programmes pour faire de telles choses sont disponibles sur Internet, ou peuvent être développés par un programmeur compétent en quelques heures.
Les entreprises ont des secrets de fabrication, des demandes de brevets en préparation, des informations de prix, des informations sur les contractants, des données client, des données sur le personnel, des informations financières, etc... De nos jours, n'importe qui ayant un accès au réseau (n'importe lequel) peut écouter tout ce qui se passe sur le réseau, sans respect des restrictions d'accès en place.
Bien des entreprises ne sont pas conscientes que l'information peut être très facilement récupérée à partir du réseau. Ils croient que leurs données sont saines et sauves puisque personne n'est supposé savoir qu'il y a des informations sensibles dans le réseau, ou parce que beaucoup d'autres données sont transférées sur le réseau. Cette politique n'est pas sûre.
Bien que OpenSSH soit développé sur OpenBSD, il existe une grande variété de portages vers d'autres systèmes d'exploitation. la version portable de OpenSSH est dirigée par Damien Miller. Pour une vue d'ensemble rapide de la version portable de OpenSSH veuillez consulter OpenSSH Portable Release. Les systèmes d'exploitation actuellement supportés sont :
Une liste d'éditeurs qui incluent OpenSSH dans leurs systèmes se trouve dans la page des Systèmes utilisant OpenSSH.
Les développeurs d'OpenSSH ont fait beaucoup d'efforts pour éviter tout problème de brevet ou de droit d'auteur. À cet effet, quelques options ont été retirées de OpenSSH; plus précisément le support d'algorithmes brevetés.
OpenSSH ne supporte aucun algorithme de transport breveté. En mode SSH1, seuls 3DES et Blowfish sont disponibles. En mode SSH2, seulement 3DES, Blowfish, CAST128, Arcfour et AES peuvent être choisis. L'algorithme breveté IDEA n'est pas supporté.
OpenSSH fournit le support du protocole SSH1 ainsi que du protocole SSH2.
Étant donné que le brevet RSA a expiré, il n'y a plus de restrictions au niveau de l'utilisation logicielle de l'algorithme RSA, y compris OpenBSD.
Il y a plusieurs endroits où on peut trouver de l'aide. En plus du site web principal de OpenSSH, il existe plusieurs listes de discussion. Avant de poster sur celles-ci, merci d'effectuer des recherches au niveau des archives de ces listes pour voir s'il n'y a pas déjà une réponse à votre question. La liste de diffusion OpenSSH a été archivée et mise dans une forme facilitant les recherches sur marc.info.
Pour plus d'informations concernant l'abonnement aux listes de diffusion relatives à OpenSSH, veuillez consulter la page des listes de diffusion OpenSSH.
Les informations concernant l'envoi de rapports de bogues se trouvent dans la page Reporting bugs.
Si souhaitez rapporter un bogue relatif à la sécurité, contactez s'il vous plaît la liste privée des développeurs <openssh@openssh.com>.
Le client OpenSSH utilise des ports non-élevés pour l'authentification rhosts et rhosts-rsa parce que le serveur a besoin de se fier au nom d'utilisateur fourni par le client. Pour désactiver ce comportement, vous pouvez ajouter la ligne suivante à votre fichier ssh_config ou à ~/.ssh/config.
UsePrivilegedPort no
Autrement vous pouvez spécifier cette option au niveau de la ligne de commande en utilisant l'option -o de la commande ssh(1).
$ ssh -o "UsePrivilegedPort no" host.com
Conjointement avec la question précédente (2.1), OpenSSH a besoin de l'autorité root pour être capable de s'attacher à des ports privilégiés afin de faciliter l'authentification rhosts. Un port privilégié est aussi requis pour l'authentification rhosts-rsa sur les anciennes versions de SSH.
De plus, dans le cas de l'authentification rhosts-rsa (dans le
protocole version 1) et l'authentification hostbased dans le
protocole version 2), le client ssh a besoin d'accéder à la clé
privée d'hôte pour authentifier la machine cliente auprès du
serveur.
Pour ce faire, les versions d'OpenSSH antérieures à 3.3 nécessitent un
bit setuid root positionné sur le binaire ssh. Si vous
n'utilisez pas ce mode d'authentification, vous pouvez supprimer ce bit
sans problème.
À partir d'OpenSSH 3.3, ssh n'est pas setuid par défaut.
ssh-keysign
est utilisé pour accéder aux clés privés d'hôtes, et ssh n'utilise pas
les ports source privilégiés par défaut. Si vous souhaitez utiliser un
port source privilégié, vous devez positionner manuellement le bit
setuid pour ssh.
SSH 2.3 et les versions antérieures contiennent un défaut dans leur implémentation HMAC. Leur code ne fournissait pas le bloc de données entier obtenu à partir du digest. Au lieu de cela, ils fournissaient toujours 128 bits. Pour des digests plus grands, ceci entraînait des problèmes d'interopérabilité de SSH 2.3 avec OpenSSH.
OpenSSH 2.2.0 détecte ce défaut sur SSH 2.3. Les versions récentes de SSH corrigent ce problème. Autrement, vous pouvez ajouter la ligne suivante à sshd2_config de SSH 2.3.
Mac hmac-md5
Des problèmes d'interopérabilité ont été constatés car les anciennes versions de OpenSSH ne supportent pas la renégociation des clés de sessions. Cependant, SSH commercial 2.3 essaie de négocier cette fonctionnalité, dès lors vous pourriez avoir des gels de connexion ou voir le message d'erreur "Dispatch protocol error: type 20 ". Pour résoudre ce problème, effectuez une mise à jour vers une version récente de OpenSSH ou désactivez la renégociation de clés en ajoutant la ligne suivante au niveau du fichier ssh2_config ou sshd2_config sur la version commerciale SSH 2.3.
RekeyIntervalSeconds 0
Les anciennes versions de SSH utilisaient un algorithme breveté pour crypter leur /etc/ssh/ssh_host_key. Ce problème se manifeste lorsque sshd(8) ne peut pas lire sa clé d'hôte. Pour le résoudre, utilisez la commande ci-après pour convertir votre ssh_host_key en 3DES. REMARQUE : utilisez le programme ssh-keygen(1) du produit commercial SSH, *PAS* OpenSSH pour l'exemple ci-dessous.
# ssh-keygen -u -f /etc/ssh/ssh_host_key
Le programme ssh-keygen(1) de SSH commercial contenait un bogue qui lui faisait occasionnellement générer des clés Pubkey Authentication (RSA or DSA) qui avait leur bit à poids le plus significatif (Most Significant Bit ou MSB) non positionné. De telles clés étaient annoncées comme étant à longueur complète alors qu'en réalité elles sont plus petites une fois sur deux.
OpenSSH affichera des messages d'avertissement quand de telles clés sont rencontrées. Pour se débarrasser de ces messages, éditez vos fichiers known_hosts et remplacez la fausse longueur de clé (habituellement "1024") avec la vraie longueur (habituellement "1023").
Vérifiez ssh_config et sshd_config. Les fichiers de configuration par défaut désactivent le X11 et le agent forwarding. Pour activer ces options, ajoutez la ligne suivante à sshd_config :
X11Forwarding yes
et ajoutez les lignes suivante à ssh_config:
ForwardAgent yes
ForwardX11 yes
L'export X11 ("X11 forwarding") nécessite un binaire xauth(1) fonctionnel. Sous OpenBSD, on peut le trouver dans le jeu de fichiers xbase mais cela sera probablement différent sous d'autres plates-formes. En ce qui concerne OpenSSH Portable, xauth devra être présent au moment de la compilation ou spécifié avec l'option XAuthLocation dans sshd_config(5) et ssh_config(5).
Remarque sur l'interopérabilité des agents : il y a deux types différents et incompatibles de mécanismes "agent forwarding" au sein du protocole SSH2. OpenSSH a toujours utilisé une extension des requêtes de l'agent SSH1 original, alors que les produits commerciaux en utilisent un autre, non libre. Cela signifie donc que l' "agent forwarding" ne peut pas être utilisé entre OpenSSH et ces protocoles.
REMARQUE : Pour les utilisateurs de Linux Mandrake 7.2, Mandrake modifie la variable d'environnement XAUTHORITY dans /etc/skel/.bashrc, ce qui a pour effet de la modifier pour tous les utilisateurs. Cette variable est positionnée par OpenSSH et pour que les options ci-dessus fonctionnent, vous devez mettre en commentaire la ligne :
# export XAUTHORITY=$HOME/.Xauthority
Entre des versions différentes, des modifications peuvent être apportées à sshd_config ou ssh_config. Vous devriez toujours vérifier ces modifications lors de la mise à jour OpenSSH. Après la version 2.3.0 de OpenSSH, vous aurez besoin d'ajouter ce qui suit à sshd_config.
HostKey /etc/ssh_host_dsa_key
HostKey /etc/ssh_host_rsa_key
sftp et/ou scp peuvent échouer à la connexion si vous avez une initialisation du shell (.profile, .bashrc, .cshrc, etc) qui produit une sortie pour des sessions non-interactives. Cette sortie rend le client sftp/scp confus. Vous pouvez vérifier ceci en exécutant la commande suivante :
ssh yourhost /usr/bin/true
Si la commande ci-dessus génère une sortie, alors vous aurez besoin de modifier votre initialisation du shell.
Réponse courte : non.
Réponse longue : scp n'est pas une commande standard. La seule spécification approchante de ce que fait scp est celle de rcp. Étant donné que c'est la même commande qui est utilisée par les deux extrémités de la communication, l'ajout de fonctionnalités ou d'options risque de casser l'interopérabilité avec d'autres implémentations.
De nouvelles fonctionnalités peuvent cependant être introduites dans sftp, le protocole étant standardisé (ou presque, il y a un document de travail), extensible, et client et serveur sont découplés.
Si le serveur distant est un serveur sshd(8), il est possible de créer un tunnel pour certains services via ssh. Ceci peut être utile pour chiffrer des connexions POP ou SMTP même si les logiciels ne supportent pas directement les communications chiffrées. La création d'un tunnel se base sur le "port forwarding" pour créer une connexion entre le client et le serveur. Le logiciel client doit être capable de spécifier un port non-standard auquel se connecter pour que cette technique fonctionne.
Pour créer un tunnel chiffré par ssh, l'utilisateur se connecte à l'hôte distant en utilisant ssh et spécifie le port sur la machine cliente qui devra être utilisé pour y passer les connexions à destination du serveur distant. Il devient alors possible de démarrer le service à chiffrer (par exemple fetchmail, irc ...) sur la machine cliente en précisant le même port local que celui précédemment fourni. La connexion sera dès lors chiffrée dans le tunnel ssh. Par défaut, le système depuis lequel le forwarding a été initié n'acceptera des connexions qu'à partir de lui-même.
Les options à utiliser pour la création des tunnels sont les options -L et -R, qui permettent à l'utilisateur de faire passer des connexions à travers des tunnels, l'option -D qui permet de faire du "port forwarding" dynamique, l'option -g qui permet à d'autres hôtes d'utiliser les tunnels créés sur une machine donnée, et l'option -f qui permet de mettre ssh en tâche de fond après authentification. Veuillez consulter la page de manuel ssh(1) pour de plus amples détails.
Voici un exemple pour créer un tunnel pour une session IRC entre une machine cliente ``127.0.0.1'' (localhost) et un serveur distant ``server.example.com'':
ssh -f -L 1234:server.example.com:6667 server.example.com sleep 10
irc -c '#users' -p 1234 pinky 127.0.0.1
La commande ci-dessus crée un tunnel pour une connexion IRC vers le serveur server.example.com. L'utilisateur veut se joindre au canal "#users", il a pour surnom "pinky". Le port local utilisé dans cet exemple est le port 1234. Le numéro de port importe peu tant qu'il est supérieur à 1023 (autrement, seul "root" peut ouvrir des sockets sur les ports privilégiés soit tous les ports inférieurs à 1024) et qu'il n'entre en conflit avec aucun port utilisé sur la machine. La connexion est chiffrée dans le tunnel jusqu'au serveur distant puis une fois déchiffrée, elle est envoyée sur le port 6667 du serveur vu que c'est le port standard utilisé par les services IRC.
La commande distante "sleep 10" est utilisée pour spécifier le temps d'attente (10 secondes dans l'exemple précité) avant le démarrage du service qui doit transiter à travers le tunnel. Si aucune connexion n'est effectuée durant ce temps d'attente, ssh s'arrête. Si un temps d'attente plus important est nécessaire, la valeur de sleep(1) peut être augmentée en conséquence, autrement l'exemple ci-dessus pourrait être ajouté comme fonction au shell utilisateur. Consultez les pages du manuel de ksh(1) et csh(1) pour plus de détails concernant les fonctions définies par l'utilisateur.
ssh possède aussi une option -N, pratique pour une utilisation de ssh en "port forwarding" : si -N est spécifiée, il n'est plus nécessaire d'utiliser une commande distante ("sleep 10" dans l'exemple ci-dessus). Cependant, l'utilisation de cette option oblige ssh à attendre indéfiniment (alors qu'avec une commande distante, ssh s'interrompra après la fin d'exécution de cette dernière). L'utilisateur devra alors mettre fin manuellement au processus ssh.
Ceci est généralement dû à l'expiration de votre session ssh au niveau d'un pare-feu ou d'un équipement de NAT en raison d'inactivité. Afin d'éviter cela, vous pouvez activer ClientAliveInterval dans le fichier de configuration serveur sshd_config, ou activer ServerAliveInterval dans le fichier de configuration client ssh_config. Cette dernière option n'est disponible qu'à partir de OpenSSH 3.8.
L'activation d'une des options précitées en positionnant leur valeur à un intervalle plus petit que le temps d'inactivité avant expiration de la session permettra de garder la session dans la table de connexion de l'équipement, sans que la session expire.
$ scp ./source:file sshserver:
Comme la plupart des implémentations SSH, OpenSSH annonce son nom et sa version aux clients lorsque ces derniers initient une connexion. Par exemple :
SSH-2.0-OpenSSH_3.9
Cette information est utilisée par les clients et les serveurs pour activer des options de compatibilité protocolaire pour contourner des fonctionnalités modifiées, problématiques ou absentes au niveau de l'implémentation vers laquelle la connexion est initiée. Cette fonctionnalité de vérification du protocole est encore requise à l'heure actuelle car des versions avec des incompatibilités sont encore largement utilisées.
La version portable de OpenSSH générera de faux messages d'authentification à chaque login, similaires à :
"authentication failure; (uid=0) -> root for sshd service"
Ces messages sont générés car OpenSSH essaie d'abord de déterminer si un utilisateur a besoin d'authentification pour se loguer (par exemple, un mot de passe vide). Malheureusement, PAM aime enregistrer tous les événements d'authentification, y compris celui-ci.
Si cela vous gêne beaucoup, positionnez "PermitEmptyPasswords no" dans sshd_config. Ceci aura pour effet de stopper le message d'erreur mais en désactivant, par la même occasion, les connexions à des comptes sans mot de passe. C'est le comportement par défaut si vous utilisez le fichier sshd_config fourni.
Pour permettre l'utilisation de mots de passe vides avec une version de OpenSSH construite avec PAM, vous devez ajouter le drapeau nullok à la fin du module de vérification du mot de passe dans le fichier /etc/pam.d/sshd. Par exemple :
auth required/lib/security/pam_unix.so shadow nodelay nullok
Cette action doit être effectuée en plus du positionnement "PermitEmptyPasswords yes" dans le fichier sshd_config.
Il y a un problème lorsque des mots de passe vides sont utilisés avec l'authentification PAM : PAM autorisera n'importe quel mot de passe quand on s'authentifie sur un compte doté d'un mot de passe vide. Ce qui a pour effet de casser la vérification que sshd(8) effectue pour déterminer si un compte n'a pas de mot de passe positionné et autorise l'accès quelque soit la politique spécifiée par PermitEmptyPasswords. Pour cette raison, il est recommandé de ne pas ajouter la directive nullok à votre fichier de configuration PAM à moins que vous souhaitiez spécifiquement autoriser les mots de passe vides.
D'importants délais (plus de 10 secondes) à la connexion sont typiquement causés par un problème au niveau de la résolution de noms :
nslookup
pour vérifier la résolution de noms et des adresses IP du client sur le
serveur et vice-versa. Vous pouvez désactiver la plupart des résolutions
DNS effectuées côté serveur en utilisant UseDNS no dans
sshd_config.Des délais de moins de 10 secondes peuvent avoir d'autres causes.
ssh. À cause de ce défaut, ssh demande du moduli
plus grand que nécessaire. Combiné au problème précité, les baisses de
performance étaient encore plus significatives. La mise à jour du client en
version 3.8 ou supérieure résout ce problème.ssh-rand-helper
pour générer de l'entropie ne rend pas la main. Pour vérifier si c'est le
cas, il suffit de l'exécuter en mode debug :
Tout délai significatif à la connexion doit être investigué et corrigé. Sinon, il suffira de supprimer les commandes posant problème du fichier ssh_prng_cmds.
/usr/local/libexec/ssh-rand-helper -vvv
time ssh localhost
true avec une clé RSA de 1024 bits sur des machines non
chargées. OpenSSH et OpenSSL ont été compilés avec gcc 3.3.x.
| CPU | Time (SSHv1)[1] | Time (SSHv2) |
|---|---|---|
| 170MHz SPARC/sun4m | 0.74 sec | 1.25 sec |
| 236MHz HPPA/8200[2] | 0.44 sec | 0.79 sec |
| 375MHz PowerPC/604e | 0.38 sec | 0.51 sec |
| 933MHz VIA Ezra | 0.34 sec | 0.44 sec |
| 2.1GHz Athlon XP 2600+ | 0.14 sec | 0.22 sec |
Le noyau Linux recherche (à travers modprobe) la famille de protocoles 10 (IPv6). Il faut soit charger le module noyau approprié, soit saisir l'alias correct dans /etc/modules.conf ou désactiver IPv6 dans /etc/modules.conf.
Pour une raison inconnue, /etc/modules.conf peut aussi s'appeler /etc/conf.modules.
Si le mot de passe est correct mais la connexion est refusée, il est fort probable que le système soit configuré pour utiliser des mots de passe de type MD5. Cependant, la fonction crypt(3) utilisée par sshd ne sait pas les interpréter.
Les comptes d'utilisateurs affectés par ce problème contiendront dans les fichiers /etc/passwd ou /etc/shadow les caractères $1$ en début de la chaîne représentant le mot de passe. Vous pouvez être pratiquement sûr que tel est le problème lorsque l'authentification par mots de passe échoue pour les nouveaux comptes ou pour les comptes dont le mot de passe a été changé récemment, alors qu'elle fonctionne pour les anciens comptes.
La cause sous-jacente de ce problème est l'existence de certaines versions d'OpenSSL dont la fonction crypt(3) ne sait pas interpréter les mots de passe MD5 et l'ordre de liage des bibliothèques au sein de sshd donne une préférence à la fonction crypt(3) fournie par le système. Le programme configure d'OpenSSH tente de corriger ce problème lorsqu'il le détecte mais il n'est pas toujours couronné de succès.
Il existe plusieurs solutions possibles :
Activer le support natif des mots de passe MD5 de sshd à la compilation.
Cette solution est sans danger même si vous avez les deux types de chiffrement du mot de passe. En effet, sshd sélectionnera automatiquement l'algorithme adapté pour chaque compte.
./configure --with-md5-passwords [options]
Si votre système a une bibliothèque libcrypt séparée (tel que Slackware 7), vous pouvez ajouter manuellement -lcrypt à la liste LIBS pour que cette bibliothèque soit utilisée au lieu de celle d'OpenSSL.
LIBS=-lcrypt ./configure [options]
Si votre plate-forme supporte PAM, vous pouvez configurer sshd de telle manière à ce qu'il utilise les fonctionnalités PAM (voir la section 3.15). Ceci se traduira alors par une modification dans la manière utilisée par sshd pour vérifier la validité des mots de passe qui lui sont soumis : il fera appel aux modules PAM configurés pour cette vérification au lieu de le faire lui-même.
Assurez-vous que vos bibliothèques OpenSSL disposent du support RSA ou DSA soit en interne soit à travers RSAref.
scp(1) doit être dans le PATH par défaut sur le client et sur le serveur. Vous aurez peut-être besoin d'utiliser l'option --with-default-path pour spécifier un chemin particulier à inclure sur le serveur. Cette option remplace le chemin par défaut. Vous aurez donc besoin de spécifier tous les répertoires actuellement dans votre chemin aussi bien que le répertoire dans lequel se trouve scp. Par exemple :
$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
La configuration effectuée par l'administrateur du serveur est prioritaire par rapport à --with-default-path. Ceci inclut la mise à zéro de PATH dans /etc/profile, PATH dans /etc/environment sous AIX, ou (pour les versions d'OpenSSH supérieures ou égales à 3.7p1), le positionnement de PATH ou de SUPATH dans /etc/default/login sous Solaris ou Reliant Unix.
Certains systèmes d'exploitation positionnent des permissions incorrectes sur /dev/tty. En conséquence, la lecture de mots de passe échoue avec l'erreur suivante :
You have no controlling tty. Cannot read passphrase.
La solution consiste à positionner les permissions à 0666 sur /dev/tty et soumettre l'erreur comme étant un bogue à l'éditeur de votre OS.
S'il n'y a pas de fichier 'configure' dans le fichier tar.gz que vous avez téléchargé ou si make échoue avec des erreurs du type "missing separator", vous avez probablement téléchargé la distribution OpenBSD de OpenSSH et vous êtes en train d'essayer de la compiler sur une autre plate-forme. Merci de consulter la page portable version.
OpenSSH peut suspendre une connexion en phase de terminaison. Ceci peut arriver quand il y a un processus actif en arrière-plan. C'est un problème connu sous Linux et HP-UX. On peut vérifier son existence en faisant :
Ou essayez plutôt d'utiliser la commande suivante :
$ sleep 20 & exit
$ sleep 20 < /dev/null > /dev/null 2>&1 &
Une solution de contournement pour les utilisateurs bash est de mettre "shopt -s huponexit" soit dans /etc/bashrc soit dans ~/.bashrc. Autrement, consultez la page de manuel de votre shell pour une option qui permet d'envoyer un signal HUP à des tâches actives durant la phase de terminaison. Consultez bug #52 pour d'autres solutions de contournement.
Quand la commande
est exécutée, ssh a besoin de suspendre la connexion, car il doit attendre :
$ ssh host command
command n'a
pas besoin d'autres informations en entrée.
command ne
produit pas d'autres informations en sortie.
command finisse car sshd a besoin
de communiquer le code de sortie de command à
ssh.
De manière générale, les clients X11 utilisant X11 R6 devraient fonctionner avec le paramétrage par défaut. Certains éditeurs, HP compris, utilisent sur leurs systèmes des clients X11 avec des bibliothèques R6 et R5. Ainsi, certains clients vont fonctionner et d'autres ne fonctionneront pas. C'est le cas pour HP-UX 11.X.
Tel que c'est documenté dans les notes
d'information de la version 3.8, ssh utilise désormais
les cookies X11 non dignes de confiance par défaut. Le comportement
précédent peut être restauré en positionnant ForwardX11Trusted yes
dans ssh_config.
Voici une liste de quelques symptômes possibles :
BadWindow
(invalid Window parameter)
BadAccess (attempt to access private
resource denied)
X Error of failed request: BadAtom (invalid Atom
parameter)
Major opcode of failed request: 20
(X_GetProperty)
Ce problème est typiquement causé par des permissions plus larges que celles permises par sshd par défaut pour les répertoires $HOME, $HOME/.ssh ou le fichier $HOME/.ssh/authorized_keys.
Dans ce cas, l'exécution des commandes suivantes sur le serveur résoudra le problème :
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ chown `whoami` $HOME/.ssh/authorized_keys
Si, pour quelque raison que ce soit, ce n'est pas envisageable de faire ça une solution alternative consiste à positionner StrictModes no dans sshd_config, cependant cette solution n'est pas recommandée.
Pour activer le support PAM, cette option doit être utilisée à la compilation. Le comportement de la version portable d'OpenSSH, lorsque le support PAM est activé, dépend de la version utilisée et, dans le cas des versions les plus récentes, du positionnement de la directive UsePAM à yes dans le fichier de configuration sshd_config.
./configure --with-pam [options]
Le tableau ci-après résume le comportement des options d'authentifications lorsque le support PAM est activé.
| Version | Valeur par défaut de UsePAM | PasswordAuthentication | ChallengeResponseAuthentication |
|---|---|---|---|
| <=3.6.1p2 | Non applicable | Utilise PAM | Utilise PAM si PAMAuthenticationViaKbdInt est activé |
| 3.7p1 - 3.7.1p1 | yes | N'utilise pas PAM | Utilise PAM si UsePAM est activé |
| 3.7.1p2 - 3.8.1p1 | no | N'utilise pas PAM [1] | Utilise PAM si UsePAM est activé |
| 3.9p1 | no | Utilise PAM si UsePAM est activé | Utilise PAM si UsePAM est activé |
[1] Certains éditeurs, notamment Red Hat/Fedora, ont intégré le comportement de PasswordAuthentitication de la version 3.9p1 à leurs paquetages 3.8x. Si vous utilisez un paquetage fourni par un éditeur, consultez la documentation qui l'accompagne.
L'interface PAM de la version portable d'OpenSSH a encore quelques problèmes avec certains modules. Nous espérons toutefois réduire le nombre de ces problèmes dans le futur. Les problèmes connus au niveau de la version 3.9p1 sont les suivants :
www@openbsd.org