☰

„Warnung: Einrichtung einer nicht vertrauenswürdigen X11-Weiterleitung fehlgeschlagen“ bei verschachteltem SSH

tag-icon • tag-icon debian login openssh
„Warnung: Einrichtung einer nicht vertrauenswürdigen X11-Weiterleitung fehlgeschlagen“ bei verschachteltem SSH

Ich habe ein Gateway, auf das ich mich per SSH aus dem bösen World Wide Web einloggen kann. Kein Problem, ich bekomme:

remote ~$ ssh -X ingo@gateway
Debian GNU/Linux 10 (buster)
0:ingo@gateway ~$

Jetzt verwalte ich meine anderen Hosts, zum Beispiel den Dateiserver:

0:ingo@gateway ~$ ssh -X ingo@fileserver
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Debian GNU/Linux 10 (buster)
0:ingo@fileserver~$

Ich bekomme diese Warnung.

Wenn ich aber von meinem Management-Host im lokalen Netzwerk direkt auf den Fileserver ssh, funktioniert es ohne Warnung. Ich habe das mit anderen Logins überprüft. Ich bekomme die Warnung nur, wenn ich von einem SSH ssh ssh.

Warum bekomme ich
Warnung: Einrichtung einer nicht vertrauenswürdigen X11-Weiterleitung fehlgeschlagen: XAuth-Schlüsseldaten nicht generiert
nur bei verschachtelten SSH-Anmeldungen?

Wie kann ich diese Warnung vermeiden und die sicherere nicht vertrauenswürdige X11-Weiterleitung erfolgreich nutzen?

Und nein, ich möchte -Yfür die vertrauenswürdige X11-Weiterleitung nicht die weniger sichere Option auf SSH anstelle der verwendeten -XOption verwenden.

Antwort1

Wenn Ihre einzige Verbindung zu einem X11-Servernicht vertrauenswürdig, können Sie es nicht weiterleiten.

Die nicht vertrauenswürdige X11-Weiterleitung funktioniert, indem der SSH-Client eine Verbindung zum lokalen Display herstellt und den xauth generate $DISPLAY . untrustedBefehl verwendet, um einenicht vertrauenswürdigSchlüssel / Cookie.

Dafür xauthmuss die SECURITYErweiterung jedoch im Befehlsfenster angezeigt werden. Diese wird wie die meisten Erweiterungen ausgeblendet und/oder deaktiviert, wenn ein Client beispielsweise xauthmit einem nicht vertrauenswürdigen Cookie authentifiziert wurde.

Sie können dies ganz einfach überprüfen mit:

$ touch /tmp/junk1 /tmp/junk2
$ chmod 600 /tmp/junk*
$ xauth -f /tmp/junk1 generate :0 . untrusted
$ XAUTHORITY=/tmp/junk1 oclock
   # get a square oclock because the Shape extension is disabled
$ XAUTHORITY=/tmp/junk1 xdpyinfo | grep -A2 extensions
number of extensions:    2
    BIG-REQUESTS
    XC-MISC
   # vs 28 or so on a trusted display
$ XAUTHORITY=/tmp/junk1 xauth -f /tmp/junk2 generate :0 . untrusted
xauth: (argv):1:  couldn't query Security extension on display ":0"

Der letzte Schritt führt zu der Warnung, die Sie in SSH erhalten.

Daher sollte zumindest der ersten X11-Weiterleitung vertraut werden, sonst würde es nicht funktionieren.

Alternativ sollten Sie über den Zwischenhost „springen“, der eine einzelne X11-Weiterleitung durchführt:

ssh -X -o ForwardX11Trusted=no -J ingo@gateway ingo@fileserver

Beachten Sie, dass explizit ForwardX11Trusted=no, da unter Debian die Optionen -Xund -Ygleichwertig sind und Sie eineVertrauenswürdigeX11-Weiterleitung standardmäßig, egal welche Sie verwenden.

verwandte Informationen