it-swarm.it

Come inoltrare X su SSH per eseguire applicazioni grafiche in remoto?

Ho una macchina che esegue Ubuntu a cui SSH dalla mia macchina Fedora 14. Voglio inoltrare X dalla macchina Ubuntu a Fedora in modo da poter eseguire programmi grafici da remoto. Entrambe le macchine sono su una LAN.

So che il -X L'opzione abilita l'inoltro X11 in SSH, ma mi sembra di perdere alcuni passaggi.

Quali sono i passaggi necessari per inoltrare X da una macchina Ubuntu a Fedora su SSH?

390
Mr. Shickadance

L'inoltro X11 deve essere abilitato sia sul lato client che sul lato server.

Sul lato client , l'opzione -X (Maiuscola X) su ssh abilita l'inoltro X11 e puoi effettuare questo è il valore predefinito (per tutte le connessioni o per una specifica connessione) con ForwardX11 yes in ~/.ssh/config .

Sul lato server , X11Forwarding yes Deve essere specificato in /etc/ssh/sshd_config . Si noti che il valore predefinito non è inoltro (alcune distribuzioni lo attivano nel valore predefinito /etc/ssh/sshd_config) E che l'utente non può ignorare questa impostazione.

Il programma xauth deve essere installato sul lato server. Se ci sono programmi X11 lì, è molto probabile che xauth sarà lì. Nel caso improbabile, xauth è stato installato in una posizione non standard, può essere chiamato tramite ~/.ssh/rc (sul server!).

Si noti che non è necessario impostare alcuna variabile di ambiente sul server. DISPLAY e XAUTHORITY verranno automaticamente impostati sui valori corretti. Se si esegue ssh e DISPLAY non è impostato, significa che ssh non sta inoltrando la connessione X11.

Per confermare che ssh sta inoltrando X11, controlla una riga contenente Requesting X11 forwarding Nell'output ssh -v -X. Si noti che il server non risponderà in entrambi i casi, una precauzione di sicurezza per nascondere i dettagli ai potenziali aggressori.

Per far funzionare l'inoltro X11 su ssh, avrai bisogno di 3 cose sul posto.

  1. Il client deve essere configurato per l'inoltro di X11.
  2. Il server deve essere impostato per consentire l'inoltro X11.
  3. Il tuo server deve essere in grado di configurare l'autenticazione X11.

Se hai sia il n. 1 che il n. 2 in posizione ma manca il n. 3, finirai con una variabile di ambiente DISPLAY vuota.

Soup-to-nut, ecco come far funzionare l'inoltro X11.

  1. Sul tuo server, assicurati che/etc/ssh/sshd_config contenga:

    X11Forwarding yes
    X11DisplayOffset 10
    

    Potrebbe essere necessario SIGHUP sshd in modo che rilevi queste modifiche.

    cat /var/run/sshd.pid | xargs kill -1
    
  2. Sul tuo server, assicurati di aver installato xauth.

    [email protected]:~$ which xauth
    /usr/bin/xauth
    

    Se xauth non è installato, si verificherà il problema "variabile ambiente DISPLAY vuota".

  3. Sul tuo client, connettiti al tuo server. Assicurati di dire a ssh di consentire l'inoltro X11. preferisco

    [email protected]:~$ ssh -X [email protected]
    

ma ti potrebbe piacere

    [email protected]:~$ ssh -o ForwardX11=yes [email protected]

oppure puoi impostarlo nel tuo ~/.ssh/config.


Oggi mi imbattevo in questa variabile di ambiente DISPLAY vuota quando mi trovavo in un nuovo server che non gestisco. Rintracciare la parte xauth mancante è stato un po 'divertente. Ecco cosa ho fatto e cosa puoi fare anche tu.

Sulla mia workstation locale, di cui sono amministratore, ho verificato che/etc/ssh/sshd_config fosse impostato per inoltrare X11. Quando faccio di nuovo ssh -X su localhost, ottengo il mio DISPLAY impostato correttamente.

Costringere DISPLAY a disinserirsi non è stato troppo difficile. Avevo solo bisogno di vedere cosa stavano facendo sshd e ssh per impostarlo correttamente. Ecco l'output completo di tutto ciò che ho fatto lungo la strada.

    [email protected]:~$ mkdir ~/dummy-sshd
    [email protected]:~$ 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

Invece di usare Sudo per forzare la copia dei miei file ssh_Host_ {dsa, rsa} _key in posizione, ho usato ssh-keygen per crearne uno fittizio.

    [email protected]:~$ 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.

Risciacquare e ripetere con -t dsa:

    [email protected]:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_Host_dsa_key
    # I bet you can visually copy-paste the above output down here

Modifica ~/dummy-sshd/sshd_config per puntare ai nuovi file chiave ssh_Host corretti.

    # before
    [email protected]:~$ grep ssh_Host /home/blyman/dummy-sshd/sshd_config 
    HostKey /etc/ssh/ssh_Host_rsa_key
    HostKey /etc/ssh/ssh_Host_dsa_key

    # after
    [email protected]:~$ 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

Avvia sshd su una nuova porta in modalità non distaccata:

    [email protected]:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
    sshd re-exec requires execution with an absolute path

Whoops, meglio correggere quel percorso:

    [email protected]:~$ /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 un nuovo terminale e ssh in localhost sulla porta 50505:

    [email protected]:~$ 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

Guarda le ultime tre righe lì. Per fortuna ho impostato DISPLAY e ho avuto quelle due linee dall'aspetto piacevole di/usr/bin/xauth.

Da lì è stato un gioco da ragazzi spostare da parte mia/usr/bin/xauth a /usr/bin/xauth.old, disconnettersi da ssh e arrestare sshd, quindi riavviare sshd e ssh su localhost.

Quando/usr/bin/xauth non c'era più, non ho visto DISPLAY riflesso nel mio ambiente.


Non sta succedendo niente di geniale qui. Principalmente ho avuto la fortuna di scegliere un approccio sano per provare a riprodurlo sulla mia macchina locale.

98
Belden

Assicurati che:

  • Hai xauth installato sul server (vedi: xauth info/xauth list).
  • Sul server il tuo file /etc/ssh/sshd_config Ha queste righe:

    X11Forwarding yes
    X11DisplayOffset 10
    X11UseLocalhost no
    
  • Sul lato client il tuo file ~/.ssh/config Ha queste righe:

    Host *
      ForwardAgent yes
      ForwardX11 yes
    
  • Sul lato client, hai installato X server (ad esempio macOS: XQuartz; Windows: Xming).


Quindi per eseguire l'inoltro X11 tramite SSH, devi aggiungere -X Al comando ssh, ad es.

ssh -v -X [email protected]

quindi verifica che DISPLAY sia non vuoto di:

echo $DISPLAY

In tal caso, avendo quindi un parametro dettagliato per ssh (-v), Controlla eventuali avvisi, ad es.

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

Nel caso in cui hai X11 non attendibile come mostrato sopra, quindi prova il flag -Y invece ( se ti fidi dell'host):

ssh -v -Y [email protected]

Vedi: Cosa significa "Avviso: installazione dell'inoltro X11 non attendibile non riuscita: dati chiave xauth non generati" significa quando si invia con -X?


Nel caso tu abbia avviso: nessun dato xauth, potresti provare a generare un nuovo file .Xauthority, Ad es.

xauth generate :0 . trusted
xauth list

Vedi: Crea/ricostruisci un nuovo file .Xauthority


Se hai un avviso diverso da quello sopra, segui gli ulteriori indizi.


43
kenorb

La soluzione è aggiungere questa riga al tuo /etc/ssh/sshd_config:

X11UseLocalhost no

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

21
Ace

Lasciando Ubuntu bash su Windows 10 eseguire ssh -X per ottenere un ambiente GUI su un server remoto

  • Primo

Installa tutto quanto segue. Su Window, installa Xming. Su Ubuntu nel terminale, usa Sudo apt install installare ssh xauth xorg.

Sudo apt install ssh xauth xorg
  • Secondo

Vai alla cartella contiene ssh_config file, il mio è /etc/ssh.

  • Terzo

Modificare ssh_config come amministratore (USE Sudo). Dentro ssh_config, rimuovi l'hash # nelle righe ForwardAgent, ForwardX11, ForwardX11Trusted e imposta gli argomenti corrispondenti su yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes
  • Via

In ssh_config file, rimuovi l'hash frontale # prima Port 22 e Protocol 2 e aggiungi anche una nuova riga alla fine del file per indicare il percorso del file xauth, XauthLocation /usr/bin/xauth, ricorda di scrivere il tuo percorso del file xauth.

# /etc/ssh/ssh_config

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

Da quando abbiamo finito di modificare ssh_config file, salvalo quando lasciamo l'editor. Ora vai alla cartella ~ o $HOME, append export DISPLAY=localhost:0 alla tua .bashrc file e salvarlo.

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

Abbiamo quasi finito. Riavvia la tua shell bash, apri il tuo programma Xming e usa ssh -X [email protected]. Quindi goditi l'ambiente della GUI.

ssh -X [email protected]

Il problema si trova anche nel sottosistema Ubuntu su Windows e il collegamento è all'indirizzo

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

5
DestinyOne

Inserisci X11UseLocalhost no per /etc/ssh/sshd_config e riavvia il server SSH.

Se non viene visualizzato DISPLAY, verificare che xauth sia installato correttamente, quindi riprovare.

RHE/CEntos non ha questo problema, questa è una cosa di Ubuntu!

4
stephen cooke

Per me il problema era nell'opzione nodev mount per il filesystem/tmp. X11 ha bisogno di creare un file speciale lì dentro.

Quindi controlla quali sono le opzioni di mount per il filesystem/tmp se usi una partizione o un disco separati per quello.

1
yakovpol

Da aggiungere alle risposte eccellenti precedenti (impostazione ~/.ssh/config e verifica se la variabile di ambiente DISPLAY è impostata sul client, impostando /etc/ssh/sshd_config e l'installazione di xauth sul server), assicurati anche che xterm sia installato sul client, ad es.

Sudo apt-get install xterm
1
Aliz Rao

xauth può essere bloccato.

   -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.

Utilizzando

xauth -b

Sulla macchina che stavo cercando di ssh ha rotto il blocco su xauth. Disconnessione dalla sessione ssh dopo l'emissione xauth -b riaccedere infine mi ha permesso di eseguire correttamente echo $DISPLAY. Provalo sicuramente prima di ricreare .Xauthority

1

X11Forwarding deve essere impostato sul server SSH (nel tuo caso la casella Ubuntu) nel suo sshd_config e devi consentire a X11 di essere inoltrato per il client SSH (la tua casella Fedora) passando il -X opzione o modifica di ssh_config file per aggiungere il ForwardX11 predefinito.

1
Caleb