it-swarm.com.de

Wie kann ich die Warnung verhindern? Keine xauth-Daten; Verwenden Sie gefälschte Authentifizierungsdaten für die X11-Weiterleitung?

Jedes Mal, wenn ich eine SSH-Verbindung von meinem Mac zu einem Linux (Debian) herstelle, wird folgende Warnung angezeigt:

No xauth data; using fake authentication data for X11 forwarding.

Dies gilt auch für Tools, die ssh verwenden, wie z. B. git oder Mercurial.

Ich möchte nur eine lokale Änderung an meinem System vornehmen, um zu verhindern, dass dies angezeigt wird.

Hinweis: Ich habe einen X11-Server (XQuartz 2.7.3 (xorg-server 1.12.4)) auf meinem Mac OS X (10.8.1) und er funktioniert ordnungsgemäß. Ich kann die Uhr erfolgreich lokal oder remote starten.

76
sorin

Habe die Ursache gefunden, mein ~/.ssh/config war unvollständig, du brauchst beides:

Host *
    ForwardAgent yes
    ForwardX11 yes

Mein Fehler war, dass ich nur die ForwardX11-Option aufgenommen habe.

24
sorin

Keine der veröffentlichten Lösungen hat bei mir funktioniert. Auf meinem Client (Desktop) -System wird macOS 10.12.5 (Sierra) ausgeführt. Ich habe -v Zu den Optionen für den Befehl ssh hinzugefügt und es hat mir gesagt,

debug1: No xauth program.

dies bedeutet, dass es keinen korrekten Pfad zum Programm xauth gibt. (In dieser Version von macOS ist der Pfad zu xauth nicht standardisiert.) Die Lösung bestand darin, diese Zeile zu /etc/ssh/ssh_config (Kann in einigen Setups /etc/ssh/config Sein) oder in ~/.ssh/config (Wenn Sie keine Administratorrechte haben):

XAuthLocation /opt/X11/bin/xauth

Jetzt ist die Warnmeldung weg.

80
nmgeek

Ubuntu unter Windows 10 ausführen lassen ssh -X, um eine GUI-Umgebung auf einem Remote-Server abzurufen

  • Zuerst

Installieren Sie alle folgenden. Installieren Sie im Fenster Xming. Verwenden Sie unter Ubuntu bash Sudo apt install installieren ssh xauth xorg.

Sudo apt install ssh xauth xorg
  • Zweite

Gehe in den Ordner mit ssh_config Datei, meine ist /etc/ssh.

  • Dritte

Bearbeiten ssh_config als Administrator (USE Sudo). Innerhalb ssh_config, entferne den Hash # in den Zeilen ForwardAgent, ForwardX11, ForwardX11Trusted und setzen Sie die entsprechenden Argumente auf yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
  • Viertens

Im ssh_config Datei, entfernen Sie den vorderen Hash # Vor Port 22 und Protocol 2, und fügen Sie am Ende der Datei eine neue Zeile hinzu, um den Speicherort der xauth-Datei anzugeben, XauthLocation /usr/bin/xauth, denk daran, deinen eigenen Pfad der xauth-Datei zu schreiben.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocation /usr/bin/xauth
  • Fünfte

Jetzt, da wir mit der Bearbeitung fertig sind ssh_config Datei, speichern Sie es, wenn wir den Editor verlassen. Gehen Sie nun zum Ordner ~ oder $HOME, anhängen export DISPLAY=localhost:0 zu deinem .bashrc Datei und speichern Sie es.

# ~/.bashrc
...
...
export DISPLAY=localhost:0
  • Letzte

Wir sind fast fertig. Starten Sie Ihre Bash-Shell neu, öffnen Sie Ihr Programm Xming und verwenden Sie ssh -X [email protected]. Dann genießen Sie die GUI-Umgebung.

ssh -X [email protected]

Das Problem liegt auch im Ubuntu-Subsystem unter Windows, und der Link befindet sich unter

https://Gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

Hinweis: Der verknüpfte Text enthält 2 Tippfehler (XauthLocaion anstelle von XauthLocation).

15
DestinyOne

Wie bereits erwähnt, scheint xauth unter OS X Yosemite auf eine alte Version zurückgegangen zu sein, die mit XQuartzs $DISPLAY Einstellung:

% xauth -V
1.0.9
% xauth generate $DISPLAY .
xauth: (argv):1:  bad display name "/private/tmp/com.Apple.launchd(...)/org.macosforge.xquartz:0" in "add" command
11
guest

Im Moment gibt es einen Fehler in MacOS. Ich bin auch darauf gestoßen. Die Lösung für mich bestand darin, meinem .bash_profile Folgendes hinzuzufügen

dispdir=`dirname $DISPLAY`
dispfile=`basename $DISPLAY`
dispnew="$dispdir/:0"
if [ -e $DISPLAY -a "$dispfile" = "org.x:0" ]; then
  mv $DISPLAY $dispnew
fi
export DISPLAY=$dispnew

Im Wesentlichen kann der Name für die mit Ihrem X-Root verknüpfte Dateipipe nicht korrekt behandelt werden und muss daher korrigiert werden. :-)

2
Red Tux

Einschließlich

XAuthLocation/opt/local/bin/xauth in ~/.ssh/config

in meinem macOS Sierra 10.12.6 hat für mich funktioniert. Eine kleine Änderung gegenüber Antwort 7).

ich habe gerade ~/.Xauthority (Zielcomputer) aus meinem Stammordner und ssh -X 192.168.123.1 wieder entfernt und ik hat funktioniert.

1
Marcel Kraan

In meinem Fall war es das Problem von .Xauthority, das das nicht weitergeleitete Magic-Cookie enthielt. Fabby on http://askubuntu.com/questions/571116/ empfiehlt am 14.11.2014, diese Zeile unter hinzuzufügen das Ende der .bashrc oder. Profil, um die Weiterleitung von xauth-Schlüsseln zwischen Benutzern beim Aufruf von su zu ermöglichen:

export $(dbus-launch)

Ich habe auch vorher hinzugefügt:

export XAUTHORITY=~/.Xauthority 

um sicherzustellen, dass die mit ssh -X aufgerufene Fernbedienung ̍ @ sie findet.

In meinem Fall ist .Xauthority ein Symlink zum ursprünglichen Benutzer /home//.Xauthority, von dem ich ...

  cd /home/<child_user>;ln -sf /home/<parent_user>/.Xauthority .xAuthority

mit korrekten Rechten:

  Sudo chown <parent_user> /home/<parent_user>/.profile
  chmod a+rw /home/<parent_user>/.profile 

so ist es zugänglich für und für. wird in der Lage sein, Apps auszulösen und das Ergebnis mit X-Fenstern auf dem lokalen Bildschirm im gesamten Proxy-Konto anzuzeigen!

TIPP: Überprüfen Sie die xauth-Liste ... wenn Magic Cookie aktiviert ist.

1
all-informatic

Ich würde dies als Kommentar hinzufügen, aber ich habe nicht genug Wiederholungen. Das Hinzufügen einer weiteren Zeile zu sorin 's Lösung hat bei mir funktioniert.

Bearbeiten Sie auf dem Client-Computer Ihre SSH-Konfigurationsdatei mit vim ~/.ssh/config

Fügen Sie dann die folgenden Zeilen hinzu:

Host *
    ForwardAgent yes
    ForwardX11 yes
    XAuthLocation /opt/X11/bin/xauth

Sie können Ihren xauth Speicherort überprüfen mit:

which xauth
1
ssanch

Dies passierte mir, nachdem ich meine Cygwin-Installation von einem PC auf einen anderen verschoben hatte. Das Problem schien die Änderung des Hostnamens zu sein: Das magische Cookie entsprach nicht mehr dem Hostnamen des neuen PCs.

Laufen

touch ~/.Xauthority
xauth add :0 . `mcookie`

auf der lokalen Cygwin-Installation wurde das Problem für mich behoben - xauth list listete jetzt ein magisches Cookie auf, das dem korrekten Hostnamen des neuen PCs zugeordnet ist, und die Warnung wurde nicht mehr angezeigt.

1
Irfy

Mein Ziel war es, eine leise SSH-basierte Befehlszeilenanmeldung für Linux-Hosts von meinem MacOS-Client aus zu erhalten. Z.B. Ich wollte keine Banner oder Nachrichten sehen. Richten Sie einfach eine zertifikatbasierte Anmeldung ein, damit ich einen Alias ​​eingeben und eine Eingabeaufforderung auf dem Host-Computer erhalten kann. Um dies zu erreichen, habe ich Folgendes getan:

  • Auf dem Debian 10 Linux Host habe ich _ [z. B. erstellt) ~/.hushlogin

  • Auf macOS Catalina ssh client erhielt ich jedoch die folgende Nachricht:

    Keine xauth-Daten; Verwenden gefälschter Authentifizierungsdaten für die X11-Weiterleitung.

Nachdem ich xauth binäre Position bestätigt hatte, fügte ichXAuthLocation /opt/X11/bin/xauth bis /etc/ssh/sshd_config auf dem macOS-Client, aber das hat nicht für mich funktioniert, als ich diesen Befehl verwendet habe:

ssh -Y [email protected]

Letztendlich @ ssanch's Antwort hat für mich gearbeitet. Aber bevor ich diese Lösung entdeckte, stieß ich auf eine Problemumgehung, die einigen Leuten helfen könnte:

ssh -Yy [email protected]

Kleinbuchstaben hinzufügen -y Das Flag in der ssh-Befehlszeile bewirkt, dass die Protokollausgabe anstelle von stderr an syslog gesendet wird, und dies ermöglicht auch die gewünschte leise Anmeldung.

0
clearlight