Jak mogę zapobiec ostrzeżeniu Brak danych xauth; używasz fałszywych danych uwierzytelniających do przekazywania X11?

66

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.

sorin
źródło
1
Jakiego polecenia używasz do ssh?
DerfK
@DerfK tylko, ssh hostnameale w moim ~/.ssh/configdodałem ForwardX11 yesjakiś czas temu. Nadal jest to coś, co chcę tam mieć.
sorin,
Używając Ubuntu 16.04 LTS (sierpień 2017) poddaję się. Najważniejsze jest to, że nawet jeśli daje błąd, działa. Używam ssh -Y hostnamez Linuksa i ssh -x hostnamepodczas korzystania z OpenSSH w systemie Windows.
SDsolar

Odpowiedzi:

66

Ż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ął.

nmgeek
źródło
10
O MÓJ BOŻE. Lata Próbowałem znaleźć rozwiązanie i to zadziałało. Lata mówię! Zauważ, że zrobiłem to, dodając tę ​​linię pod Host *wpisem w moim ~/.ssh/configpliku zamiast edycji /etc/ssh/ssh_config. Jedyną dokumentacją, którą znalazłem, była man sshd_config.
Demitri,
To również działało dla mnie. Rozumiem, że w tej chwili XQuartz nie jest dobrze utrzymywany z powodu braku funduszy. Myślę więc, że takie problemy z przenoszeniem są w rzeczywistości mniej, niż się spodziewałem.
AlanObject
W High Sierra; to też zadziałało dla mnie.
mklein9,
1
Pamiętaj, że możesz napotkać ten problem, nawet jeśli twoja powłoka może znaleźć xauth w ŚCIEŻCE! Wydaje mi się, że klient ssh dezynfekuje ŚCIEŻKĘ ze względów bezpieczeństwa?
MarcH
1
To rozwiązanie nie działało dla mnie. Używam Cygwin na Win7. Dodanie „XAuthLocation / usr / bin / xauth” albo pod wpisem „Host *”, albo przed tym wierszem w ~ / .ssh / config, nie miało znaczenia.
David M. Karr
22

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.

sorin
źródło
12
Nie jestem pewien, dlaczego jest to potrzebne / istotne. ForwardAgentsłuży do przekazywania kluczy buforowanych ssh-agentprzez wiele zagnieżdżonych połączeń SSH. Nie powinno to mieć żadnego związku z X11. I fwiw, według niektórych, nie jest dobrym pomysłem ze względów bezpieczeństwa: heipei.github.io/2015/02/26/…
underscore_d
2
To nie brzmi dobrze, co pomaga w rzeczywistości wyłączyć przekazywanie X11 lub naprawić konfigurację xauth, aby ją skonfigurować. Nie jest związany z agentami ssh.
eckes
To rozwiązanie nie działało dla mnie.
David M. Karr
Czy to ~/.ssh/configna kliencie macOS lub serwerze Linux? Nie mam tych plików na żadnym z nich. Mam podobny/etc/ssh/sshd_config
Max Coplan
12

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)

DestinyOne
źródło
Pytanie nie dotyczy Windowsa.
kasperd
Na MacOS jest prawie taki sam, różnice są zamiast Xming, powinniśmy dostać XQuartz, a ssh_configplik znajduje się w innej lokalizacji, moja jest /private/etc/ssh.
DestinyOne
I ostatnia linia ssh_configbędzie:XAuthLocation /opt/X11/bin/xauth
DestinyOne
2
Potrzebna edycja : XauthLocaion-> XauthLocation(ta edycja jest za mała, aby ją wykonać).
echristopherson
1
Poza instalacją xming, ssh, xauth, i xorg(krok 1), jedyną rzeczą, potrzebne było dla mnieexport DISPLAY=localhost:0
tytułowej
11

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
Gość
źródło
1
Testowałem te same linie w systemie OS X 10.11 i nie otrzymuję żadnego błędu. Wciąż ta sama wersja XQuartz.
sorin
1
@guest Twoje xauth generate $DISPLAY .polecenie działało na moim Mac OS X High Sierra (10.13) i rozwiązało moje No xauth data; using fake authentication data for X11 forwarding.pb.
SebMa,
2

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. :-)

Red Tux
źródło
Wątpię, czy to rozwiązałoby błąd w aplikacjach GUI OS X, takich jak SourceTree.
sorin
Potwierdzenie, że działa w Sierra do uruchamiania emacsa za pomocą X - ponieważ Mac jest serwerem. powinno to działać ogólnie w przypadkach, gdy klient znajduje się na zdalnej maszynie
Mark Mullin,
2

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).

Kepler Oliveira Filho
źródło
1

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.

Marcel Kraan
źródło
Mogę potwierdzić, że jest to odpowiedź w systemie Mac OS Sierra 10.12.4. Usunięcie ~ / .Xauthority na serwerze SSH załatwia sprawę : ~$ mv ~/.Xauthority ~/.Xauthority.bak Nowy magiczny plik cookie został automatycznie ponownie umieszczony w ~ / .Xauthority po ponownym zalogowaniu. Skrypty Bash wcale nie są wymagane.
Kenneth Pegasus
1

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.

całkowicie informatyczne
źródło
0

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
ssanch
źródło
Nie jestem pewien, czy to naprawdę działałoby, ponieważ lokalizacja xauth byłaby inna na każdym komputerze zdalnym. Twój wygląda jak MacOS, ale Linux ma go w innej lokalizacji. Przeważnie zacząłem całkowicie wyłączać ForwardX11, ponieważ prawie nigdy go nie używam.
sorin