Accesso SSH all'host dell'ufficio dietro il router NAT

Vorrei accedere alla porta SSH del mio host Linux da casa. Sfortunatamente l'host si trova dietro un router NAT. Pertanto, l'indirizzo IP non è disponibile pubblicamente. Vi è tuttavia l'accesso a un altro host Internet (Server) che purtroppo è solo un accesso non root. Dopo un po 'di ricerche non trovo una soluzione adatta.

Seguente installazione:

• PC Office (Linux, accesso root) dietro NAT (IP non pubblico) ma accesso completo a Internet.
• Server PC (Linux, nessun accesso root) IP pubblico e statico e accesso completo a Internet.
• PC domestico (linux, accesso root) dietro NAT (IP non pubblico) ma accesso completo a Internet.

Possibili connessioni: PC Office -> Server <- PC di casa

Impossibile: PC di Office <-X- Server -X-> PC di casa

Né il PC di casa, né il server possono avviare l'accesso al PC di Office. Ma sia il PC di Office che il PC di casa possono avviare connessioni al server.

Tunnel SSH inverso impossibile: ho provato un metodo chiamato tunnel ssh inverso. Sfortunatamente questo richiede GatewayPorts su Server impostato su "yes" in / etc / ssh / sshd_config, dove non ho accesso root.

In linea di principio dovrebbe essere possibile:

0) Sul server avvio un programma di spazio utente che è in ascolto su 2 porte (1 in entrata, 1 in uscita)

1) Sul mio PC da ufficio eseguo un altro programma che mantiene aperta una connessione TCP alla porta in uscita sul server.

2) Da casa mi collego alla porta di ingresso del server.

Dovrebbe esserci una soluzione standard per questo là fuori.

Qual è la soluzione più rapida e pulita per risolvere questo?

Franco

youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc

Dopo:

you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc

you@homepc$ ssh youatwork@localhost -p 23456

Quello che potresti fare è questo: nel passaggio 1 inoltra una porta remota dal PC dell'ufficio al server ( 12345viene utilizzato come esempio, qualsiasi porta> 1024 dovrebbe fare). Ora la connessione a 12345 sul server dovrebbe connetterti alla porta 22 su officepc.

Nel passaggio 2, inoltrare la porta 23456 dal computer di casa al 12345 sul server (da cui viene inoltrato a officepc: 22, come impostato nel passaggio 1)

Al passaggio 3, ci si collega alla porta locale 23456 con l'accesso al PC dell'ufficio . Questo viene inoltrato dal passaggio 2 alla porta 12345 sul server e dal passaggio 1 al PC dell'ufficio.

Nota che sto usando autossh per gli inoltri, in quanto è un wrapper ssh che ricollega automaticamente il tunnel in caso di disconnessione; comunque anche il normale ssh funzionerebbe, purché la connessione non cessi.

Esiste una possibile vulnerabilità: chiunque sia in grado di connettersi a localhost: 12345 su serverpc ora può connettersi a officepc: 22 e provare ad hackerarlo. (Nota che se stai eseguendo un server SSH, dovresti comunque proteggerlo sopra le protezioni di base che sono attive di default; ti consiglio almeno di disabilitare il login di root e disabilitare l'autenticazione con password - vedi ad esempio questo )

Modifica : ho verificato questo con la stessa configurazione e funziona. GatewayPorts noriguarda solo le porte aperte al mondo in generale, non i tunnel locali. Ecco cosa sono le porte inoltrate:

homepc:
  outgoing ssh to serverpc:22
  listening localhost:23456 forwarded through ssh tunnel
serverpc:
  listening ssh at *:22
  incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
  listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
  outgoing ssh to serverpc:22
  incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22

Quindi, per quanto riguarda lo stack di rete, è tutto il traffico locale sulle rispettive interfacce di loopback (oltre alle connessioni ssh a serverpc); pertanto, GatewayPortsnon viene controllato affatto.

Esiste, tuttavia, la direttiva AllowTcpForwarding: in tal caso no, questa installazione non riuscirà poiché non è consentito alcun inoltro, nemmeno attraverso l'interfaccia di loopback.

Avvertenze :

• se usi autossh e ssh recenti, potresti voler usare ssh ServerAliveIntervale ServerAliveCountMaxper mantenere alto il tunnel. Autossh ha un controllo integrato, ma a quanto pare ha alcuni problemi su Fedora. -M0lo disabilita e -oServerAliveInterval=20 -oServerAliveCountMax=3verifica se la connessione è attiva - prova ogni 20 secondi, se fallisce 3 volte di seguito, interrompe ssh (e autossh ne crea una nuova):

  autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  
  autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  

• potrebbe essere utile riavviare ssh tunnel se l'inoltro fallisce, usando -oExitOnForwardFailure=yes- se la porta è già associata, potresti ottenere una connessione SSH funzionante, ma nessun tunnel inoltrato.

• ~/.ssh/configè consigliabile usare per le opzioni (e le porte), altrimenti le righe di comando diventano troppo dettagliate. Per esempio:

  Host fwdserverpc
      Hostname serverpc
      User notroot
      ServerAliveInterval 20
      ServerAliveCountMax 3
      ExitOnForwardFailure yes
      LocalForward 23456 localhost:12345
  

Quindi è possibile utilizzare solo l'alias del server:

    autossh -M0 fwdserverpc

Se puoi ssh sul server interno da casa e dal server interno alla tua macchina Linux dell'ufficio, da casa puoi usare ssh ProxyCommandper rimbalzare silenziosamente attraverso il server alla macchina interna tramite nc(netcat)

# ~/.ssh/config on your home machine:
Host internalpc 
   ForwardAgent yes 
   ProxyCommand ssh user@server.example.com exec nc internal.pc.example.com %p

Quindi sei semplicemente ssh user@internalpce sei inoltrato silenziosamente attraverso la macchina del server, nessuna apertura di porte o tunnel richiesta su entrambe le estremità.

Installa Robo-TiTO sul computer a cui vuoi accedere a SSH da remoto.

• Ciò ti consentirà di accedere a SSH utilizzando dalle app client di Google Talk ovunque.
• Non è necessario un indirizzo IP pubblico o un'impostazione speciale.
• È gratuito e open source, non paga più alcun servizio di applicazione.
• Non è necessario aprire la porta SSH (proteggere il computer).
• Non è necessario aprire alcun tunneling (ad es. VPN o qualcosa del genere)

Le seguenti istruzioni di installazione sono obsolete, poiché il sito è stato spostato. Il nuovo URL è https://github.com/formigarafa/robotito

Ho creato uno script (testato sul mio sistema operativo Raspbian in Raspberry Pi) in modo da poter installare facilmente Robo-TiTO su Raspberry Pi, Debian o Ubuntu Box (distribuzione di pacchetti Debian). questi sono i passaggi per rendere remotabile il tuo box Linux:

1. Apri il comando Shell o puoi chiamarlo Terminale, vai alla cartella principale, Scarica lo script di installazione con il comando:

   $ wget https://opengateway.googlecode.com/files/robotito
   

2. dopodiché esegui lo script inserendo il comando:

   $ sudo ./robotito
   

3. e quindi puoi modificare il file credentials.rbdalla cartella di configurazione di Robo-TiTO usando il tuo account GTalk e salvarlo premendo Ctrl+ Xe Y. L'impostazione predefinita utilizza nano editor.

4. eseguendo il comando Robo-TiTO dalla cartella Robo-TiTO

   $ cd robotito
   $ ./jabbershd start
   

5. Ora che hai fatto puoi usare SSH da qualsiasi client di Google Talk. Non dimenticare di aggiungere l'account Robo-TiTO GTalk al tuo account Google Talk e testarlo chattando a vicenda prima di utilizzare l'account.

La soluzione di Piskvor funziona ed è carina. Tuttavia, mantiene i terminali penzoloni aperti con le shell di login sospese. Non molto figo.

Ho sempre usato questo piccolo script che ho scritto per connettermi a un server e mantenerlo connesso eseguendolo in cron:

#!/bin/bash
TARGET_HOST=${1:-myserver.example.com}
TARGET_PORT=${2:-7777}
TUNNEL_PORT=${3:-22}
T_USER="odin"

#Check that we have an active connection to the remote system
ACTIVE_PROCESS=`ps -ef | \
    grep "ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT" | \
    grep -v grep | \
    wc -l`
if [ $ACTIVE_PROCESS -lt 1 ]; then
    echo "`date` : establishing connection to $TARGET_HOST on port $TARGET_PORT"
    screen -m -d ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT > /dev/null
fi

Scommetto che potremmo risolvere la soluzione di Piskvor usando l'autossh più elegante a fianco forse di uno schermo staccato o usare gli argomenti -NT ssh per mantenere la connessione in background.

Per me sembra che, invece di un tunnel SSH, dovresti provare una VPN: il tipo che funziona usando un server esterno per eseguire il proxy, come Hamachi . Ci sono altri software gratuiti come questo, ma Hamachi è il mio preferito.