OpenSSH: non solo shell

Premessa

Si danno per scontate conoscenze quali come installare e lanciare un demone OpenSSH e metterlo in ascolto in modo che sia raggiungibile sulla porta 443 da Internet. Perché la 443 e non la standard 22? Perché spesso in situazioni di accesso ad internet limitato, ad esempio dietro firewall con porte in uscita filtrate oppure dietro a proxy HTTP/HTTPS trasparenti e non, le porte 80 e 443 sono le uniche su cui si possa "uscire". I proxy inoltreranno la 80 solo come traffico HTTP mentre verso le 443 permetteranno connessioni criptate SSL, proprio quello che serve a noi per connetterci al nostro demone OpenSSH.

Proxy non trasparente

Per far funzionare OpenSSH attraverso un server proxy HTTP per traffico criptato non trasparente è necessario utilizzare un semplice programmino chiamato corkscrew. Corkscrew è un tool che ci permette di tunnellare la connessione SSH attraverso tale proxy. Una volta installato corkscrew, aggiungere le seguenti istruzioni al file ~/.ssh/config:

ProxyCommand /usr/bin/corkscrew proxy.mynetwork.it 8080 %h %p ~/.ssh/mynetwork_proxy_auth

e mettere in ~/.ssh/mynetwork_proxy_auth le informazioni per l'autenticazione:

username:password

per disattivare l'utilizzo di corkscrew (che impedisce il funzionamento di SSH una volta che non vi trovate più nella rete mynetwork.it) basta commentare la riga in ~/.ssh/config

#ProxyCommand ...

Connessioni verso porte filtrate dal firewall (ovvero OpenSSH come proxy SOCKS)

Supponiamo di voler usare il nostro client di posta preferito all'interno della nostra rete "filtrata/proxata": impresa a prima vista impossibile! Ma non per OpenSSH :) Infatti questo fantastico tool può svolgere anche la funzione di proxy SOCKS. Ovvero invece che provare (fallendo malamente) a connetterci dalla nostra macchina al server di posta, lasceremo che sia la macchina sulla quale il demone OpenSSH è in esecuzione a farlo, inoltrandoci poi il contenuto della connessione. Più difficle a dirsi che a farsi!

ssh -D 1080 -p 443 pincopallino.no-ip.org

Avremo adesso un server SOCKS in ascolto sulla porta 1080. Si pone ora il problema di come "suggerire" al client di posta di non provare direttamente a connettersi al server di posta, bensì sfruttare il server SOCKS. Ci sono due possibilità:

• il client di posta supporta nativamente i server SOCKS: basterà configurarlo impostando localhost come indirizzo del server SOCKS e 1080 come porta sulla quale è in ascolto;
  
• il client non supporta nativamente i server SOCKS: dovremmo usare un tool che intercetta le connessioni e le redirige al server SOCKS in modo trasparente all'applicazione. In questa guida useremo tsocks.

Configurazione di tsocks

Innanzitutto:

man tsocks.conf

Se la rete locale aziendale è 192.168.123.0/24 aggiungeremo le seguenti regole al file tsocks.conf (in gentoo /etc/socks/tsocks.conf)

local = 192.168.123.0/255.255.255.0

server = 127.0.0.1
server_port = 1080
server_type = 5

Che si potrebbe leggere "le connessioni verso la rete 192.168.123.0/24 non devono essere redirette, tutte le altre connessioni devono passare da localhost (127.0.0.1) sulla porta 1080 (dove troverai un server SOCKSv5)".

Ora potremo lanciare il client di posta (nell'esempio claws-mail) nel seguente modo:

tsocks claws-mail

KDE e i proxy SOCKS

KDE ha un ottimo supporto per i proxy SOCKS e, in particolare, per Dante. Dante è un pacchetto applicativo che contiene sia un server SOCKS che delle librerie lato client entrambi altamente configurabili: i programmi di KDE saranno in grado di usare queste librerie per connettersi ad internet, passando per il proxy seguendo le direttive che impartiremo.

(Su Ubuntu per installare le librerie lato client di Dante usate il pacchetto dante-client)

/etc/socks.conf (o analogo sulla vostra distribuzione, l'importante è che sia socks.conf e NON sockd.conf, che è il file di configurazione del server):

route {
        from: 0.0.0.0/0 to: 0.0.0.0/0 port = 53 via: direct
}

route {
        from: 0.0.0.0/0 to: 0.0.0.0/0 port = 80 via: direct
}

route {
        from: 0.0.0.0/0 to: 0.0.0.0/0 port = 443 via: direct
}

route {
        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 127.0.0.1 port = 1080
        proxyprotocol: socks_v5
        protocol: tcp udp
        extension: bind
}

Tradotto in italiano "redirigi tutto il traffico TCP e UDP verso il proxy SOCKS (supportante il protocollo versione 5 e l'estensione bind) che si trova in ascolto sulla macchina locale al numero di porta 1080, fatta eccezione per connessioni verso porte 53 (dns), 80 e 443, che seguiranno la strada normale" :)

Una volta lanciato ssh come visto precedentemente, andate in Centro di controllo->Internet e Rete->Proxy, selezionale la scheda SOCKS, abilitate il supporto SOCKS e selezionate "Dante" tra le scelte possibili. Come vi avvertirà una finestra popup le nuove impostazioni avranno effetto solo per le applicazioni avviate da quel momento (e solo per le applicazioni KDE!)