OpenSSH

From zeroincombenze
Jump to: navigation, search
Tb arrow up.jpg Lang english.png


OpenSSH SSH è stato progettato per sostituire Telnet e gli altri protocolli di accesso non sicuri, quali ad esempio rsh, rexec e , ftp , che tramsettonon in chiaro anche le informazioni delicate come le password, rendendo i collegamenti suscettibili di interecettazione e analisi. La crittografica usata da SSH permette di scambiare informazioni confidenziali in modo sicuro anche su una rete insicura come Internet.

Il 19 ottobre 2015, Microsoft ha annunciato che OpenSSH sarà supportato nativamente dai sistemi operativi Windows attraverso PowerShell.


Programmi rimpiazzati

Funzione Comando SSH Esempio Comando insicuro (Linux) Esempio Comando insicuro (OpenVMS) Esempio Comando insicuro (Windows) Esempio
Accesso interattivo shell ssh ssh user@host telnet telnet host telnet telnet host telnet telnet host
Accesso interattivo TCP/IP ssh ssh user@host rlogin rlogin host rlogin rlogin host [1]
Copia file scp scp user@host:srcpath localpath rcp rcp user@host:srcpath localpath rcp[2] rcp user@host:srcpath localpath copy[3] copy \\host\srcpath localpath[4]
Copia file sftp sftp user@host ftp ftp user@host ftp ftp /user=user host ftp ftp /u:user host


Modalità di accesso

Il protocollo OpenSSH prevede, per accedere da un host ad un altro, tre modalità:

  • Password
  • Kerberos/GSSAPI
  • Coppia di chiavi pubblica/privata

L'accesso con password o con Kerberos segue il tradizionale schema usato da telnet o rlogin con richiesta password per l'autenticazione ma rispetto a questi protocolli, i dati sono crittografati.

L'utilizzo di una coppia di chiavi simmetrice, una copia privata ed una pubblica permette l'accesso senza autenticazione interattiva. La chiave privata è nel client, quella pubblica in ogni server a cui può accedere.


Flusso di autenticazione

  1. Il client verifica se il server è già stato autenticato cercando l'impronta (fingerprint) nel file locale dei server autenticati ~/.ssh/known_hosts
  2. Il client ed il server negoziano il protocollo di comunicazione, in ordine rsa V1, rsa V2 e dsa
    1. Il client invia la propria chiave pubblica criptata
    2. Il server decripta la chiave ricevuta e la confronta con quelle presenti nel file locale
  3. Con rsa V1 la chiave del client è in ~/.ssh/identity.pub
  4. Con rsa V2 la chiave del client è in ~/.ssh/id_rsa.pub
  5. Con dsa la chiave del cliente è in ~/.ssh/id_dsa.pub
  6. Il server cerca la corrispondenza in ~/.ssh/authorized_keys

Il client Linux può comportarsi in modo diverso in base al file di configurazione /etc/ssh/ssh_config.

Struttura dei file

Linux

/etc/ssh/moduli Contiene le chiavi per lo scambio dati con i siti di aggiornamento moduli
/etc/ssh/ssh_config File di configurazione con regole di accesso client ssh; usato se non esiste uno specifico file dell'utente ~/.ssh/ssh_config
/etc/ssh/sshd_config File di configurazione del servizio (demone) server ssh
/etc/ssh/ssh_host_dsa_key Chiave privata dsa predefinita del servizio ssh
/etc/ssh/ssh_host_dsa_key.pub Chiave pubblica dsa predefinita del servizio ssh
/etc/ssh/ssh_host_rsa_key Chiave privata rsa V2 predefinita del servizio ssh
/etc/ssh/ssh_host_rsa_key.pub Chiave pubblica rsa V2 predefinita del servizio ssh
/etc/ssh/ssh_host_key Chiave privata rsa V1 predefinita del servizio ssh
/etc/ssh/ssh_host_key.pub Chiave pubblica rsa V1 predefinita del servizio ssh
~/.ssh/authorized_keys Lista chiavi pubbliche di client esterni
~/.ssh/id_dsa_key Chiave privata dsa dell'utente
~/.ssh/id_dsa_key.pub Chiave pubblica dsa dell'utente; quando accede ad un server, una copia deve essere presente in remoto nel file ~/.ssh/authorized_keys
~/.ssh/id_rsa_key Chiave privata rsa V2 dell'utente
~/.ssh/id_rsa_key.pub Chiave pubblica rsa V2 dell'utente; quando accede ad un server, una copia deve essere presente in remoto nel file ~/.ssh/authorized_keys
~/.ssh/identity Chiave privata rsa V1 dell'utente
~/.ssh/identity.pub Chiave pubblica rsa V1 dell'utente; quando accede ad un server, una copia deve essere presente in remoto nel file ~/.ssh/authorized_keys
~/.ssh/known_hosts Lista delle impronte dei server a cui si ha avuto accesso per tutelarsi da eventuali attacchi man-in-the-middle


/etc/ssh/shosts.equiv File con lista degli host per i quali è ammessa l'autenticazione
/etc/ssh/known_hosts Lista chiavi pubbliche dell'utente degli host autorizzati. Il formato è diverso da quello per utente; prima di ogni chiave è presente la lista degli host (presenti in shosts.equiv) e il tipo di chiave.


Configurazione accesso Linux/Linux

  1. Su host client in locale generare una chiave
  2. Copiare la chiave pubblica nell'host remoto
  3. Nell'host remoto aggiungere la chiave pubblica nel file ~/.ssh/authorized_keys
  4. Ora è possibile eseguire il login senza password con ssh user@host-remoto


32px warning.jpg
Non usare lo stesso file di chiave pubbliche/private per utenti diversi e soprattutto per utente root o di sistema. Infatti la violazione di una chiave anche da un utente con minimi privilegi, comporterebbe l'accesso al sistema tramite superuser root o di sistema.


Generare una chiave ssh

Comando ssh-keygen in Linux

Il comando ssh-keygen permette di creare chiavi assimetrice per il trasporto di informazioni reversibili sicure.

Sono disponibili due protocolli di sicurezza:

  • rsa - chiavi variabili da 768, 1024 e 2048 (default) bit
  • dsa - chiave da 1024 bit

Generalmente si considera allo stesso livello di sicurezza una chiave dsa da 1024 bit e una chiave rsa da 2048 bit. Le chiavi rsa di dimensioni minori permetteno di sfruttare meno la CPU in situazioni in cui la sicurezza sia meno critica.


Il comando per creare un chiave rsa da da console è

ssh-keygen -t rsa -b 2048

Il file con la chiave privata si chiama ~/.ssh/id_rsa e quello con la chiave pubblica in ~/.ssh/id_rsa.pub


Il comando per creare un chiave dsa da da console è

ssh-keygen -t dsa

Il file con la chiave privata si chiama ~/.ssh/id_dsa e quello con la chiave pubblica in ~/.ssh/id_dsa.pub


32px warning.jpg
Il file contenente la chiave privata id_rsa oppure id_dsa non deve mai essere reso pubblico in quanto permette di violare l'accesso al sistema. Il sistema operativo verifica che tali file siano accessibili esclusivamente al proprietario. Anche l'invio del file tramite mail è da considerarsi reso pubblico e pertanto in violazione della sicurezza.


Copiare una chiave pubblica con ssh-copy-id (utente abilitato)

Questo procedimento può essere usato quando:

  1. Tutte le operazioni sono eseguite in locale dal client
  2. Il server ammette autenticazione tramite password
  3. Il client conosca le credenziali di accesso al server

Dall'host in cui si è eseguito ssh-keygen copiare la chiave pubblica con uno dei seguenti comandi:

ssh-copy-id -i ~/.ssh/id_rsa.pub host-remoto        # se copia rsa
ssh-copy-id -i ~/.ssh/id_dsa.pub host-remoto        # se copia dsa
# Test accesso
ssh host-remoto

Il comando ssh-copy-id copia il file e sul server imposta gli attributi corretti e modifica il file authorized_keys


Copiare una chiave pubblica con ssh-copy-id (utente disabilitato)

Questo procedimento può essere usato quando:

  1. Le operazioni sono eseguite in parte nel client e in parte nel server
  2. Il server non ammette autenticazione tramite password
  3. Si conosca le credenziali di accesso al server o sia possibile impostarle

Sel l'utente su host-remoto non è abilitato al login occorre trasferire il file tramite utente amministratore oppure seguire le seguenti istruzioni con molta attenzione e cautela.

Accedere con un'altra console sull'host-remoto tramite utente amministratore.

Sull'host-remoto verificare che l'utente sia effettivamente un utente con login disabilitato con il comando (sostituendo utente con il nome esatto dell'utente)

grep utente /etc/shadow

Lo spazio password deve iniziare con il simbolo "!" (punto esclamativo). Vedere Capire /etc/shadow

32px warning.jpg
Attenzione! Prestare estrema attenzione alle istruzioni che seguono che aprono una temporanea falla nella sicurezza.


Se l'utente è senza password occorre abilitare al login con una password temporanea con i comandi (sostituendo utente con il nome esatto dell'utente)

passwd -uf utente   # Sblocca utente !!Utente senza password!!
passwd utente       # Imposta password temporanea


Se l'utente ha già una password è sufficiente abilitare il login con il comando (sostituendo utente con il nome esatto dell'utente)

passwd -u utente    # Sblocca utente


A questo, dalla sessione dell'host in cui è stata generata la chiave eseguire il comando ssh-copy-id come spiegato in precedenza nel paragrafo "Copiare una chiave pubblica con ssh-copy-id (utente abilitato)".

Ora ritornare sulla sessione di console dell'host-remoto per ripristinare la situazione originale. Occorre ripristinare il lock rimosso dall'utente.


Se l'utente era senza password ripristinare con i comandi (sostituendo utente con il nome esatto dell'utente)

passwd -d utente    # Cancella password temporanea  !!Utente senza password!!
passwd -l utente    # Blocca nuovamente utente
grep utente /etc/shadow


Se l'utente ha già una password è sufficiente ribloccare il login con il comando (sostituendo utente con il nome esatto dell'utente)

passwd -l utente    # Blocca nuovamente utente
grep utente /etc/shadow


Infine provare nuovamente la funzionalità con il comando

ssh host-remoto

Copiare una chiave pubblica manualmente

Il comando ssh-copy-id, copia il file, imposta gli attributi corretti e modifica il file authorized_keys

Se il file è copiato manualmente occorre eseguire le stesse operazioni. I passi sono:

Da host server in locale:

mkdir ~/.ssh && chmod 700 ~/.ssh                           #crea directory .ssh su server
scp user@client-remoto:~/.ssh/id_rsa.pub .ssh/KEY.pub      # se copia rsa da host-remoto
scp user@client-remoto:~/.ssh/id_dsa.pub .ssh/KEY.pub      # se copia dsa da host-remoto
cd ~/.ssh
cat authorized_keys KEY.pub > new_keys                     # Accoda chiave pubblica
mv authorized_keys __old_keys                              # Salva l'attuale file
mv new_keys authorized_keys                                # Assegna nuovo nome file autorizzazioni
chmod 600 authorized_keys                                  # Imposta attributi corretti
rm ~/.ssh/KEY.pub                                          # Cancella file temporaneo
rm __old_keys                                              # Cancella vecchia copia file autorizzazioni

Le istruzioni di copia possono essere sostituite con le seguenti da host client in locale:

scp ~/.ssh/id_rsa.pub user@host-remoto:.ssh/KEY.pub        # se copia rsa da host client
scp ~/.ssh/id_dsa.pub user@host-remoto:.ssh/KEY.pub        # se copia dsa da host client


Configurazione accesso Windows/Linux

Nel caso di accesso da Windows, è necessario gestire le chiavi su PC; sono utilizzati i programmi della famiglia putty.

Sono possibili due modi:

  • Generazione chiave in autonomia su Windows
  • Generazione chiave su server Linux

Il primo metodo è quello consigliato in quanto più sicuro ma è necessario avere già un accesso al server (via ftp o via telnet). Il secondo, la generazione della chiave su server Linux è da considerasi un metodo di emergenza per accedere con un emulatore terminale (esempio putty) senza supporto dello strato di comunicazione, esempio pageant

32px warning.jpg
La struttura della chiave pubblica generata da puttygen non è compatibile con un semplice copia e incolla su Linux.


Metodo 1: generazione chiave su Windows

La generazione della chiave in modo autonomo su Linux, è la modalità di gestione più sicura ma che richiede un po' di tempo.

Occorre creare il file di chiave privata .ppk gestito tramite puttygen

I passi sono

  1. Creare chiave privata su PC
  2. Trasmettere la chiave pubblica sul server Linux
  3. Attivare lo strato di comunicazione
  4. Effettuare test accesso


Creare la chiave privata

Usare puttygen

Effettuare l'operazione Generate selezionando il tipo di chiave SSH-2 RSA o SSH-2 DSA e prestare attenzione alla lunghezza chiave in bit come precedentemente esposto.

Poiché si tratta di conversione di chiave privata, l'operazione di conversione richiede un po' di tempo.

Salvare la chiave privata, preferibilmente in una cartella riservata, esempio ssh key.

Si consiglia, all'interno della cartella, di assegnare alle chiavi pubbliche il nome con prefisso server e utente, esempio server-dev utente id_rsa.ppk in modo da distinguere gli accesi ai diversi server o servizi.

Non salvare la chiave pubblica, perché puttygen utilizza un formato diverso da quello usato da OpenSSH di Linux.


Trasmettere la chiave pubblica su server Linux

Seguire le istruzioni del paragrafo 'Copiare una chiave pubblica manualmente


Attivare lo strato di comunicazione

Per attivare lo strato di comunicazione usare il comando pageant che serve sia all'emulatore terminale putty che ai trasferimento via ftp. Caricare la copia della chiave privata .ppk generata.

Le chiavi che sono caricate all'avvio di pageant, sono fornite su riga di comando. Utilizzare un file link di Windows per elencare le chiavi da caricare all'avvio.

Effettuare test di accesso

Effettuare test di accesso tramite putty


Metodo 2: importazione chiave da Linux

32px warning.jpg
Questo metodo prevede la generazione della della chiave sul server Linux ed il trasferimento della stessa nel PC. La geneazione della chiave sul server Linux è più veloce che su PC ma questo metodo è insicuro in quanto prevede l'invio di una chiave privata dal server Linux al PC.

I passi sono

  1. Generare chiave privata ssh
  2. Copiare chiave pubblica
  3. Copiare la chiave privata su PC
  4. Convertire la chiave pubblica in un formato utilizzabile da PC
  5. Attivare lo strato di comunicazione


Generare una chiave ssh

Seguire le istruzione del precedente paragrafo Generare una chiave ssh


Copiare una chiave pubblica

Connettersi con la console all'host remoto

# Se non esiste la directory .ssh su host-remoto:
mkdir ~/.ssh && chmod 700 ~/.ssh
cd ~/.ssh
# in caso di chiave rsa
cat id_rsa.pub authorized_keys > new_keys # Accoda chiave pubblica rsa
# oppure in caso di chiave dsa
cat id_dsa.pub authorized_keys > new_keys # Accoda chiave pubblica dsa
# cont
mv authorized_keys __old_keys             # Salva l'attuale file
mv new_keys authorized_keys               # Assegna nuovo nome file autorizzazioni
rm __old_keys                             # Cancella vecchia copia file autorizzazioni


Copiare la chiave privata

32px warning.jpg
Copiare tramite ftp o meglio sftp il file della chiave privata id_rsa o id_dsa su PC locale. Si consiglia di creare una cartella riservata a queste chiavi, esempio ssh key.

Si consiglia, all'interno della cartella, di assegnare alle chiavi pubbliche il nome con prefisso server e utente, esempio server-dev utente id_rsa


Convertire la chiave privata

Occorre convertire il file di chiave privata in un file .ppk gestito tramite puttygen

Effettuare l'operazione ConvertionsImport Key selezionando il tipo di chiave SSH-2 RSA o SSH-2 DSA e prestare attenzione alla lunghezza chiave in bit come precedentemente esposto. Selezionare il file con la chiave privata, copiato nel precedente paragrafo, esempio server-dev utente id_rsa.

Effettuate l'operazione [Save Private key]. Importante impostare il commento per riconoscere la chiave in futuro e evitare la passphrase se è necessario effettuare connessioni automatiche.

Alla fine salvare la chiave.

Attivare lo strato di comunicazione

Per attivare lo strato di comunicazione usare il comando pageant che serve sia all'emulatore terminale putty che ai trasferimento via ftp. Caricare la copia della chiave privata .ppk generata.


Effettuare test di accesso

Effettuare test di accesso tramite putty


H notes.png

Note

  1. Windows non ha emulatori di terminale nativi
  2. OpenVMS utilizza nativamente DecNet per copiare in LAN
  3. Comando utilizzabile soltanto in LAN
  4. Lo stesso comando è usato in modo sicuro