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 -v
i 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, ssh
co 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?
źródło
-v
do opcji ssh, a następnie wklej wynik do pytania.Odpowiedzi:
Wygląda na to, że w twoim rootie brakuje magicznego pliku cookie X11 w pliku
.Xauthority
, który maszstandarduser
. Oto jak to naprawić.KRÓTKA WERSJA (dzięki @bmaupin )
Uwaga: sprawdź backticks! Nie można ich zastąpić cytatami! Musisz
sudo
zainstalować, aby przejść dalej drugie polecenie!ORYGINALNA DŁUGA WERSJA
Aby to naprawić, najpierw sprawdź, który numer wyświetlacza
standarduser
używa:W tym przypadku tak jest
21.0
. Po drugie, wyświetlstandarduser
listę plików cookie:Plik cookie na
21.0
wyświetlaczu jest drugim na liście i kończy się na104f
.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:W ten sposób możesz zminimalizować
X11 connection rejected because of wrong authentication
błąd, gdy uruchamiasz sięsu
jako inny użytkownik w skrypcie Bash lubscreen
.Dzięki temu facetowi za inspirację.
źródło
Łatwiejsze rozwiązanie:
1.-
ssh user@host
2.-
$ sudo su
3.-
# xauth merge /home/user/.Xauthority
To wszystko
Oczywiście
$DISPLAY
należy ustawić zmienną.źródło
$DISPLAY
zmienną? Wierzę, że ten niewielki dodatek rzuci dodatkowe głosy na twoją odpowiedź.xauth: file /root/.Xauthority does not exist
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:
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:
Krok trzeci:
CentOS domyślnie nie wypełnia wartości $ XAUTHORITY. Dodaj wiersz do swojego profilu (mój to ~ / .bash_profile):
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:
Działa świetnie z MobaXTerm.
źródło
Powinieneś całkowicie przełączyć się na docelowego użytkownika, tzn. Użyć „
-
” zsu
(su - standarduser ...
). Jeśli nie, rzeczy X roota zostaną przeciągnięte w środowisku.źródło
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.
źródło
cookie=$(xauth list|grep $h.*$port)
może pasować bardziej niż powinna, jeśli $ port jest częścią wartości pliku cookie. Bezpieczniejsze jest:cookie=$(xauth list) cookie=${c%% *}
lubcookie=$(xauth list |grep $h[^ ]*$port)
.W moim przypadku, gdy napotkałem ten błąd, miałem zaszyfrowany katalog użytkownika. Po wywołaniu
ecrypt-mount-private
pozbył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.ecryptfs
folder, oznacza to, że Twój katalog domowy jest prawdopodobnie zaszyfrowany. W takim przypadku możesz spróbować wykonać polecenie podane na początku odpowiedzi.źródło