Come faccio a SSH per lavorare A tramite B in un comando?

69

Voglio accedere a un computer, ad esempio macchina A che si trova nella rete della mia università. Tuttavia, questo computer è accessibile solo tramite la rete interna dell'università, quindi non posso usare SSH su questo computer direttamente da casa.

Ecco cosa faccio ora:

  1. Accedi a un altro computer universitario, ad esempio computer B

    (Questa macchina B è accessibile tramite SSH dal mio computer di casa.)

  2. Usa SSH su B per connetterti ad A.

C'è un modo per farlo più velocemente? Usando solo un comando ssh.

    
posta nikosdi 22.06.2013 - 17:03

6 risposte

76

Sì, utilizzando ProxyCommand nella configurazione SSH.

Crea un file di configurazione SSH nella tua home directory (a meno che non vuoi renderlo a livello di sistema), ~/.ssh/config :

Host unibroker          # Machine B definition (the broker)
Hostname 12.34.45.56    # Change this IP address to the address of the broker
User myusername         # Change this default user accordingly 
                        # ('[email protected]' can overwrite it)

Host internalmachine    # Machine A definition (the target host)
ProxyCommand ssh -q unibroker nc -q0 hostname.or.IP.address.internal.machine 22

Ora puoi raggiungere direttamente la Macchina A usando

ssh [email protected]

Nota anche che ora hai un singolo nome di destinazione host SSH per questo, puoi usarlo anche in altre applicazioni. Per esempio:.

Note

Modifica hostname.or.IP.address.internal.machine e la porta ( 22 ) sulla macchina che desideri raggiungere come se fossi dalla macchina unibroker .

A seconda delle versioni di netcat sull'host unroker, l'opzione -q0 deve essere omessa. Per quanto riguarda l'autenticazione; in pratica stai configurando due connessioni SSH dalla tua workstation. Ciò significa che sia l'host unbroker che l'host della macchina interna vengono verificati / autenticati uno dopo l'altro (sia per la verifica della coppia chiave / keypair che della chiave host).

Spiegazione

Questo approccio all'uso di ProxyCommand e 'netcat' è solo un modo per farlo. Mi piace perché il mio client SSH parla direttamente alla macchina di destinazione in modo che possa verificare la chiave host dal mio client e posso utilizzare la mia autenticazione a chiave pubblica senza utilizzare un'altra chiave sul broker.

Ogni Host definisce l'inizio di una nuova sezione host. Hostname è il nome host di destinazione o l'indirizzo IP di quell'host. User è ciò che forniresti come parte utente in ssh [email protected] .

ProxyCommand verrà utilizzato come pipe per il computer di destinazione. Usando SSH sulla prima macchina e impostando direttamente un semplice 'netcat' ( nc ) sulla destinazione da lì, questo è fondamentalmente solo un testo in chiaro verso la macchina interna dal broker tra quelli. Le opzioni -q servono a silenziare qualsiasi output (solo una preferenza personale).

Assicurati di avere netcat installato sul broker (solitamente disponibile per impostazione predefinita su Ubuntu): netcat-openbsd < img src="https://hostmar.co/software-small"> o netcat-traditional < img src="https://hostmar.co/software-small"> .

Nota che stai ancora utilizzando SSH con crittografia due volte qui. Mentre il canale netcat è in chiaro, il tuo client SSH sul tuo PC configurerà un altro canale crittografato con il computer di destinazione finale.

    
risposta data gertvdijk 22.06.2013 - 17:24
36

Hop in one go

Un'ovvia alternativa all'approccio ProxyCommand che ho fornito in la mia altra risposta sarebbe stata "saltata" direttamente sulla macchina di destinazione :

ssh -t [email protected] ssh [email protected]

Notare -t sul primo comando ssh . Senza di esso, fallirà:

Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.
[...]

Forzerà l'assegnazione di un vero TTY

Il lato negativo di questo è che ora tutta la configurazione, la verifica e l'autenticazione avvengono alla macchina B, cosa che non mi piace davvero nella mia situazione per motivi di sicurezza. Mi piace la mia coppia di chiavi sul mio PC e autenticarsi e verificare la macchina target finale dal mio PC. Inoltre, è possibile utilizzare la shell interattiva solo per SSH, quindi non si tratterà di altri strumenti come SCP o l'utilizzo del gestore file della GUI.

Per tutti i suddetti motivi raccomando vivamente l'approccio ProxyCommand , ma per una connessione rapida funziona bene.

    
risposta data gertvdijk 22.06.2013 - 17:47
14

Prova a usare

Host <visible hostname alias>
        Controlmaster auto
        User <user>
        hostname <visible hostname>
        port <port>
        IdentityFile ~/.ssh/<id file>

Host <private LAN hostname alias>
     ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>

nel tuo ~ / .ssh / config e fai tutto in un colpo solo con le chiavi che risiedono sul tuo computer.

    
risposta data SSH Help 29.07.2014 - 15:49
11

Potresti utilizzare l'opzione della riga di comando -J :

ssh -J [email protected] [email protected]

Da man ssh :

-J [[email protected]]host[:port]
     Connect to the target host by first making a ssh connection to
     the jump host and then establishing a TCP forwarding to the
     ultimate destination from there.  Multiple jump hops may be
     specified separated by comma characters.  This is a shortcut to
     specify a ProxyJump configuration directive.

È stato introdotto in OpenSSH versione 7.3 (pubblicato ad agosto 2016). È disponibile in Ubuntu 16.10 e versioni successive.

    
risposta data Erik Sjölund 16.01.2018 - 17:19
1

ProxyCommand è una soluzione pulita per un caso che consente l'accesso alla shell in entrambi i sistemi. Volevamo offrire agli utenti remoti l'accesso a un computer interno (A) tramite un broker (B), ma senza consentire all'utente un accesso shell a B per una maggiore sicurezza. Questo ha funzionato:

Sostituisci la shell di login

Sostituisci la shell di login (usa chsh ) per extuser sul broker con il seguente script (memorizzato in un file):

#!/bin/sh   # this is essential to avoid Exec format error
ssh [email protected]

Se non è stato impostato il login della password in extuser @ B per l'utente remoto e in internaluser @ A per extuser @ B, quindi l'esecuzione del seguente comando porterà direttamente l'utente remoto su A

ssh [email protected]

Suggerimento : crea l'autenticazione no_utenti necessaria login_keys in extuser @ B prima di passare alla shell di login personalizzata. Dopo la modifica, poiché questo account è inaccessibile a chiunque attraverso una shell, solo un sudoer @ B può apportare modifiche al file authorized_keys modificandolo direttamente.

sudo vi ~extuser/.ssh/authorized_keys
sudo touch ~extuser/.hushlogin

L'ultima riga deve sopprimere il display del banner di accesso da B, quindi l'utente remoto ha un accesso trasparente ad A.

    
risposta data Sunthar 08.06.2016 - 20:27
0

Questo è un suggerimento molto utile. Dopo aver incasinato per ore, ho trovato questa nota, & amp; confermato questo funziona esattamente come documentato. Per connettere Thr MachineA a MachineB, da remote machineC:

es .: [xuser @ machineC ~] ssh -t MachineUn ssh MachineB

Il "-t" è critico, ssh fallisce se non è presente. Verrà richiesto due volte, prima per la password su MachineA, quindi per la seconda volta ComputerB. Inoltre, si noti che questo presuppone che l'utente "xuser" sia definito su tutti tre macchine. In caso contrario, utilizzare la sintassi ssh: "yuser @ MachineA ...". Si noti inoltre che è possibile utilizzare i # IP puntati quadrupli, se lo si desidera. Questo è utile se stai collegando attraverso una rete locale privata che utilizza IP non esposti al mondo, ad es. Non in il tuo file host locale o qualsiasi DNS. Per ottenere un file da MachineB, a machineC remoto, è possibile scp da MachineB a MachineA, quindi da MachineA a machineC remoto. (Ad esempio il remote machineC può eseguire il ping su MachineA, ma non su MachineB.) Caveat: Ho provato con Fedora e WindowsXP, MachineA è un XP-box con ICS (Internet Connection Sharing), mentre MachineB e remote machineC sono box Fedora-Linux. Questo suggerimento ha risolto per me un problema chiave, ad es. accesso remoto controllato e controllato al mio sito remoto. Nota anche, quando si "disconnette" da MachineB, dovresti vedere due "Connessione a xxx.xxx.xxx.xxx chiusa". messaggi.

    
risposta data Mcl 17.04.2014 - 00:34

Leggi altre domande sui tag