Za każdym razem, gdy inicjuję połączenie ssh z komputera Mac do systemu Linux (Debian), pojawia się następujące ostrzeżenie:

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

Dzieje się tak również w przypadku narzędzi korzystających z ssh, takich jak git lub mercurial.

Chcę tylko wprowadzić lokalną zmianę w moim systemie, aby temu zapobiec.

Uwaga: Mam serwer X11 (XQuartz 2.7.3 (xorg-server 1.12.4)) na moim Mac OS X (10.8.1) i działa poprawnie, mogę z powodzeniem uruchomić zegar lokalnie lub zdalnie.

Żadne z opublikowanych rozwiązań nie działało dla mnie. System mojego klienta (stacjonarny) działa pod kontrolą systemu macOS 10.12.5 (Sierra). Dodałem -vdo opcji sshpolecenia i powiedział mi:

debug1: No xauth program.

co oznacza, że ​​nie ma poprawnej ścieżki do xauthprogramu. (W tej wersji systemu macOS ścieżka do xauthjest niestandardowa.) Rozwiązaniem było dodanie tej linii do /etc/ssh/ssh_config(może być /etc/ssh/configw niektórych konfiguracjach) lub w ~/.ssh/config(jeśli nie masz uprawnień administratora):

XAuthLocation /opt/X11/bin/xauth

Teraz komunikat ostrzegawczy zniknął.

Znalazłem przyczynę, moja ~/.ssh/configbyła niekompletna, potrzebujesz obu:

Host *
    ForwardAgent yes
    ForwardX11 yes

Mój błąd polegał na tym, że zawarłem tylko opcję ForwardX11.

Zezwolenie Ubuntu na uruchomienie systemu Windows 10 w ssh -X celu uzyskania środowiska GUI na zdalnym serwerze

• Pierwszy

Zainstaluj wszystkie następujące elementy. W systemie Windows zainstaluj Xming. W systemie Ubuntu bash użyj, sudo apt installaby zainstalować ssh xauth xorg.

sudo apt install ssh xauth xorg

• druga

Idź do folderu zawierającego ssh_configplik, mój jest /etc/ssh.

• Trzeci

Edytuj ssh_configjako administrator (USE sudo). Wewnątrz ssh_config, usuń mieszania #w linii ForwardAgent, ForwardX11, ForwardX11Trustedi ustaw odpowiednie argumenty yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes

• Naprzód

W ssh_configpliku usuń przedni skrót #przed Port 22i Protocol 2, a także dodaj nowy wiersz na końcu pliku, aby podać lokalizację pliku xauth XauthLocation /usr/bin/xauth, pamiętaj, że napisz własną ścieżkę do pliku xauth.

# /etc/ssh/ssh_config

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

• Piąty

Teraz, gdy skończyliśmy edytować ssh_configplik, zapisz go, gdy wyjdziemy z edytora. Teraz przejdź do folderu ~lub $HOMEdołącz export DISPLAY=localhost:0do .bashrcpliku i zapisz go.

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

• Ostatni, ubiegły, zeszły

Prawie skończyliśmy. Zrestartuj powłokę bash, otwórz Xmingprogram i użyj ssh -X yourusername@yourhost. Następnie ciesz się środowiskiem GUI.

ssh -X yourusername@yourhost

Problem dotyczy również podsystemu Ubuntu w systemie Windows, a łącze znajduje się pod adresem

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

Uwaga: połączony tekst zawiera 2 literówki ( XauthLocaionzamiast XauthLocation)

Jak wspomniano, wydaje się, że xauthw OS X Yosemite zresetował się do starej wersji, która nie działa z $DISPLAYustawieniem XQuartz :

% 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

Obecnie w systemie MacOS występuje błąd. Też natknąłem się na to. Poprawka polegała na dodaniu do mojego pliku .bash_profile następujących elementów

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

Zasadniczo nazwa potoku pliku powiązanego z twoim katalogiem głównym X nie może być obsługiwana poprawnie, a zatem wymaga korekty. :-)

Włącznie z

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

w moim systemie macOS działała dla mnie Sierra 10.12.6. Mała zmiana w stosunku do odpowiedzi 7).

właśnie usunąłem ~ / .Xauthority (komputer docelowy) z mojego folderu głównego i ssh -X 192.168.123.1 ponownie i ik zadziałało.

W moim przypadku był to problem .Xauthority zawierający Magic cookie nie został przesłany dalej, Fabby na http://askubuntu.com/questions/571116/ zaleca 14.11.2014, aby dodać ten wiersz na końcu .bashrc lub . profil umożliwiający przekazywanie kluczy xauth między użytkownikami podczas wywoływania su:

export $(dbus-launch)

Dodałem też wcześniej:

export XAUTHORITY=~/.Xauthority 

aby upewnić się, że zdalne wywołane przez ssh -X ̍ @ go znajdzie.

W moim przypadku .Xauthority jest dowiązaniem symbolicznym do oryginalnego użytkownika /home//.Xauthority, z którego pochodzę od ...

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

z prawidłowymi prawami:

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

więc jest dostępny dla i dla. będzie mógł uruchamiać aplikacje i wyświetlać wynik X-okien na swoim lokalnym ekranie na całym koncie proxy!

WSKAZÓWKA: Sprawdź listę xauth ... jeśli odzwierciedla magiczne ciasteczko.

Dodałbym to jako komentarz, ale nie mam wystarczającej liczby przedstawicieli. Dodanie jeszcze jednej linii do rozwiązania sorina działało dla mnie.

Otwórz plik konfiguracyjny ssh za pomocą vim ~/.ssh/config Następnie dodaj do niego następujące wiersze:

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

Możesz dwukrotnie sprawdzić swoją xauthlokalizację za pomocą:

which xauth