„Su” z błędem „Połączenie X11 odrzucone z powodu nieprawidłowego uwierzytelnienia”

Jako root łączę się ze zdalnym hostem, aby wykonać polecenie. Tylko „standardowy użytkownik” ma odpowiedni plik identyfikatora i poprawny plik .ssh / config, więc najpierw przełączam użytkownika:

su standarduser -c 'ssh -x remotehost ./remotecommand'

Polecenie działa dobrze, ale pomimo tego, że użyłem „-x” (wyłącz X11-Forwarding) i mam wyłączoną X11Forwards /etc/ssh/ssh_config, nadal pojawia się komunikat o błędzie:

X11 connection rejected because of wrong authentication.

Nie pojawia się komunikat o błędzie, gdy jestem zalogowany jako „użytkownik standardowy”.

Jest to dość denerwujące, ponieważ chciałbym zintegrować polecenie z plikiem zadania cron. Rozumiem, że komunikat o błędzie odnosi się do niewłaściwego uwierzytelnienia pliku .XAuth użytkownika root, ale nawet nie próbuję się połączyć przez X11.

Dlaczego „ssh -x” nie wyłącza połączenia X11 i nie wyświetla komunikatu o błędzie?

AKTUALIZACJA : Komunikat pokazuje się tylko wtedy, gdy jestem zalogowany na ekranie, podczas korzystania z polecenia wymienionego powyżej na samym komputerze lokalnym (bez ekranu), nie pojawia się komunikat o błędzie, więc to też powinno być w porządku z cronem .

Uruchomiłem również to samo polecenie -vi niespodziewanie dostałem komunikat o błędzie PIERWSZY, nawet przed informacją o statusie z SSH:

root@localhost:~# su standarduser -c 'ssh -x remotehost ./remotecommand'
X11 connection rejected because of wrong authentication.
OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013

Doprowadziło mnie to do samego problemu, to NIE to, sshco wyświetla komunikat o błędzie, to su:

root@localhost:~# su standarduser -c 'echo Hi'
X11 connection rejected because of wrong authentication.
Hi

Dlaczego ten błąd pojawia się tylko w środku screen? Jak mogę wyłączyć ten komunikat o błędzie?

Wygląda na to, że w twoim rootie brakuje magicznego pliku cookie X11 w pliku.Xauthority , który masz standarduser. Oto jak to naprawić.

KRÓTKA WERSJA (dzięki @bmaupin )

standarduser@localhost:~$ xauth list | grep unix`echo $DISPLAY | cut -c10-12` > /tmp/xauth
standarduser@localhost:~$ sudo su
root@localhost:~$ xauth add `cat /tmp/xauth`

Uwaga: sprawdź backticks! Nie można ich zastąpić cytatami! Musisz sudozainstalować, aby przejść dalej drugie polecenie!

ORYGINALNA DŁUGA WERSJA

Aby to naprawić, najpierw sprawdź, który numer wyświetlacza standarduserużywa:

standarduser@localhost:~$ echo $DISPLAY
localhost:21.0

W tym przypadku tak jest 21.0. Po drugie, wyświetl standarduserlistę plików cookie:

standarduser@localhost:~$ xauth list
localhost/unix:1  MIT-MAGIC-COOKIE-1  51a3801fd7776704575752f09015c61d
localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f
localhost/unix:22  MIT-MAGIC-COOKIE-1  22ba6595c270f20f6315c53e27958dfe
localhost/unix:20  MIT-MAGIC-COOKIE-1  267f68b51726a8a381cfc10c91783a13

Plik cookie na 21.0wyświetlaczu jest drugim na liście i kończy się na 104f.

Ostatnią rzeczą do zrobienia jest dodanie tego konkretnego pliku cookie do katalogu głównego .Xauthority. Zaloguj się jako root i wykonaj następujące czynności:

root@localhost:~$ xauth add localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f

W ten sposób możesz zminimalizować X11 connection rejected because of wrong authenticationbłąd, gdy uruchamiasz się sujako inny użytkownik w skrypcie Bash lub screen.

Dzięki temu facetowi za inspirację.

Łatwiejsze rozwiązanie:

1.- ssh user@host

2.- $ sudo su

3.- # xauth merge /home/user/.Xauthority

To wszystko

Oczywiście $DISPLAYnależy ustawić zmienną.

Moje potrzeby były nieco inne, więc wpadłem na nieco inne rozwiązanie. Potrzebowałem możliwości uruchomienia aplikacji X11 jako inny użytkownik (który nie jest rootem). Z systemem CentOS, więc nie mam narzędzia gksudo, które mają szczęśliwe psy z ubuntu, które wykonują magię Xauth.

Naprawdę nie chciałem wymieniać niestandardowych skryptów tylko po to, aby się zalogować, zmienić użytkownika i uruchomić aplikację; wydaje mi się to zbyteczne.

Krok pierwszy:

Pozwól $ XAUTHORITY być przenoszone podczas sesji sudo.

Dodaj ten wiersz pod resztą instrukcji env_keep w / etc / sudoers:

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

Krok drugi:

Pozwól docelowemu użytkownikowi na odczytanie twojej autoryzacji. Tak, wiem, krzycz BEZPIECZEŃSTWO! Dla tych, którzy chcą tylko uruchamiać polecenia jako root, można to pominąć.

Docelowy użytkownik dzieli tę samą grupę co ja, więc po prostu włączam uprawnienia do odczytu grupy:

$ chmod g+r user ~/.Xauthority

Krok trzeci:

CentOS domyślnie nie wypełnia wartości $ XAUTHORITY. Dodaj wiersz do swojego profilu (mój to ~ / .bash_profile):

export XAUTHORITY=$HOME/.Xauthority

Otóż ​​to. Nigdy więcej poprawiania. Brak pisania .XML, aby PolicyKit działał. Brak uruchomionych skryptów dla każdego logowania. Nie trzeba dwa razy sudo kopiować xauth. Odtąd możesz po prostu:

$ sudo -u user xcalc

Działa świetnie z MobaXTerm.

Powinieneś całkowicie przełączyć się na docelowego użytkownika, tzn. Użyć „ -” z su( su - standarduser ...). Jeśli nie, rzeczy X roota zostaną przeciągnięte w środowisku.

Ponieważ często rootuję w sieciowym unicestwieniu plików root, żadne z powyższych rozwiązań nie działało dla mnie. (Xubuntu 14.04). Przygotowałem następujący skrypt, który działa w moim systemie. To może działać na twoje. Z drugiej strony może nie, ale można spróbować ...

Założono, że ssh'd użyłem opcji -Y.

#!/bin/bash  
if [[ $DISPLAY =~ localhost(:[[:digit:]]+) ]] ;then
    port=${BASH_REMATCH[1]}
else
    echo "Unexpected DISPLAY $DISPLAY"
    exit 1
fi
h=$(hostname)
cookie=$(xauth list|grep $h.*$port)
sudo -i xauth -i add $cookie
sudo -i $*

W moim przypadku, gdy napotkałem ten błąd, miałem zaszyfrowany katalog użytkownika. Po wywołaniu ecrypt-mount-privatepozbyłem się błędu i pozwoliłem kontynuować przekazywanie X11.

Aby ustalić, czy katalog domowy jest zaszyfrowany, można spróbować to (jak na tą odpowiedź ) ls -A /home. Jeśli widzisz .ecryptfsfolder, oznacza to, że Twój katalog domowy jest prawdopodobnie zaszyfrowany. W takim przypadku możesz spróbować wykonać polecenie podane na początku odpowiedzi.