“Su” hatası “su” bağlantısı yanlış kimlik doğrulaması nedeniyle reddedildi ”

Kök olarak, bir komutu yürütmek için uzaktaki bir ana bilgisayara bağlanıyorum. Yalnızca "standarduser" uygun kimlik dosyasına ve doğru .ssh / config dosyasına sahiptir, bu yüzden önce kullanıcıyı değiştiriyorum:

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

Komut düzgün çalışıyor, ancak "-x" (X11-Forwarding'i devre dışı bırak) kullanmam ve X11Forwards'ı devre dışı bırakmama /etc/ssh/ssh_configrağmen, hala hata mesajını alıyorum:

X11 connection rejected because of wrong authentication.

"Standart kullanıcı" olarak giriş yaptığımda hata mesajını alamıyorum.

Bu komutu bir cron job dosyasına entegre etmek istediğim için oldukça can sıkıcı. Hata mesajının kökün .XAuth dosyasının yanlış kimlik doğrulamasına işaret ettiğini anlıyorum, ancak X11 üzerinden bağlanmaya bile çalışmıyorum.

"Ssh -x" neden X11 bağlantısını devre dışı bırakmıyor ve hata mesajını atmıyor?

GÜNCELLEME : Mesaj yalnızca bir ekrana giriş yaptığımda, yerel makinede yukarıda belirtilen komutu kullanırken (ekran olmadan), bir hata mesajı alamadığımı gösterir, bu yüzden cron ile de iyi olmalı .

Aynı komutu -vSSH’nin durum bilgisinden önce bile, FIRST’in hata mesajı ile başlattım ve şaşırdım:

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

Bu beni sorunun kendisine götürdü, sshhangisi hata mesajını atmıyor , DEĞİL su:

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

Neden bu hatayı yalnızca içeri alıyorum screen? Bu hata mesajını nasıl devre dışı bırakabilirim?

Kök bazı X11 yoksun gibi görünüyor sihirli çerez içinde .Xauthoritysenin hangi standardusersahiptir. İşte bunu düzeltmek için nasıl.

KISA SÜRÜM ( @bmaupin sayesinde )

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

Dikkat: geri tepmeleri kontrol edin! Tırnaklarla değiştirilemezler! sudoİkinci komutu daha ileriye taşımak için yüklü olması gerekir !

ORİJİNAL UZUN VERSİYON

Bir şeyleri düzeltmek için önce hangi ekran numarasının standarduserkullanılacağını belirleyin:

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

Bu durumda öyle 21.0. İkincisi, standarduserçerezlerin listesini görüntüle :

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

Ekranın çerezi 21.0, listede ikinci olur ve ile biter 104f.

Yapılması gereken son şey, bu belirli çerezi kökündekilere eklemek .Xauthority. Kök olarak giriş yapın ve aşağıdakileri yapın:

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

Bash komut dosyasında veya farklı bir kullanıcı olarak X11 connection rejected because of wrong authenticationçalıştırdığınızda hatayı nasıl azaltabileceğinizdir .suscreen

İlham için bu adama teşekkürler .

Daha kolay bir çözüm:

1.- ssh user@host

2.- $ sudo su

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

Bu kadar

Elbette $DISPLAYdeğişken ayarlanmalıdır.

İhtiyaçlarım biraz farklıydı bu yüzden biraz farklı bir çözüm buldum. Bir X11 uygulamasını başka bir kullanıcı (root olmayan) olarak çalıştırma yeteneğine ihtiyacım vardı. CentOS Koşu, ben ubuntu ile şanslı köpekler Xauth sihir var sahip güzel gksudo aracı yok.

Gerçekten sadece giriş yapmak, kullanıcı değiştirmek ve bir uygulama çalıştırmak için bazı özel komut dosyalarını çıkarmak istemedim; Bu bana biraz gereksiz görünüyor.

Adım bir:

$ XAUTHORITY'nin sudo oturumlarında taşınmasına izin ver.

Bu satırı / etc / sudoers içindeki env_keep ifadelerinin geri kalanının altına ekleyin:

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

İkinci adım:

Hedef kullanıcınıza .Xauthority'nizi okuma imkanı verin (evet biliyorum, GÜVENLİK diye bağırın! Sadece komutları root olarak çalıştırma yeteneği isteyenler için bu atlanabilir.

Hedef kullanıcı benimle aynı grubu paylaşıyor, bu yüzden sadece grup okuma izinlerini açıyorum:

$ chmod g+r user ~/.Xauthority

Adım üç:

CentOS, varsayılan olarak $ XAUTHORITY değerini doldurmaz. Profilinize bir satır ekleyin (benimki ~ / .bash_profile):

export XAUTHORITY=$HOME/.Xauthority

Bu kadar. Artık tweaking yok. PolicyKit'i çalıştırmak için .XML yazmanıza gerek yok. Her giriş için çalışan komut dosyası yok. Xauth'u kopyalamak için iki kez sudo yapmak zorunda değilsiniz. Bundan sonra basitçe:

$ sudo -u user xcalc

MobaXTerm ile harika çalışıyor.

Tamamen hedef kullanıcıya geçmelisiniz, yani ( ) -ile " " kullanmalısınız . Aksi takdirde, kök X ortamı ortamda sürüklenecektir.susu - standarduser ...

Sık sık bir kök ezilmiş ağ dosya paylaşımına dayandığım için yukarıdaki çözümlerin hiçbiri benim için işe yaramadı. (xubuntu 14.04). Sistemimde çalışan aşağıdaki betiği bir araya getirdim. Senin üzerinde çalışabilir. Sonra tekrar, olmayabilir, ama denemek için ücretsiz ...

Varsayım, -Y seçeneğini kullandım.

#!/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 $*

Benim durumumda bu hatayla karşılaştığımda şifreli bir kullanıcı dizinim vardı. Aradıktan sonra ecrypt-mount-privatehatadan kurtuldu ve X11'i yönlendirmeye devam etmeme izin verdi.

(Uyarınca ev klasörü şifreli olup olmadığını belirlemek için, bu deneyebilirsiniz Bu yanıt ): ls -A /home. Bir .ecryptfsklasör görürseniz , o zaman ana dizininiz şifrelenir, bu durumda cevabın başına koyduğum komutu yapmayı deneyebilirsiniz.