SSH, SCP, SSHFS, SFTP e l’autenticazione a chiave pubblica

In principio erano telnet, rcp ed ftp.. al giorno d’oggi SSH, scp e SFTP! In pratica il modo standard per collegarsi ad un sistema remoto in maniera sicura (anche da windows usando Putty).

SSH e SCP

La sintassi è banale:

ssh nomeutente@nomeserver -p porta

(se la porta è quella standard, ovvero la 22, il parametro può essere omesso)

Al posto di rcp (remote copy) abbiamo scp (secure file copy) quindi:

scp nomefile utente@nomeserver:/percorso/dove/salvare/il/file

SSHFS

Particolarmente comoda è la possibilità di montare una partizione del server remoto per l’accesso diretto al filesystem: per questo è nato SSHFS.

La sintassi è la seguente:

sshfs utente@nomeserver:/directory/da/montare /punto/di/mount -o opzioni

in pratica è necessario prima creare un punto di mount (per esempio su debian e derivate si può creare una directory in /media) e poi lanciare il comando per montare il disco.

Nella realtà di tutti i giorni ci sono alcune opzioni aggiuntive che sono molto utili:

• allow_other : consente a tutti gli utenti di usare il mount
• idmap=user : converte in automatico l’id dell’utente locale con quello remoto
• workaround=rename : simula il rename con eliminazione e creazione del file nel caso di presenza di file nel disco di destinazione (migliora la compatibilità coi vari sistemi)
• uid=xx : imposta lo user id da usare per i files (rilevabile in /etc/passwd del server remoto)
• gid=xx : imposta il group id da usare per i files (rilevabile in /etc/passwd del server remoto)
• reconnect : ri-connessione automatica nel caso di perdita di connessione.

N.B. ogni singola opzione va preceduta da -o.

Il comando tipico diventa quindi:

sshfs -p porta utente@nomeserver:/directory/da/montare /punto/di/mount -o reconnect -o allow_other -o idmap=user -o uid=xx -o gid=xx -o workaround=rename

Da citare un’ulteriore opzione che può essere utile quando compare il fastidioso errore “connection reset by peer“: -o debug (o abbreviando -d). Questa opzione attiva la modalità debug che consentirà di evidenziare eventuali problemi.

SFTP

In principio si usava FTP che prevede due canali specifici (uno per i comandi e uno per il trasferimento dati). Il server è in ascolto sulla porta 21 e, una volta ricevuti i comandi di autenticazione, può partire il trasferimento dei dati che può essere di due tipi:

• attivo : il client sceglie una porta casuale e la comunica al server che fa il binding con la sua porta 20 quindi il trasferimento dal client può iniziare.
• passivo : il server predispone una porta causale (maggiore di 1023) e la comunica al client che può iniziare il trasferimento dati.

Il canale di trasferimento dei dati non è univoco per l’intera sessione (come quello dei comandi). Viene creato per ogni files da trasferire il che rende il tutto particolarmente non performante.

La pecca principale non erano certo le performance ma il fatto che la comunicazione non fosse sicura pertanto è nato FTP/S (FTP su protocollo SSL o TLS) che prevede due modalità:

• implicita : usa la porta 990 (di default) e un sistema di crittografia obsoleto ma retro compatibile con i server più vecchi.
• esplicita : usa la porta 21 e crittografa i dati usando SSL o TLS. In genere questa è la modalità da preferire.

Anche FTP/S non brilla di certo per performance visto che il meccanismo dei due canali ereditato da FTP è ancora attivo.

Per chiudere il cerchio è nato SFTP: più che una revisione di FTP e FTP/S un sistema di copia dei files basato su SSH quindi attivo su porta standard 22.

Diversamente da FTP e FTP/S non è prevista l’apertura di due canali distinti (uno per i comandi e l’altro per i dati) ma di un solo canale crittografato via TLS da usare per trasferimento di comandi e dati opportunamente crittografati (quindi intrinsecamente più sicuro e performante).

La sintassi di sftp è la seguente:

sftp -o Port=porta utente@nomeserver 

Nel caso si desideri l’uso di un cliente grafico (sopratutto se l’os in uso è windows) si può usare Filezilla che è in grado di gestire FTP, FTP/S e sftp.

Autenticazione con chiave pubblica

Per non dover ricordare gli accessi di ogni singola macchina o semplicemente per usare SSH, SSHFS, SCP e SFTP in maniera non interattiva (ad esempio all’interno di uno script) è possibile attivare l’autenticazione mediante chiave pubblica.

Il comando da lanciare è il seguente:

ssh-keygen

Saranno proposte le seguenti domande:

Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Se non avete necessità di creare la chiave in un percorso specifico e se non volete usare una passphrase basta premere tre volte invio ed è fatta.

Non avendo modificato il percorso di base in /home/user/.ssh/ saranno creati due files: id_rsa (chiave privata, da non mostrare a nessuno) e id_rsa.pub (chiave pubblica da diffondere liberamente).

A questo punto basta copiare la propria chiave pubblica sul server di destinazione con il seguente comando:

cat ~/.ssh/id_rsa.pub | ssh utente@nomeserver 'cat >> .ssh/authorized_keys'

oppure:

scp -P porta ~/.ssh/id_rsa.pub utente@nomeserver:~/.ssh/authorized_keys

Per testare il corretto funzionamento basta ora provare a collegarsi al server con il comando standard.Non dovrebbe essere richiesta alcuna password. Se qualcosa non va a buon fine ricordate che nella home directory del utente remoto deve esistere la cartella .ssh con permessi 755 contenente il file authorized_keys con permessi 644.

N.B. : il discorso usare / non usare passphrase è una questione di scelte personali. Non usandola l’accesso è veloce e pratico (non viene richiesto nulla) però è anche meno sicuro. Se la nostra chiave fosse rubata e non vi fosse passphrase il ladro avrebbe accesso a tutte le macchine sulle quali la chiave è presente… valutate con attenzione!