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

Vorrei accedere alla port ssh del mio host di linux dell'ufficio da casa. Purtroppo l'host si trova dietro un router NAT. Quindi l'indirizzo IP non è pubblicamente disponibile. C'è tuttavia l'accesso ad un altro host di Internet (Server) che è purtroppo solo accesso non root. Dopo un po 'di ricerca non trovo una soluzione adeguata.

Dopo l'installazione:

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

Possibili connessioni: Office PC -> Server <- Home PC

Non è ansible: Office PC <-X- Server -X-> PC Home

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

Il tunnel inverso di SSH non è ansible: ho provato un metodo chiamato tunnel reverse ssh. Purtroppo questo richiede GatewayPorts su Server impostato su "yes" in / etc / ssh / sshd_config, where non ho accesso root.

In linea di principio dovrebbe essere ansible:

0) Sul server iniziano un programma userspace che ascolta su 2 porte (1 in entrata, 1 in output)

1) Sul mio PC dell'ufficio ho un altro programma che mantiene una connessione TCP aperta alla port in output sul server.

2) Da casa mi connetti alla port in arrivo del server.

Ci dovrebbe essere una soluzione standard per questo là fuori.

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

Franco

[email protected]$ autossh -R 12345:localhost:22 [email protected] 

Dopo:

 [email protected]$ autossh -L 23456:localhost:12345 [email protected] [email protected]$ ssh [email protected] -p 23456 

Quello che puoi fare è questo: al passaggio 1 inoltra una port remota dal PC dell'ufficio al server ( 12345 viene utilizzato come esempio, qualsiasi port> 1024 dovrebbe fare). Ora il collegamento a 12345 sul server dovrebbe connettersi alla port 22 su officepc.

Nel passaggio 2, inoltrare la port 23456 dalla propria macchina domestica a 12345 sul server (da where viene inoltrata a officepc: 22, come impostato nel passaggio 1)

Al passaggio 3, si connette alla port locale 23456 con il login del proprio PC . Questo viene inoltrato dal passaggio 2 alla port 12345 sul server e dal passaggio 1 al PC dell'ufficio.

Si noti che sto usando autossh per le inoltro, in quanto è un wrapper ssh che ricollega automaticamente il tunnel se deve essere disconnesso; comunque il normale ssh functionrebbe bene, a patto che la connessione non cada.

Esiste una vulnerabilità: chiunque può connettersi a localhost: 12345 in serverpc può ora connettersi a officepc: 22 e cercare di incidere. (Si noti che se si esegue un server SSH, è comunque necessario proteggerlo sopra le protezioni di base attive per impostazione predefinita; consiglio alless distriggersre l'accesso di root e distriggersre l'authentication della password – vedere ad esempio)

Modifica : Ho verificato questo con la stessa configuration e funziona. GatewayPorts no riguarda solo le porte aperte al mondo in grandi size e non alle gallerie locali. Questo è ciò che le porte inoltrate sono:

 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 networking, è tutto il traffico locale sulle rispettive interfacce di loopback (più le connessioni ssh a serverpc); quindi GatewayPorts non è affatto verificato.

Esiste tuttavia la direttiva AllowTcpForwarding : se no è così, questa configuration non riesce in quanto non è consentita alcuna trasmissione, nemless in tutta l'interface di loopback.

Se si può ssh al server interno da casa e dal server interno alla macchina Linux, quindi da casa è ansible utilizzare ssh ProxyCommand per rimbalzare in silenzio attraverso il server alla macchina interna tramite nc (netcat)

 # ~/.ssh/config on your home machine: Host internalpc ForwardAgent yes ProxyCommand ssh [email protected] exec nc internal.pc.example.com %p 

Poi si fa solo ssh [email protected] e si inoltano in silenzio attraverso la macchina server, senza apertura di porte o tunnel richiesti da entrambe le estremità.

Installare Robo-TiTO nel computer in cui si desidera accedere SSH in remoto.

  • Ciò vi permetterà di accedere a SSH utilizzando da Google Talk Client Apps ovunque.
  • Non è necessario un indirizzo IP pubblico o impostazioni speciali.
  • È Free e Open Source, non paga più alcun servizio di applicazione.
  • Non è necessario aprire la port SSH (tenere il computer protetto).
  • Non c'è bisogno di aprire alcun tunneling (ad esempio, VPN o qualcosa del genere)

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

Ho eseguito uno script (testato sul mio sistema Raspbian in Raspberry Pi) in modo da poter installare facilmente Robo-TiTO su Raspberry Pi, Debian o Ubuntu Box (distribuzione dei pacchetti Debian). questi sono i passaggi per get la tua casella di posta elettronica remota:

  1. Apri il command Shell oppure puoi chiamarlo Terminale, vai alla cartella di casa, Scarica script di installazione per command:

     $ wget https://opengateway.googlecode.com/files/robotito 
  2. dopo aver eseguito lo script inserendo il command:

     $ sudo ./robotito 
  3. e quindi puoi modificare credentials.rb file dalla cartella di configuration di Robo-TiTO utilizzando il tuo account GTalk e salvarlo premendo Ctrl + X e Y. Il predefinito utilizza l'editor nano.

  4. eseguire il Robo-TiTO dalla cartella Robo-TiTO per command

     $ cd robotito $ ./jabbershd start 
  5. Ora che questo è fatto è ansible utilizzare SSH da qualsiasi client Google Talk. Non dimenticare di aggiungere il conto Robal-TiTO GTalk all'account di conversazione di Google e provarlo a chiacchierare tra di loro prima di utilizzare l'account.

A me sembra che, invece di un tunnel SSH, dovresti provare una VPN: il genere che funziona usando un server all'esterno per proxy, come ad esempio Hamachi . Ci sono altri software gratuiti come questo, ma Hamachi è la mia fav.

La soluzione di Piskvor funziona ed è bello. Tuttavia, mantiene i terminali che appaiono aperti con le appendici di login appese. Non molto cool.

Ho sempre usato questo piccolo script che ho scritto per connettersi a un server e mantenerlo collegato 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 utilizzando l'autossh più elegante accanto a forse uno schermo distaccato o utilizzare gli argomenti di -NT ssh per mantenere la connessione in background.