Proxy PuTTY X11: podjęto próbę nieprawidłowego protokołu autoryzacji

13

Próbuję połączyć się z serwerem Ubuntu, aby pracować na Qt-creator. Zanim wszystko pójdzie nie tak, skorzystałem z tego samouczka. Pobrałem kit i Xming i wszystko działało dobrze.

nagle, pracując nad twórcą Qt, nie mogłem zapisać żadnych zmian. Więc zamknąłem Qt-creator i ponownie uruchomiłem sesję szpachlowania. zapytał mnie o nazwę użytkownika i hasło (jak zwykle), a następnie po zalogowaniu się na serwerze i kiedy próbowałem uruchomić Qt-creator (jak zwykle) pojawia się następujący komunikat:

PuTTY X11 proxy: wrong authorisation protocol attempted
Can't open display: localhost:10.0

więc próbowałem rozwiązać problem przy użyciu dwóch metod znalezionych w Internecie:

pierwszy polega na dpyname protoname hexkeyużyciu:

xauth list 

który powinien zwrócić klucz, który następnie można dodać za pomocą:

xauth add

Jednak nie zadziałało, ponieważ xauth listpolecenie nic nie zwróciło.

drugim rozwiązaniem było przejście do:

./etc/ssh/sshd_config

otwórz plik: sshd_config i edytuj ForwardX11Trustedwiersz do odczytu yes, a jeśli taki wiersz nie istnieje, dodaj go.

ForwardX11Trusted yes

następnie zrestartuj serwer ssh i powinien on działać.

Jednak to też nie działało. Nie mogłem otworzyć pliku sshd_configza pomocą xdg-openlub gediti ponownie pojawia się ten sam komunikat.

więc dlaczego tak się dzieje i jakie jest na to rozwiązanie?

McLan
źródło
Dobra wiadomość jest taka: jestem teraz w stanie otworzyć plik: sshd_configza pomocą sudo nanopolecenia i dodać wiersz: ForwardX11Trusted yes.. złą wiadomością jest: po „kroku dodawania” problem nadal istnieje !!!
McLan,
Jakie jest pełne polecenie podczas używania xauth add?
Nate z Kalamazoo,
ForwardX11Trustedjest opcją dla klienta OpenSSH, nie dla serwera. Dodanie go może uniemożliwić sshduruchomienie, w zależności od wersji.
Gert van den Berg

Odpowiedzi:

7

Gdy zalogowałem się jako su, po kilku błędach typu „PuTTY X11 proxy: próba niewłaściwego protokołu autoryzacji” - zauważyłem, że to problem z uwierzytelnieniem. Potem przypomniałem sobie, aby skopiować plik .Xauthority z mojego własnego profilu / katalogu domowego do / root. Problem rozwiązany!

Navy Flyer
źródło
To wygląda na odpowiedź na inny problem (choć z tymi samymi objawami).
DavidPostill
To zadziałało dla Raspbian Jessie na RaspberryPi
Dexter
To również działało dla mnie na RPI. Z PuTTy na Win10 prosty leafpaddziałał dobrze, ale sudo leafpadzgłosił błąd w powyższym opisie. Kopiowanie .Xauthoritydziałało bezbłędnie. Wielkie dzięki!
Petr Újezdský
ok za problem z autoryzacją ... ale wciąż daje mi komunikat „Nie można otworzyć wyświetlacza:” ...? żadnych pomysłów
ZEE
2

Rozwiązany.

Rozwiązałem go za pomocą mieszaniny dwóch wyżej wymienionych.

1. Dodałem następujący wiersz do „/ etc / ssh / sshd_config”

ForwardX11Trusted yes

2. Zainstalowałem xauth za pomocą

sudo apt-get install xauth

xauth listbył dla mnie pusty przed ponownym uruchomieniem. Został jednak wypełniony po ponownym uruchomieniu. Zrobiłem to xauth listpo przetestowaniu go za pomocą szpachli.

Potem ponownie uruchomiłem ssh i zadziałało. Tak!

Uwaga: Tak naprawdę zrestartowałem Raspberry Pi

Dheeraj Bhaskar
źródło
3
ForwardX11Trusted nie jest prawidłową opcją dla sshd_config. Jest to parametr klienta, a nie parametr demona serwera
HeatfanJohn 21.01.16
Zrobiłem to już jakiś czas temu. Nie wiem teraz.
Dheeraj Bhaskar
2

Miałem podobny problem na serwerze w pracy, ponieważ w folderze domowym zabrakło miejsca na dysku. Po zalogowaniu nie mógł zapisać pliku Xauthority i ... nie mógł przekazać dalej.

Zwolnienie miejsca rozwiązało problem.

Wyobrażam sobie, że miałbyś podobny problem, gdyby uprawnienia do folderu domowego lub uprawnień .Xauthority były ustawione nieprawidłowo, więc nie miałeś dostępu do zapisu.

Ryan Armstrong
źródło
1

W moim przypadku zauważyłem, że mogę otworzyć Display z rootem, ale robiłem super-grid, a ten grid użytkownika był tym, który miał problem,

rozwiązaniem było zamknięcie tej sesji i otwarcie nowej sesji bezpośrednio za pomocą grida, i zadziałało, coś w robieniu su-grida zawiodło ...

użytkownik524500
źródło
0

Miałem podobny problem na serwerze. Powodem było to, że użytkownik uzyskał niewłaściwą liczbę wskazań (DISPLAY = localhost: 10.0). Gdy użytkownik łączy się z serwerem za pośrednictwem SSH (jako użytkownik o nazwie test1) otrzymuje DISPLAY = localhost: 11.0. Kiedy łączy się jako inny użytkownik, a następnie staje się użytkownikiem (test1), otrzymuje nieprawidłową liczbę wskazań (DISPLAY = localhost: 10.0). Kiedy ustawię numer rifght DISPLAY (DISPLAY = localhost: 11.0) to działa.

anton
źródło