Mam komputer z systemem Ubuntu, na który przesyłam SSH z mojego komputera Fedora 14. Chcę przesłać X z komputera Ubuntu z powrotem do Fedory, aby móc zdalnie uruchamiać programy graficzne. Oba urządzenia są w sieci LAN.

Wiem, że ta -Xopcja umożliwia przekazywanie X11 w SSH, ale wydaje mi się, że brakuje mi niektórych kroków.

Jakie są wymagane kroki, aby przesłać X z komputera Ubuntu do Fedory przez SSH?

Przekazywanie X11 musi być włączone zarówno po stronie klienta, jak i serwera.

Na stronie klienta , -X(kapitał X) Opcja sshumożliwia przekazywanie X11, i można zrobić to domyślny (dla wszystkich połączeń lub dla konkretnego łączem) z ForwardX11 yesw ~/.ssh/config.

Na stronie serwera , X11Forwarding yesnależy określić w /etc/ssh/sshd_config. Zauważ, że domyślnie nie ma przekazywania (niektóre dystrybucje włączają go domyślnie /etc/ssh/sshd_config) i że użytkownik nie może zastąpić tego ustawienia.

xauthProgram musi być zainstalowany po stronie serwera. Jeśli są tam jakieś programy X11, jest bardzo prawdopodobne, że xauthtam będą. W mało prawdopodobnym przypadku xauthzostał zainstalowany w niestandardowej lokalizacji, można go wywołać przez ~/.ssh/rc(na serwerze!).

Pamiętaj, że nie musisz ustawiać żadnych zmiennych środowiskowych na serwerze. DISPLAYi XAUTHORITYzostaną automatycznie ustawione na odpowiednie wartości. Jeśli uruchomisz ssh i DISPLAYnie jest ustawiony, oznacza to, że ssh nie przekazuje połączenia X11.

Aby potwierdzić, że ssh przesyła X11, sprawdź wiersz zawierający Requesting X11 forwardingdane ssh -v -Xwyjściowe. Pamiętaj, że serwer nie odpowie w żaden sposób, co stanowi zabezpieczenie przed ukryciem szczegółów przed potencjalnymi atakującymi.

Aby przekazywanie X11 działało przez ssh, potrzebujesz 3 rzeczy na swoim miejscu.

1. Twój klient musi być skonfigurowany do przesyłania dalej X11.
2. Twój serwer musi być skonfigurowany, aby umożliwić przekazywanie X11.
3. Twój serwer musi mieć możliwość skonfigurowania uwierzytelnienia X11.

Jeśli masz zarówno numer 1, jak i numer 2, ale brakuje Ci numeru 3, otrzymasz pustą zmienną środowiskową DISPLAY.

Zupy do orzechów, oto jak sprawić, by przekazywanie X11 działało.

1. Na serwerze upewnij się, że plik / etc / ssh / sshd_config zawiera:

   X11Forwarding yes
   X11DisplayOffset 10
   

   Konieczne może być SIGHUP sshd, aby wyłapał te zmiany.

   cat /var/run/sshd.pid | xargs kill -1
   

2. Na swoim serwerze upewnij się, że masz zainstalowany xauth.

   belden@skretting:~$ which xauth
   /usr/bin/xauth
   

   Jeśli nie masz zainstalowanego xauth, napotkasz problem „pusta zmienna środowiskowa DISPLAY”.

3. Na kliencie połącz się z serwerem. Pamiętaj, aby powiedzieć ssh, aby zezwoliło na przekazywanie X11. wolę

   belden@skretting:~$ ssh -X blyman@the-server
   

ale może ci się spodobać

    belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server

lub możesz to ustawić w swoim ~ / .ssh / config.

Wpadłem dzisiaj na tę pustą zmienną środowiskową DISPLAY, kiedy ssh'owałem na nowym serwerze, którym nie administruję. Odnalezienie brakującej części xauth było trochę zabawne. Oto co zrobiłem i co możesz zrobić.

Na mojej lokalnej stacji roboczej, gdzie jestem administratorem, zweryfikowałem, że / etc / ssh / sshd_config został skonfigurowany do przekazywania X11. Kiedy ponownie ssh -X do localhost, mój DISPLAY jest poprawnie ustawiony.

Zmuszenie DISPLAY do rozbrojenia nie było zbyt trudne. Musiałem tylko obserwować, co robią sshd i ssh, aby ustawić go poprawnie. Oto pełna moc wszystkiego, co zrobiłem po drodze.

    blyman@skretting:~$ mkdir ~/dummy-sshd
    blyman@skretting:~$ cp -r /etc/ssh/* ~/dummy-sshd/
    cp: cannot open `/etc/ssh/ssh_host_dsa_key' for reading: Permission denied
    cp: cannot open `/etc/ssh/ssh_host_rsa_key' for reading: Permission denied

Zamiast używać sudo do wymuszania kopiowania moich plików ssh_host_ {dsa, rsa} _key na swoje miejsce, użyłem ssh-keygen, aby stworzyć dla siebie atrapy.

    blyman@skretting:~$ ssh-keygen -t rsa -f ~/dummy-sshd/ssh_host_rsa_key
    Generating public/private rsa key pair.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.
    Your public key has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.pub.

Przepłucz i powtórz za pomocą -t dsa:

    blyman@skretting:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_host_dsa_key
    # I bet you can visually copy-paste the above output down here

Zmodyfikuj ~ / dummy-sshd / sshd_config, aby wskazać poprawne nowe pliki kluczy ssh_host.

    # before
    blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config 
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_dsa_key

    # after
    blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config 
    HostKey /home/blyman/dummy-sshd/ssh_host_rsa_key
    HostKey /home/blyman/dummy-sshd/ssh_host_dsa_key

Uruchom sshd na nowym porcie w trybie bez odłączania:

    blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    sshd re-exec requires execution with an absolute path

Ups, lepiej popraw tę ścieżkę:

    blyman@skretting:~$ /usr/sbin/sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    debug1: sshd version OpenSSH_5.5p1 Debian-4ubuntu6
    debug1: read PEM private key done: type RSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
    debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
    debug1: private host key: #0 type 1 RSA
    debug1: read PEM private key done: type DSA
    debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
    debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
    debug1: private host key: #1 type 2 DSA
    debug1: setgroups() failed: Operation not permitted
    debug1: rexec_argv[0]='/usr/sbin/sshd'
    debug1: rexec_argv[1]='-p'
    debug1: rexec_argv[2]='50505'
    debug1: rexec_argv[3]='-f'
    debug1: rexec_argv[4]='/home/blyman/dummy-sshd/sshd_config'
    debug1: rexec_argv[5]='-d'
    Set /proc/self/oom_adj from 0 to -17
    debug1: Bind to port 50505 on 0.0.0.0.
    Server listening on 0.0.0.0 port 50505.
    debug1: Bind to port 50505 on ::.
    Server listening on :: port 50505.

Pop nowy terminal i ssh do localhost na porcie 50505:

    blyman@skretting:~$ ssh -p 50505 localhost
    The authenticity of host '[localhost]:50505 ([::1]:50505)' can't be established.
    RSA key fingerprint is 81:36:a5:ff:a3:5a:45:a6:90:d3:cc:54:6b:52:d0:61.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '[localhost]:50505' (RSA) to the list of known hosts.
    Linux skretting 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 UTC 2012 x86_64 GNU/Linux
    Ubuntu 10.10

    Welcome to Ubuntu!
     * Documentation:  https://help.ubuntu.com/

    1 package can be updated.
    0 updates are security updates.

    Last login: Thu Aug 16 15:41:58 2012 from 10.0.65.153
    Environment:
      LANG=en_US.UTF-8
      USER=blyman
      LOGNAME=blyman
      HOME=/home/blyman
      PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
      MAIL=/var/mail/blyman
      SHELL=/bin/bash
      SSH_CLIENT=::1 43599 50505
      SSH_CONNECTION=::1 43599 ::1 50505
      SSH_TTY=/dev/pts/16
      TERM=xterm
      DISPLAY=localhost:10.0
    Running /usr/bin/xauth remove unix:10.0
    /usr/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 79aa9275ced418dd445d9798b115d393

Spójrz na ostatnie trzy wiersze tam. Na szczęście miałem ustawiony DISPLAY i miałem te dwie ładnie wyglądające linie z / usr / bin / xauth.

Stąd dziecinnie proste było przeniesienie mojego / usr / bin / xauth do /usr/bin/xauth.old, rozłączenie się z ssh i zatrzymanie sshd, a następnie uruchomienie sshd i ssh z powrotem na localhost.

Kiedy nie było / usr / bin / xauth, nie widziałem DISPLAY odzwierciedlonego w moim środowisku.

Nie dzieje się tu nic wspaniałego. Głównie miałem szczęście, wybierając rozsądne podejście, aby spróbować odtworzyć to na mojej lokalnej maszynie.

Upewnić się, że:

• Masz xauthzainstalowany na serwerze (patrz: xauth info/ xauth list).

• Na serwerze twój /etc/ssh/sshd_configplik ma następujące linie:

  X11Forwarding yes
  X11DisplayOffset 10
  X11UseLocalhost no
  

• Po stronie klienta twój ~/.ssh/configplik ma następujące linie:

  Host *
    ForwardAgent yes
    ForwardX11 yes
  

• Po stronie klienta masz zainstalowany serwer X (np. MacOS: XQuartz; Windows: Xming).

Następnie, aby wykonać przekazywanie X11 za pomocą SSH, musisz dodać -Xdossh polecenia, np

ssh -v -X user@host

następnie sprawdź, czy twój nieDISPLAY jest pusty przez:

echo $DISPLAY

Jeśli tak, to mając pełny parametr dla ssh ( -v), sprawdź wszelkie ostrzeżenia, np

debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated

Jeśli masz niezaufany X11, jak pokazano powyżej, spróbuj-Y zamiast tego oznaczyć flagę (jeśli ufasz hostowi):

ssh -v -Y user@host

^{Zobacz: Co oznacza „Ostrzeżenie: niezaufana konfiguracja przekazywania X11 nie powiodła się: nie wygenerowano danych klucza xauth”, gdy ssh'ing z -X?}

W przypadku ostrzeżenia: Brak danych xauth , możesz spróbować wygenerować nowy .Xauthorityplik, np

xauth generate :0 . trusted
xauth list

Zobacz: Utwórz / odbuduj nowy plik .Xauthority

Jeśli masz inne ostrzeżenia niż wyżej, postępuj zgodnie z dalszymi wskazówkami.

Rozwiązaniem jest dodanie tej linii do /etc/ssh/sshd_config:

X11UseLocalhost no

https://joshua.hoblitt.com/rtfm/2013/04/how_to_fix_x11_forwarding_request_failed_on_channel_0/

Zezwolenie Ubuntu na uruchomienie systemu Windows 10 w ssh -X celu uzyskania środowiska GUI na zdalnym serwerze

• Pierwszy

Zainstaluj wszystkie następujące elementy. W systemie Windows zainstaluj Xming. W systemie Ubuntu bash użyj, sudo apt installaby zainstalować ssh xauth xorg.

sudo apt install ssh xauth xorg

• druga

Idź do folderu zawierającego ssh_configplik, mój jest /etc/ssh.

• Trzeci

Edytuj ssh_configjako administrator (USE sudo). Wewnątrz ssh_config, usuń mieszania #w linii ForwardAgent, ForwardX11, ForwardX11Trustedi ustaw odpowiednie argumenty yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes

• Naprzód

W ssh_configpliku usuń przedni skrót #przed Port 22i Protocol 2, a także dodaj nowy wiersz na końcu pliku, aby podać lokalizację pliku xauth XauthLocaion /usr/bin/xauth, pamiętaj, aby napisać własną ścieżkę do pliku xauth.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocaion /usr/bin/xauth

• Piąty

Teraz, gdy skończyliśmy edytować ssh_configplik, zapisz go, gdy wyjdziemy z edytora. Teraz przejdź do folderu ~lub $HOMEdołącz export DISPLAY=localhost:0do .bashrcpliku i zapisz go.

# ~/.bashrc
...
...
export DISPLAY=localhost:0

• Ostatni, ubiegły, zeszły

Prawie skończyliśmy. Zrestartuj powłokę bash, otwórz Xmingprogram i użyj ssh -X yourusername@yourhost. Następnie ciesz się środowiskiem GUI.

ssh -X yourusername@yourhost

Problem dotyczy również podsystemu Ubuntu w systemie Windows, a łącze znajduje się pod adresem

https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

Dodaj X11UseLocalhost nodo /etc/ssh/sshd_configi zrestartować serwer SSH.

Jeśli nie wyświetla się WYŚWIETLACZ, sprawdź, czy xauth jest poprawnie zainstalowany, a następnie spróbuj ponownie.

RHE / CEntos nie ma tego problemu, to kwestia Ubuntu!

Dla mnie problemem była opcja montowania nodev dla systemu plików / tmp. X11 potrzebuje tam specjalnego pliku.

Sprawdź więc, jakie są opcje montowania systemu plików / tmp, jeśli używasz do tego osobnej partycji lub dysku.

Aby dodać do poprzednich doskonałych odpowiedzi (konfigurowanie ~/.ssh/configi sprawdzanie, czy DISPLAYzmienna środowiskowa jest ustawiona na kliencie, konfigurowanie /etc/ssh/sshd_configi instalacja xauthna serwerze), upewnij się również, że xtermjest zainstalowana na kliencie, np.

sudo apt-get install xterm

xauth może zostać zamknięty.

   -b      This  option  indicates  that  xauth  should  attempt to break any authority file locks before proceeding.  Use this
           option only to clean up stale locks.

Za pomocą

xauth -b

Na maszynie, którą próbowałem sshwłamać, włamał się zamek xauth. Wylogowanie z sshsesji po wydaniu, xauth -ba następnie ponowne zalogowanie w końcu pozwoliło mi pomyślnie echo $DISPLAY. Zdecydowanie wypróbuj to przed ponownym utworzeniem.Xauthority

X11Forwardingmusi być ustawiony na serwerze SSH (w twoim przypadku na polu Ubuntu) sshd_configi musisz zezwolić na przekazywanie X11 dla klienta SSH (twoje okno Fedory), przekazując -Xopcję lub edytując ssh_configplik, aby dodać wartość ForwardX11domyślną.