Que pourrait signifier «Roaming non autorisé par le serveur» du client ssh?

25

Je n'arrive pas à me connecter à une instance de serveur SSH et la sortie détaillée contient debug1: Roaming not allowed by server. Les problèmes prévisibles et évitables suivants surviennent:

  • L'itinérance signifie accéder aux services de différents types de réseaux. Je ne peux pas comprendre ce que cela pourrait signifier dans le contexte de la sortie détaillée d'un sshclient 6.6.1 fonctionnant sur Ubuntu 14.04.
  • Il n'est pas clair si c'est une erreur ou non et si c'est la cause de l'échec de la connexion ou non (je ne veux pas plonger ici dans l'échec de la connexion; cependant, aucun des messages de sortie de sshBTW -> plus de problèmes et de temps perdu - vous avez été prévenu!)
  • J'ai demandé site:www.openssh.org roamingdans google avec un résultat vide et les pages de manuel ne contiennent pas le terme. Il est absurde de l'utiliser même s'il a été documenté en raison de son ambiguïté!

Que pouvait signifier le message? Comment pourrais-je l'utiliser pour déboguer le grand ensemble d'autres erreurs et autres messages très ambigus, peu intuitifs et inutiles de SSH?

Karl Richter
la source

Réponses:

22

Ce n'est pas vraiment un message d'erreur. Il s'agit simplement d'un message de débogage vous indiquant que le serveur n'accepte pas les connexions itinérantes.

L'itinérance est apparemment une fonctionnalité expérimentale ajoutée à OpenSSH en 2009 environ. Le but de la fonctionnalité est de permettre à un client ssh de se déconnecter d'une session serveur, puis de reprendre la session à partir d'un autre emplacement. Voir ici pour une discussion à ce sujet. Googler ssh, roaming et "Martin Forssén" affichera d'autres pages. Il ne semble pas qu'il soit activement développé. Je soupçonne que les développeurs SSH ne l'ont jamais documenté car il est expérimental et peut-être pas terminé.

De l'inspection du code source d'OpenSSH, il existe une option côté client non documentée UseRoamingqui peut être définie sur oui ou non. L'ajout de la ligne "UseRoaming no" à votre configuration client (normalement votre .ssh/configfichier) devrait supprimer le message de débogage.

Il n'était pas évident pour moi pourquoi le HostbasedAuthenticationparamètre côté serveur contrôlerait si le serveur accepte les connexions itinérantes ou non.

Mise à jour: La prise en charge de l'itinérance client fait apparemment l'objet d'un rapport d'exposition aux vulnérabilités informatiques, CVE-2016-0777 . Les versions d'OpenSSH 5.4 à 7.1p1 sont vulnérables. Les utilisateurs doivent mettre à niveau vers OpenSSH 7.1p2 ou version ultérieure. Les utilisateurs qui ne peuvent pas mettre à niveau doivent désactiver l'itinérance dans le client en ajoutant "UseRoaming no" à leur configuration client ssh. Voir ce qui suit:

Kenster
la source
7
Eh bien, il est maintenant recommandé de le régler sur non. mail-archive.com/[email protected]/msg144351.html
nikeee
1
@nikeee: ... et c'est une mise en garde pour ne pas envoyer de talons inoffensifs "inoffensifs". (Notez que vous devez le configurer nodans les paramètres client , pas sur le serveur)
Piskvor
@Piskvor mais il y a pas mal de livres de devops / webops qui se propagent en faisant ça ... pourraient-ils se tromper? Oh.
Florian Heigl
meilleure explication de cette config sur le net.
nils petersohn
4

Le journal des modifications de openssh 5.3 sur CentOS6 a une note:

2009/06/27
     Ajouter l'option client UseRoaming. Il ne fait rien encore mais
     contrôler si le client essaie d'utiliser l'itinérance s'il est activé sur le
     serveur. De Martin Forssen.
Andrew Daviel
la source
3

@ ILMostro_7 chmod 600 authorized_keys a bien fonctionné pour moi.

Pour le bénéfice de toute autre personne qui arrive ici en recherchant sur Google "Itinérance non autorisée par le serveur" et utilisant un client Linux (Ubuntu), vous pouvez corriger cet avertissement et voir ensuite : -

Agent admitted failure to sign using the key

Le remède à cela est donné à https://help.github.com/articles/error-agent-admitted-failure-to-sign/

    # start the ssh-agent in the background
    $ eval "$(ssh-agent -s)"
    # Agent pid 59566 (displays process id)
    $ ssh-add
    # Enter passphrase for /home/you/.ssh/id_rsa: [tippy tap]
    # Identity added: /home/you/.ssh/id_rsa (/home/you/.ssh/id_rsa)

'#' = commentaire. vous = votre-nom d'utilisateur. [tippy tap] = humo [u] r? = appuyez sur la touche Entrée.

J'espère que cela aide quelqu'un autant que ce Q&R m'a déjà aidé.

MartinRH
la source
2

Ce message d'erreur peut s'afficher lorsqu'il /etc/ssh/sshd_confign'est pas HostbasedAuthenticationdéfini yessur le serveur.

Je ne sais pas pourquoi.

Un autre problème peut être:

Vérifiez les autorisations sur le répertoire $ USER / .ssh qui doit appartenir à l'utilisateur et être chmod 700. Le fichier authorized_keys doit également être chmod 700 et détenu par l'utilisateur

Nifle
la source
700? Pourquoi auriez-vous besoin de executebits sur le fichier de clés?
ILMostro_7
D'où vient la citation? Veuillez ajouter une référence.
Karl Richter
ILMostro_7 n'est pas dans le fichier, il est dans le répertoire, et pour que l'utilisateur puisse créer des fichiers dans le répertoire, l'indicateur d'exécution doit être défini
IceyEC
@IceyEC La réponse suggère 700 pour authorized_keys .
mdrozdziel
1
Devrait l'être chmod 400. Je ne sais pas pourquoi je voudrais que ce fichier soit exécutable; et l'accès en écriture n'est pas non plus souhaitable 99,999% du temps. sshdvérifie que le .sshdossier de l'utilisateur n'a pas accès au groupe et aux autres, et de même pour .ssh/authorized_keys. Par conséquent, les perms dans la réponse peuvent fonctionner, mais ils sont inutilement larges.
Piskvor