come ssh -Y e poi su - <un altro utente> e ancora inoltrare le applicazioni X al computer locale


13

È abbastanza facile 'recuperare' (cioè disegnare localmente) un'applicazione linux in esecuzione in remoto: se vado ssh -Ysul computer remoto ed eseguo un'applicazione, quell'applicazione apparirà sicuramente abbastanza sul mio desktop locale.

Se, tuttavia, mentre mi trovo nella macchina remota, io sua un altro utente, non posso inoltrare l'applicazione X alla mia macchina locale. Dice wrong authentication.

Non sono sicuro di come affrontare questo caso. Il echo $DISPLAYè ancora corretta (impostato dal primo ssh -Yaccesso), ma il cookie di sessione è probabilmente impostato solo per l'utente iniziale che ha registrato su ssh.

Come posso superare questa difficoltà e inoltrare altre applicazioni X eseguite da utenti diversi?

Il motivo per cui non sto scrivendo direttamente è perché non voglio che quell'utente sia accessibile tramite ssh (è l'utente "virtualbox", che è ovviamente un bersaglio facile per i robot che cercano di inviare a quel server) ...

Risposte:


12

Quando ti connetti a una macchina di rimozione tramite ssh con l'inoltro X11 abilitato, ssh sul server crea un .Xauthorityfile nella home directory dell'utente. Poiché ssh ascolta X11 su un socket TCP, chiunque può connettersi. Poiché chiunque può connettersi, abbiamo bisogno di un modo per impedire a chiunque di utilizzare il display. Questo viene fatto con quel .Xauthorityfile. Il file contiene un "cookie" che viene presentato al server X11 per verificare che il client debba essere autorizzato a connettersi.

Saltando tutti i dettagli, se copi quel .Xauthorityfile nella home directory dell'utente di destinazione (e dai loro la proprietà), dovresti essere in grado di connetterti.


Vale la pena notare che anche dopo aver fatto ciò, la variabile DISPLAY deve essere impostata correttamente dopo aver cambiato utente. Questo può essere un problema quando si usa 'sudo' che può filtrare l'ambiente.
Chris Arguin,

8
  1. ssh -Y alla macchina remota come te stesso.
  2. Una volta lì, digita xauth list. Viene visualizzato un elenco di voci MAGIC-COOKIE. Molto probabilmente la tua sessione di accesso è quella in fondo all'elenco. (Controlla questo guardando il nome host e il codice numerico UNIX e confrontandolo con il nome host da cui hai bombardato e il tuo attuale localhost: ## DISPLAY variabile env.)
  3. Cambia utente.
  4. Digita xauth add+ l'intera riga MAGIC-COOKIE dall'alto.
  5. La grafica dovrebbe apparire ora. Provalo con una rapida xlogo.

2
nessun "+" in xauth add. Ad esempio, solo xauth aggiunge ubuntu / unix: 10 MIT-MAGIC-COOKIE-1 6b49de7c34409d5ac69beab31d12ec94
Tuntable

1
USER="otherusername" && MAGIC_COOKIE=`xauth list | tail -n1` && su -c "xauth add $MAGIC_COOKIE" $USER && su - $USER
7yl4r,

3

Mi piace la risposta di Randy, ma per me non ha funzionato.

Ecco cosa ho avuto modo di lavorare:

  1. ssh -Y as user1
  2. xauth list | grep `uname -n`
  3. Passa a utente2
  4. unset XAUTHORITY
  5. xauth generate :0 .
  6. xauth add :0 . <KEY-FROM-STEP-2>

Nota i due punti nei passaggi 5 e 6.

Se seguo semplicemente la risposta di Randy, la XAUTHORITYvariabile di user2 punta ancora al .Xauthorityfile di user1 . E la sua sintassi del tasto + non ha funzionato.


2

Questa non è una risposta, quindi se ne trovi una, ovviamente è preferibile.

In caso contrario, e questa è la causa principale del tuo enigma:

Il motivo per cui non sto scrivendo direttamente è perché non voglio che quell'utente sia accessibile tramite ssh (è l'utente "virtualbox", che è ovviamente un bersaglio facile per i robot che cercano di inviare a quel server) ...

Non mi sembra un grande ragionamento. "A cosa mirano i robot" WRT un SSH ben configurato è in gran parte irrilevante. Vivranno intorno alla porta 22 dappertutto? Apparentemente così. Questo significa che hanno effettivamente una possibilità di successo?

Prova a cercare su Google una storia su qualcuno che ha avuto un bot anonimo casuale ed è riuscito a entrare in sshd. Sono sicuro che deve essere successo a qualcuno da qualche parte (e, ovviamente, potresti non saperlo mai), ma non riesco a trovare alcuna notizia in merito. Sarebbe interessante leggere quale fosse la configurazione utilizzata.

SSH è molto sicuro se usato correttamente. Se non lo fosse, il commercio via Internet non sarebbe fattibile. Quindi perché questi robot si danno fastidio? Per "usato correttamente" intendo, principalmente, con coppie di chiavi pubbliche / private obbligatorie. Se lo fai e sei sicuro che la tua chiave privata sia sicura (e dovresti esserlo), sii sicuro di sshd.

Penso che il motivo per cui tutti i "tentativi di intrusione" si verificano affatto sia che esiste un gran numero di utenti che non fanno cose come fare domande su U&L;) e non leggono le pagine del manuale e usano la protezione con password da solo, che è un po 'come lasciare la tua carta bancomat in una macchina da qualche parte con un cartello che dice "Indovina!".

Tuttavia, se pensi alla tua chiave privata come alla tua carta bancomat - come qualcosa che è fisicamente protetto da te (cosa che essenzialmente è), allora il bersaglio diventa molto più etereo. Tutto ciò che questi robot possono fare è dimostrare che sì, ci vorrebbero davvero migliaia di macchine migliaia di anni che lavorano insieme per forzare una chiave a 2048 bit.

Se sei stanco di leggere i rapporti sui tentativi di intrusione, cambia la tua porta. Ho visto persone qui cacca come "sicurezza per oscurità", tuttavia, un SSH che è adeguatamente protetto sulla porta 22 non sarà meno sicuro sulla porta 57, ma non sarà disturbato casualmente. Ovviamente, tutti i tuoi nemici drone potrebbero semplicemente eseguire il port scan dell'intero IP - ma sai cosa? Non lo fanno. Presumo che questo sia perché ciò che stanno cercando è qualcuno che gestisce un sistema che non ha nemmeno guardato /etc/ssh/sshd_config, e tanto meno istruito se stesso e messo a punto.


Sono d'accordo con tutto quello che dici. ma sono sempre follemente insicuro (non è quello che ti insegnano in molte situazioni dopo che sei stato bruciato?). Ad essere sincero, il PC a cui sto tentando di accedere è un firewall (nessun accesso dall'esterno). Il suo ssh è su una porta alta, ha una password difficile, ma ancora non posso fare a meno di sentire che "virtualbox" è un nome pubblico. uno che qualcuno da qualche parte può scegliere di incorporare in un codice bot. Le chiavi SSH sono una soluzione meravigliosa soprattutto se utilizzate con la protezione con password. Ma dovrei avere una leggera distribuzione Linux su USB se dovessi usarli.
nass
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.