web-dev-qa-db-fra.com

ssh renvoie le message "La demande de transfert X11 a échoué sur le canal 1"

Lorsque je ssh sur un serveur distant qui n'exécute aucun type d'environnement de bureau X11, j'obtiens le message suivant.

$ ssh user@server
X11 forwarding request failed

$ ssh user@server ls
X11 forwarding request failed on channel 1
file1
file2
...

Comment puis-je me débarrasser de ces messages?

sshx11
36
slm

Ces messages peuvent être éliminés via 1 des 3 méthodes, en utilisant uniquement les options SSH. Vous pouvez toujours envoyer des messages à /dev/null aussi, mais ces méthodes essaient de traiter le message via la configuration, plutôt que de simplement les piéger et les vider.

Méthode n ° 1 - installer xauth

Le serveur auquel vous vous connectez se plaint de ne pas pouvoir créer une entrée dans le .Xauthority fichier, car xauth n'est pas installé. Vous pouvez donc l'installer sur chaque serveur pour vous débarrasser de ce message ennuyeux.

Sur Fedora 19, vous installez xauth comme ceci:

$ Sudo yum install xorg-x11-xauth

Si vous essayez ensuite de ssh dans le serveur, vous verrez un message indiquant qu'une entrée est en cours de création dans le .Xauthority fichier.

$ ssh root@server
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

Les connexions suivantes n'afficheront plus ce message.

Méthode n ° 2 - désactivez-la via ForwardX11

Vous pouvez demander au client ssh de ne pas tenter d'activer le transfert X11 en incluant le paramètre SSH ForwardX11.

$ ssh -o ForwardX11=no root@server

Vous pouvez faire la même chose avec le -x commutateur:

$ ssh -x root@server

Cela ne désactivera que temporairement ce message, mais c'est une bonne option si vous ne pouvez pas ou ne voulez pas installer xauth sur le serveur distant.

Méthode # 3 - désactivez-la via sshd_config

Il s'agit généralement de la valeur par défaut, mais dans le cas contraire, vous pouvez configurer votre serveur sshd pour que X11Forwarding soit désactivé, dans /etc/ssh/sshd_config.

X11Forwarding no

Parmi les 3 méthodes que j'utilise généralement # 2, parce que je veux souvent X11Forwarding activé pour la plupart de mes serveurs, mais je ne veux pas voir le X11.... avertissements

$ HOME/.ssh/config

La plupart du temps, ces messages ne s'affichent même pas. Ils ne sont généralement présents que lorsque vous avez les entrées suivantes dans votre $HOME/.ssh/config fichier, en haut.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

C'est donc cette configuration, qui conduit finalement à la génération de ces X11.. messages, encore une fois, la méthode n ° 2 semble être la plus appropriée si vous souhaitez fonctionner avec ForwardX11 yes activé par défaut, mais désactivez-le de manière sélective pour certaines connexions du point de vue du client ssh.

Sécurité

Il est généralement déconseillé de courir avec ForwardX11 yes allumé en tout temps. Donc, si vous souhaitez exploiter vos connexions SSH dans le manoir le plus sécurisé possible, il est préférable de procéder comme suit:

  1. N'incluez pas ForwardX11 yes dans ton $HOME/.ssh/config fichier
  2. N'utilisez ForwardingX11 que lorsque vous devez passer par ssh -X user@server
  3. Si vous le pouvez, désactivez X11Forwarding complètement sur le serveur donc il n'est pas autorisé

Références

42
slm

J'ai traversé cela aujourd'hui et me suis battu la tête pendant un certain temps jusqu'à ce que je tombe sur un paramètre ssh:

Si c'est RHEL 7 (centOS, OEL, etc.), et si ipv6 est désactivé, il a besoin de:

AddressFamily inet

défini dans/etc/ssh/sshd_config.

13
Systemspoet

Dans mon cas, l'ajout de cette chaîne à /etc/ssh/sshd_config résolu le problème:

X11UseLocalhost no
13
user3132194

Une autre légère variation serait si vous vouliez cesser de voir ce message (c'est-à-dire cesser d'essayer de transférer X11) pour certains serveurs mais conserver la valeur par défaut à ForwardX11 oui pour toutes les autres connexions.

Pour ce scénario, vous pouvez désactiver le transfert X11 pour un hôte (ou une plage) spécifique dans votre ~/.ssh/config. Quelque chose comme ça:

Host 10.1.1.*
ForwardX11 no

Remerciements: Ceci est un léger embellissement de la réponse existante (et très complète) existante - car je ne pouvais pas commenter!

2
philarmour

Si vous exécutez le client en mode détaillé (ssh -v user@Host) vous donne

debug1: Remote: No xauth program; cannot forward with spoofing.

mais xauth est en effet installé sur le serveur, alors c'est probablement parce que sshd cherche xauth exécutable au mauvais endroit (/ usr/X11R6/bin/xauth généralement). On peut résoudre ce problème en définissant

XAuthLocation /usr/bin/xauth

in / etc/sshd/sshd_config (ou quoi que votre serveur soit configuré avec).

2
Anton Samsonov

Je suis tombé sur cette question après une rencontre avec un sshd-xauth bug de près d'une décennie. Deux solutions sont signalées, la première contournant xauth, la seconde corrigeant le bogue.

Solution 1 - contourner xauth

  • local - la machine locale desservant un Xserver.
  • remote - la machine distante desservant l'application qui dirige les données vers le Xserver

Télécommande /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Télécommande ~/.Xauthority est vide ou n'existe pas

Sur local:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

Dans le test, local exécutait Ubuntu 18.05, distant exécutait Debian Jesse.

J'ai aussi publié cette solution comme réponse à une autre question.

Solution 2 - corrigez le bug sshd/xauth

Cette solution est proche de celle de @systempoet solution ci-dessus , bien que cela seul ne soit pas suffisant.

En plus de modifier /etc/ssh/sshd_config sur la télécommande:

AddressFamily inet

/etc/hosts sur la télécommande a également été modifié:

::1     localhost ip6-localhost ip6-loopback

Si l'un ou l'autre a été commenté, le message d'erreur

X11 forwarding request failed on channel 0

est apparu après le ssh -X ... appel. De plus, le /var/log/auth.log a montré l'erreur:

sshd[...]: error: Failed to allocate internet-domain X11 display socket

Testez pour produire le bug (avant correction):

Machine locale:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0
1
Craig Hicks

Configuration du transfert X11 par hôte

En plus de toutes les excellentes réponses déjà présentes, vous pouvez configurer ForwardX11 sur une base par hôte, donc si seulement server échoue comme ceci, vous pouvez ajouter une entrée à votre ~/.ssh/config fichier de la forme suivante:

Host server server.domain.dom
    ForwardX11 no

Vous pouvez même utiliser des entrées comme celle-ci comme allias pour des ensembles entiers de configurations

Host my.server
    HostName server.domain.dom
    User user
    Port 1234
    ForwardX11 no

Ceci est particulièrement utile si vous avez configuré noms de serveur de saisie semi-automatique pour SSH et SCP .

1
Mark Booth

Un point important à noter après avoir effectué les modifications de configuration est que vous devrez tuer sshd pour qu'il reprenne les modifications:

cat /var/run/sshd.pid | xargs kill -1

étant l'utilisateur root.

0
unixia