Vraag Wat doet "Waarschuwing: niet-vertrouwde X11 doorsturen setup is mislukt: xauth key data niet gegenereerd" betekent wanneer ssh'ing met -X?


Wanneer ik gebruik ssh -X op mijn Mac (met OS X 10.6.7) om verbinding te maken met mijn Ubuntu-vak (11.04), krijg ik de volgende waarschuwing:

Waarschuwing: niet-vertrouwde X11-doorsturen   setup mislukt: xauth key data niet   gegenereerd Waarschuwing: geen xauth-gegevens;   het gebruik van valse authenticatiegegevens voor X11   forwarding.

Kan ik iets doen om te zorgen dat deze waarschuwing verdwijnt? Zo nee, kan ik het veilig negeren?

X11 doorsturen lijkt goed te werken, hoewel ik dit bericht wel zie:

Xlib: extensie "RANDR" ontbreekt   "localhost: 10.0" weergeven.

Heeft dat te maken met de waarschuwing? (Ik vermoed het niet. Als dat niet het geval is, zal ik daar een nieuwe vraag over stellen.)


112
2018-05-25 22:41


oorsprong


IS het xauth-programma op de ubuntu-server geïnstalleerd? - slubman
sudo apt-get install xauth vertelt me ​​"xauth is al de nieuwste versie" - Daryl Spitzer
Wanneer is ingelogd op de ubuntu-server, wat is de uitvoer van 'welke xauth'? - slubman
Ik vind inderdaad dat je deze uitleg moet lezen: mail-archive.com/cygwin-xfree@cygwin.com/msg17927.html ... u kunt deze waarschuwing negeren - slubman
af en toe kan dit worden veroorzaakt door problemen met uw ~ / .Xauthority-bestand. Als u het verwijdert, wordt het opnieuw gemaakt wanneer u de volgende keer probeert in te loggen. - michael


antwoorden:


Enige reden waarom u de -Y vlag niet in plaats van de -X vlag wilt gebruiken?

Heel eenvoudig, het verschil tussen -X en -Y is dat -Y vertrouwde X11-doorsturen mogelijk maakt.


125
2018-02-01 22:02



Nee, ik was alleen niet op de hoogte van de vlag-Y toen ik de vraag schreef. Ik geloof dat dat een oplossing bleek te zijn. Verander je antwoord zodat het geen vraag is (en het zou leuk zijn als je het verschil tussen -Y en -C kort uitlegde) en ik accepteer het. - Daryl Spitzer
is er een geval wanneer u -Y in plaats van -X niet zou willen gebruiken? - Rooster
@ Rooster voor zeer oude systemen waar -Y niet wordt ondersteund zou ik zeggen - Petr
Tip voor probleemoplossing: voer "ssh -vv ..." uit en zoek naar de xauth-regel en eventuele foutmeldingen. Je kunt proberen de xauth-regel te gebruiken die hij direct laat zien. Voor mij had ik het nodig als "xauth list: 0" (vertrouwd) niet "xauth -f / tmp / ssh ... lijst: 0" (niet vertrouwd). Welke -Y fixed en "ForwardX11Trusted yes" in remote host / etc / ssh / ssh_config (of ~ / .ssh / config) ook opgelost. - Curtis Yallop
Deze oplossing werkte ook met Cygwin / X. - linux64kb


Als je hier in 2015 komt: zelfs als al het andere goed is ingesteld, kan dit ook gebeuren op Mac OS X 10.10 Yosemite, wanneer je ssh -X en een XQuartz-versie draaien <= 2.7.7. De oorzaak is dat X11-display sockets buiten het xauth-zoekpad worden geschreven: issue # 2068 in de XQuartz-tracker.

Bewerken: een vaste XQuartz is sindsdien vrijgegeven op de nieuwe startpagina, xquartz.org, en het installeren van de nieuwste versie vanaf daar (momenteel 2.7.9) zal dit probleem oplossen.


22
2018-05-13 15:09



Dank je! ik had geen idee dat de XQuartz I net gedownload van de top van de XQuartz-pagina is niet echt de nieuwste release. - craigds
Vermeldenswaardig dat brew install xquartz installeert momenteel de verouderde 2.7.7-versie. - Martin Cleaver
brew install Caskroom/cask/xquartz zou je de nieuwste XQuartz met HomeBrew moeten krijgen - Nick
Of korter brew cask install xquartz. - Franklin Yu


Als u hetzelfde bericht krijgt, zelfs wanneer u het gebruikt -Y, de xauth programma ontbreekt op de server. Op Debian-achtige systemen heeft u de xauth pakket. Op RedHat-achtige systemen heeft u de xorg-x11-xauth pakket.


14
2017-07-17 08:35





"Niet-vertrouwd" betekent in dit verband dat u de verbinding niet vertrouwt. SSH zal aanvullende veiligheidsmaatregelen nemen om X11-doorsturen veiliger te maken. "Vertrouwd" betekent dat u er volledig zeker van bent dat er geen on op de externe host toegang krijgt tot uw Xauth-gegevens en deze gebruikt om bijvoorbeeld uw toetsaanslagen te controleren.

Deze terminologie verwarde me al jaren. Ik dacht dat "vertrouwde" verbindingen veiliger waren. Maar eigenlijk is het een optie die u zou moeten gebruiken in situaties waarin de verbinding betrouwbaar is en u dingen wilt uitvoeren zonder dat extra beveiligingsmaatregelen u in de weg zitten. "Niet-vertrouwd" maakt het (enigszins) veiliger om met een niet-vertrouwde externe host om te gaan.

Een "niet-vertrouwde" verbinding probeert te beperken wat een zwarte hoed u kan doen door de X11-beveiligingsextensie in te schakelen en andere extensies uit te schakelen die u (hopelijk) niet nodig hebt. Dit is waarschijnlijk de reden waarom RandR is uitgeschakeld met -X. Moet je je X-display van de externe host kunnen draaien?

Het is ook belangrijk op te merken dat "niet-vertrouwde" X11-doorschakeling na een bepaalde tijd wordt uitgeschakeld om te voorkomen dat u deze per ongeluk inschakelt. Nieuwe pogingen om vensters te openen zullen daarna gewoon mislukken. Dat beet ik een paar keer voordat ik genoeg documenten las om te begrijpen wat er gebeurde.


11
2018-02-17 17:36





Ik heb geen installatie die dit gedrag kan vertonen, dus dit is een shot in het donker:

De waarschuwing kan worden onderdrukt als u instelt ForwardX11Trusted naar "no" voor hosts die deze waarschuwing geven. Je kunt dit in beide plaatsen ~/.ssh/config of /etc/ssh/ssh_configen u kunt de optie specifiek voor een bepaalde host maken door deze op te nemen Host <hostname> op de regel hierboven. de <hostname> component komt overeen met wat u typt op de opdrachtregel (niet de geresolveerde hostnaam), en het kan jokertekens bevatten.


8
2018-06-13 20:03



Men kan gebruiken ssh -Y om vertrouwde X11-forwarding te doen, maar hoe kun je die niet-vertrouwde repareren? - Pavel Šimerda
Ik kreeg dezelfde fout in Redhat en nu kan ik het oplossen door het configuratiebestand te bewerken /etc/ssh/ssh_config aan de kant van de klant. Dank je - Gangadhar Jannu


Als u installeert xauth werkt niet goed, een bijzonder vervelende zaak kan corrupt zijn .Xauthority het dossier. In dit specifieke geval konden sommige X-clients werken, maar niet anderen met een grotere neiging om te falen met nieuwere beeldschermen. Verwijderen en opnieuw maken van de .Xauthority bestand kan dat probleem oplossen.


5
2017-08-01 17:43





Sluit server-side problemen uit

Ten eerste moet u eventuele serverproblemen uitsluiten. Ben je in staat om ssh -X van een andere host met succes? Doet ssh -Y werk terwijl ssh -X niet? Ga in beide gevallen ervan uit dat ssh + X11 correct is ingesteld op uw server en ga verder met het volgende gedeelte.

Als je niet in staat bent om dat te controleren (je hebt alleen je ene laptop met X11, zeg), dan kan dat ssh van de server naar zichzelf met behulp van een valse sessie:

  1. export DISPLAY=:44 # (Bourne-schaal) of
    setenv DISPLAY :44 # (csh / tcsh)
  2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234  # Bogus-cookie alleen voor deze test
  3. ssh -X localhost env |grep DISPLAY

Verwacht resultaat: er moet een DISPLAY-variabele zijn ingesteld aan de externe kant van de SSH-naar-zelf-sessie. Als u geen resultaat krijgt, is uw server waarschijnlijk verkeerd geconfigureerd (bijvoorbeeld de X11-bibliotheken en / of de xauth commando zou kunnen ontbreken; of de sshd-configuratie kan worden ingesteld om X11-toegang te weigeren)

Op Mac: controleer of Xquartz up-to-date is

Vanaf Will Angley's antwoord

Onderzoeken ssh -vv -X uitgang

De foutmelding die u aanhaalt, is een symptoom dat vele oorzaken kan hebben. Probeer het opnieuw met ssh -X -vv remotehost, wat u extra aanwijzingen zou moeten geven over waarom de opstelling van de X11-tunnel mislukte.

Zie je het volgende bericht verschijnen?

debug1: Geen xauth-programma.
Als,

  1. Let op waar op uw clientsysteem de xauth opdracht bevindt zich:
    welke xauth
  2. Voeg het volgende toe helemaal aan het einde van je ~ / .ssh / config (en voeg een commentaar toe om jezelf eraan te herinneren om het daar in de toekomst te bewaren):
    Host *
        XAuthLocation / opt / X11 / bin / xauth
    
    Pas dit pad aan volgens de bevindingen van stap 1 - Credits voor Jan-Willem Arnold

5
2017-08-18 16:34





PAS OP (moe van het lezen van onvolledige antwoorden die tot een beveiligingsfout leiden)

1 / met ssh -Y betekent hier dat je fake xauth informatie hebt die slecht is!

2 / ssh-X zou moeten werken omdat XQuartz, eenmaal ingeschakeld, xauth gebruikt. Het enige probleem is dat ssh op zoek is naar xauth in / usr / X11R6 / bin en op macos met XQuartz is het in / opt / X11 / bin

Veilig oplossen:

1 / Schakel de eerste optie in Veiligheid tabblad met voorkeuren (Cmd-,) die geverifieerde verbindingen mogelijk maakt

2 / toevoegen

XAuthLocation /opt/X11/bin/xauth

in $ HOME / .ssh / config

3 / ssh -X you_server werkt in een veilige omgeving


4
2018-01-31 13:16





Ik had al de nieuwste XQuartz 2.7.11 geïnstalleerd, maar ik denk dat ik het besturingssysteem sindsdien ook een paar keer heb bijgewerkt. Ik heb XQuartz 2.7.11 opnieuw geïnstalleerd en nu werkt het prima.


-1
2018-04-01 12:52