Benvenuto su Pop3-smtp.com
Tutti i parametri per la configurazione delle email

SSH

Smtp Pop3

SSH (Secure SHell, shell sicura) è un protocollo che permette di stabilire una sessione remota cifrata ad interfaccia a linea di comando con un altro host. Il client SSH ha una interfaccia a linea di comando simile a quella di telnet e rlogin, ma l'intera comunicazione (ovvero sia l'autenticazione che la sessione di lavoro) avviene in maniera cifrata. Per questo motivo, SSH è diventato uno standard di fatto per l'amministrazione remota di sistemi unix e di dispositivi di rete, rendendo obsoleto il protocollo telnet, giudicato troppo pericoloso per la sua mancanza di protezione contro le intercettazioni. Il client ed il server SSH sono installati, o è possibile installarli, su molte versioni di UNIX, tra cui Linux e Mac OS X, ma anche su Microsoft Windows, ed è inoltre disponibile come strumento di amministrazione su alcuni apparati di rete

La sintassi su sistemi UNIX-like è la seguente:

 % ssh [opzioni] nomeutente@host [comando]

dove con "%" si intende il prompt della shell utilizzata.

Port forwarding

SSH permette di realizzare dei tunnel criptati, che permettono di trasportare sessioni TCP arbitrarie all'interno della connessione criptata, permettendo di proteggere da intercettazione protocolli non sicuri, o di aggirare limitazioni di routing. Questa funzionalità è detta port forwarding, e permette di aprire una socket TCP sul client SSH (local port forwarding) o sul server (remote port forwarding). Le connessioni ricevute su questa porta vengono inoltrate dall'altro capo della connessione SSH, verso un host e una porta specificata.

Ad esempio, con questo comando ci si collega ad host1, inoltrando la sua porta 22 alla porta 10022 di host2

 ssh host1 -L 10022:host2:22

Mentre questa connessione è attiva, collegandosi alla porta 10022 di host2 si viene rediretti verso la porta 22 di host1.

X forwarding

Il port forwarding è utile anche per trasportare applicazioni X Window attraverso una connessione SSH. SSH imposta anche automaticamente le opportune variabili d'ambiente, in modo che le applicazioni X lanciate da un terminale remoto vengano visualizzate sul display da cui è stata avviata la connessione. L'X forwarding dal lato client deve essere abilitato passando l'opzione "-X" mentre dal lato server va modificato il file di configurazione /etc/ssh/sshd_config abilitando la direttiva X11Forwarding (ricordatevi di riavviare il server una volta apportata la modifica al file di configurazione).

Esempio di uso del port forwarding

Il port forwarding è utile ad esempio per fare assistenza remota a macchine prive di un sistema di gestione remota sicuro. È possibile creare un tunnel sicuro tra una porta del client e una porta del server remoto o di qualsiasi terza macchina dietro al sever remoto, a patto che la macchina SERVER SSH abbia abilitato il forwarding. Questo è normalmente possibile senza installare nessun pacchetto aggiuntivo.

Ad esempio, nel seguente scenario

 CLIENT --[rete insicura]--> ssh server --[rete sicura]--> TERZA MACCHINA

Se vogliamo utilizzare un desktop remoto sulla terza macchina basta che ci connettiamo al server ssh includendo un tunnel tra una porta locale della macchina dove lavoriamo e la porta 3389 della TERZA MACCHINA. Dopo di che basterà avviare il client RDP e connettersi a localhost:(porta scelta). Il client ssh locale stabilirà una connessione criptata con il server, creerà un tunnel all'interno di questa connessione criptata, ed invierà la connessione RDP su questo tunnel. Il server a sua volta stabilirà una normale sessione TCP con la terza macchina sulla porta richiesta. Come risultato, il client RDP verrà messo in comunicazione con la terza macchina. La connessione tra ssh server e terza macchina non sarà criptata, per cui è opportuno che la comunicazione tra queste due macchine non sia a rischio di intercettazione. La terza macchina vedrà la connessione TCP provenire dal server ssh invece che dal client.

Meccanismi di autenticazione del client

Esistono principalmente due metodi di autenticazione per controllare l'accesso ad un server ssh:

username/password

L'utente fornisce un nome utente ed una password, che vengono validati dal server. Questo scambio avviene all'interno di un canale cifrato, per cui non è a rischio di intercettazione.

Procedura:

1. A ==> B: SSH_MSG_USERAUTH_REQUEST, pappy, ssh-userauth, keyboard-interactive

2. B ==> A: SSH_MSG_USERAUTH_INFO_REQUEST, pappy, password-authentication, 1, “Enter Password”

3. A ==> B: SSH_MSG_USERAUTH_INFO_RESPONSE, 1, “love”

4. B ==> A: SSH_MSG_USERAUTH_SUCCESS.

chiave pubblica

Questo metodo di autenticazione è basato sulla crittografia asimmetrica. Per utilizzarlo l'utente genera una coppia di chiavi. La chiave pubblica è copiata sul server, tipicamente in un apposito file nella home directory dell'utente; la chiave privata deve essere conservata dall'utente, ed è bene che sia protetta con una parola chiave (passphrase). Nella fase di accesso, il client ssh prova al server di essere in possesso della chiave privata, e in caso di successo viene consentito l'accesso. In questo modo, all'utente non è richiesto di fornire la propria password ad ogni connessione.

Autenticazione del Server

SSH prevede anche la verifica dell'autenticità del server. Questo serve ad evitare che un utente maligno "impersoni" il server, facendosi fornire le credenziali dell'utente (attacco man in the middle). A questo scopo, per ciascun server viene generata una coppia di chiavi asimmetriche. La chiave privata rimane sul server. La chiave pubblica deve essere installata sui client. Quando un client si collega ad un server di cui conosce la chiave pubblica, verifica che il server sia ancora in possesso della chiave privata. Se questa verifica fallisce, la connessione viene abbattuta, evitando di fornire credenziali al server. Nella pratica, quando ci si collega ad un server per la prima volta, il client chiede se si vuole accettare la chiave pubblica di questo server, e se l'utente risponde positivamente memorizza questa chiave e prosegue nella connessione. Alle connessioni successive con lo stesso server, il client ne verifica l'autenticità, e in caso la chiave privata non corrisponda impedisce di proseguire la connessione.