AutosshTunnel » Cronologia » Versione 5
Simone Piccardi, 27-03-2017 18:56
1 | 1 | Simone Piccardi | h1. Creare tunnel permanenti con autossh |
---|---|---|---|
2 | |||
3 | 2 | Simone Piccardi | Ci sono molte occasioni un cui creare occorre creare delle connessioni verso macchine e servizi che sono protette da firewall che è opportuno cifrare e proteggere adeguatamente, ma per le quali la creazione di una VPN diventa un onere eccessivo. |
4 | 1 | Simone Piccardi | |
5 | 5 | Simone Piccardi | Per delle operazioni temporanee la capacità di _port forwarding_ di SSH è molto utile per creare un tunnel cifrato da una macchina ad un'altra, consentendo anche di condividere accessi locali (come ad esempio ad un MySQL che ascolta solo localmente) in maniera sicura, il problema sorge quando si vuole fornire una connessione permanente, in tal caso infatti lasciare attivo il programma può non bastare, perché la connessione SSH (ed il relativo tunnel) potrebbero cadere in caso di problemi sulla rete. |
6 | 1 | Simone Piccardi | |
7 | 5 | Simone Piccardi | Per ovviare a questa eventualità e creare tunnel permanenti, ci viene in aiuto @autossh@, un semplice programma che consente di eseguire una istanza di @ssh@ mantenendola sotto controllo, e riavviando la stessa qualora la connessione dovesse cadere fino ad un numero massimo di volte controllato dalla variabile di ambiente @AUTOSSH_MAXSTART@ o indefinitamente se il valore di questa è negativo (che è il comportamento di default). |
8 | 1 | Simone Piccardi | |
9 | 5 | Simone Piccardi | Il programma infatti rileva se l'istanza di @ssh@ che ha lanciato termina per un segnale o un errore di connessione e nel caso la riesegue, se invece si termina @ssh@ con un segnale di SIGKILL @autossh@ interpreta la cosa come una terminazione esplicita, e si ferma anche lui. Allo stesso modo viene interpretato un segnale di terminazione inviato ad @autossh@ stesso, che nel caso esce terminando anche l'istanza di @ssh@. |
10 | 1 | Simone Piccardi | |
11 | 5 | Simone Piccardi | Il comando prende una opzione principale, @-M@ che consente di indicare una porta usate per il monitoraggio della connessione (per verificare cioè che l'istanza di @ssh@ sia attiva e funzionante utilizza la porta indicata e la successiva per mandare dei messaggi che gli devono tornare indietro). Con la versione 2 del protocollo @ssh@ supporta un controllo interno della connessione, che è più affidabile, pertanto si suggerisce di usare le opportune opzioni di controllo (che vedremo più avanti) ed indicare sempre un valore nullo (cioè @-M 0@) che disabilita questo monitoraggio. |
12 | 2 | Simone Piccardi | |
13 | 5 | Simone Piccardi | L'altra opzione principale di @autossh@ è @-f@ che imposta l'esecuzione in background. Il resto del comportamento del programma è controllato da una serie di ulteriori variabili di ambiente per il significato delle quali si rimanda alla lettura della pagina di manuale (i valori di default sono adatti all'uso ordinario, possono essere modificati in caso di problemi o per attivare diagnostiche). |
14 | 4 | Simone Piccardi | |
15 | 2 | Simone Piccardi | L'uso di @autossh@ consente di creare un numero arbitrario di tunnel in maniera molto sicura, se infatti non è necessario mettersi in ascolto su porte riservate, si può far eseguire il programma per conto di un utente non privilegiato, che nel nostro caso sarà appunto @autossh@. Si provvederà allora a creare detto utente su entrambi i capi del tunnel con: |
16 | |||
17 | <pre> |
||
18 | useradd -m -s /bin/false autossh |
||
19 | </pre> |
||
20 | |||
21 | e si noti come per l'utente si sia disabilitata la shell e non si sia impostata la password, cosa che renderà impossibile usare l'utente per un accesso al sistema (che non ci serve essendo esso utilizzato solo allo scopo di creare il tunnel). |
||
22 | |||
23 | 5 | Simone Piccardi | La scelta di non impostare la password richiede l'uso della autenticazione a chiavi, cosa che è comunque il caso di usare sempre, e se possibile in maniera esclusiva. Per questo sul capo della connessione che deve creare il tunnel si dovrà creare una chiave per l'utente, che, se si vuole che il tunnel possa partire automaticamente all'avvio, dovrà essere senza password; pertanto si dovranno eseguire i seguenti comandi: |
24 | 2 | Simone Piccardi | |
25 | <pre> |
||
26 | 5 | Simone Piccardi | # su -s /bin/bash autossh |
27 | $ ssh-keygen |
||
28 | 2 | Simone Piccardi | Generating public/private rsa key pair. |
29 | Enter file in which to save the key (/home/autossh/.ssh/id_rsa): |
||
30 | Enter passphrase (empty for no passphrase): |
||
31 | Enter same passphrase again: |
||
32 | Your identification has been saved in /home/autossh/.ssh/id_rsa. |
||
33 | Your public key has been saved in /home/autossh/.ssh/id_rsa.pub. |
||
34 | The key fingerprint is: |
||
35 | b6:b7:d5:1e:fd:b0:62:57:b5:77:4c:33:82:78:f7:06 autossh@dodds |
||
36 | The key's randomart image is: |
||
37 | +--[ RSA 2048]----+ |
||
38 | | | |
||
39 | | | |
||
40 | | . . | |
||
41 | | . o E oo| |
||
42 | | S . . +o=| |
||
43 | | . . . ==| |
||
44 | | . . . =.+| |
||
45 | | . oo..+.| |
||
46 | | .. oo .| |
||
47 | +-----------------+ |
||
48 | </pre> |
||
49 | 3 | Simone Piccardi | |
50 | (è necessario usare @su@ con il primo comando per impersonare l'utente @autossh@ dato che questo non ha una shell né una password valida). |
||
51 | |||
52 | Una volta fatto questo si dovrà aver cura di copiare la chiave pubblica sulla/e macchina/e di destinazione ed installarla nelle home degli utenti @autossh@ ivi creati sotto @.ssh/authorized_keys@; si verifichi che detto file appartenga ad @autossh@. |
||
53 | |||
54 | 5 | Simone Piccardi | A questo punto si potrà creare un tunnel semplicemente lanciando @ssh@ con le opzioni necessarie tramite @autossh@. Dato che si vuole solo creare un tunnel occorrerà usare l'opzione @-N@ per dire a @ssh@ di non lanciare nessun comando (non sarebbe comunque possibile, avendo impostato @/bin/false@ come shell), inoltre sono importanti le opzioni: |
55 | 3 | Simone Piccardi | |
56 | <pre> |
||
57 | -o "ServerAliveInterval 60" |
||
58 | -o "ServerAliveCountMax 3" |
||
59 | 1 | Simone Piccardi | </pre> |
60 | |||
61 | 5 | Simone Piccardi | che consentono di attivare il controllo interno della sussistenza della connessione di @ssh@; il tunnel potrà poi essere attivato con le solite opzioni @-L@ o @-R@ a seconda della direzione. |
62 | 1 | Simone Piccardi | |
63 | 5 | Simone Piccardi | Se allora ad esempio si vuole creare un tunnel per la connessione ad un database MySQL remoto di una macchina che è raggiungibile in SSH, una volta creati gli utenti, come descritto, sarà sufficiente eseguire il comando: |
64 | 1 | Simone Piccardi | |
65 | <pre> |
||
66 | su -s /bin/sh autossh -c 'autossh -M 0 -q -f -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -L 3306:localhost:3306 autossh@macchinaremota' |
||
67 | </pre> |
||
68 | |||
69 | 5 | Simone Piccardi | ed almeno la prima volta occorrerà confermare la validità della fingerprint della chiave dell'altro capo della connessione. |
70 | 1 | Simone Piccardi | |
71 | 5 | Simone Piccardi | Allo stesso modo, se si vuole creare un tunnel per consentire un accesso di amministrazione remota ad una macchina posta dietro un firewall per la quale non è possibile un accesso diretto si potrà usare un comando del tipo: |
72 | |||
73 | <pre> |
||
74 | su -s /bin/sh autossh -c 'autossh -M 0 -q -f -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 20001:localhost:22 autossh@macchinaremota' |
||
75 | </pre> |
||
76 | |||
77 | ed in questo modo lanciando sull'altro capo del tunnel il comando @ssh -p 20001 root@localhost@ ci si potrà ricollegare all'indietro. |
||
78 | |||
79 | Con i comandi indicati, che portano @autossh@ in background il tunnel resta attivo fintanto che non lo si interrompe esplicitamente o si riavvia la macchina. Per abilitare il tunnel in maniera permanente all'avvio la cosa più semplice è inserire il comando in @/etc/rc.local@ o file analogo per il proprio sistema di avvio. |
||
80 | |||
81 | Qualora si utilizzi @systemd@ si può utilizzare la _unit file_ illustrata di seguito (ma ci si ricordi che si deve comunque aver cura di eseguire almeno una volta il comando manualmente, per accettare la fingerprint del server a cui ci si connette): |
||
82 | |||
83 | <pre> |
||
84 | [Unit] |
||
85 | Description=AutoSSH tunnel service for SSH remote access |
||
86 | After=network.target |
||
87 | |||
88 | [Service] |
||
89 | Environment="AUTOSSH_GATETIME=0" |
||
90 | ExecStart=/usr/bin/autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -NR 20001:localhost:22 autossh@macchinaremota |
||
91 | User=autossh |
||
92 | |||
93 | [Install] |
||
94 | WantedBy=multi-user.target |
||
95 | </pre> |
||
96 | |||
97 | Si noti come in questo caso non è possibile lanciare @autossh@ con l'opzione @-f@, perché l'avvio in background non è supportato da @systemd@ (è cura di @systemd@ eseguire il tutto in background). Però occorre anche indicare ad @autossh@ di ripetere la connessione anche se questa fallisce inizialmente, impostando la variabile di ambiente @AUTOSSH_GATETIME@ ad un valore nullo (questo è il default se si usa @-f@ ma non nell'uso normale). |
||
98 | |||
99 | Installando la _unit file_ precedente sotto @/etc/systemd/system@ (ad esempio come @autossh-tunnel.service@) sarà possibile attivare il tunnel con: |
||
100 | |||
101 | <pre> |
||
102 | systemctl start autossh-tunnel |
||
103 | </pre> |
||
104 | |||
105 | verificarne lo stato con: |
||
106 | |||
107 | <pre> |
||
108 | systemctl status autossh-tunnel |
||
109 | </pre> |
||
110 | |||
111 | e predisporne l'attivazione all'avvio con: |
||
112 | |||
113 | <pre> |
||
114 | systemctl enable autossh-tunnel |
||
115 | </pre> |