110.3 Lezione 1

Certificazione:

LPIC-1

Versione:

5.0

Argomento:

110 Sicurezza

Obiettivo:

110.3 Proteggere i dati con la crittografia

Lezione:

1 di 2

Introduzione

Proteggere i dati con la crittografia è di fondamentale importanza in molti aspetti dell’amministrazione di sistema di oggi: ancora di più quando si tratta di accedere ai sistemi in remoto. Al contrario di soluzioni insicure come telnet, rlogin o FTP, il protocollo SSH (Secure Shell) è stato progettato con in mente la sicurezza. Utilizzando la crittografia a chiave pubblica autentica sia gli host sia gli utenti e cripta tutti i successivi scambi di informazioni. Inoltre, SSH può essere usato per stabilire port tunnel, che — tra le altre cose — permette a un protocollo non criptato di trasmettere dati su una connessione SSH criptata. L’attuale versione raccomandata del protocollo SSH è la 2.0. OpenSSH, è un’implementazione libera e open source del protocollo SSH.

Questa lezione tratterà la configurazione di base del client OpenSSH così come il ruolo delle chiavi host del server OpenSSH. Verrà anche discusso il concetto di tunnel di porte SSH. Useremo due macchine con la seguente configurazione:

Ruolo Macchina OS Indirizzo IP Nome Host Utente

Client

Debian GNU/Linux 10 (buster)

192.168.1.55

debian

carol

Server

openSUSE Leap 15.1

192.168.1.77

halof

ina

Configurazione e Uso di Base del Client OpenSSH

Sebbene il server e il client OpenSSH siano in pacchetti separati, puoi normalmente installare un metapacchetto che li installerà entrambi in una volta sola. Per stabilire una sessione remota con il server SSH si usa il comando ssh, specificando l’utente con cui ci si vuole connettere sulla macchina remota e l’indirizzo IP o l’hostname della macchina remota. La prima volta che ti connetti a un host remoto riceverai un messaggio come questo:

carol@debian:~$ ssh ina@192.168.1.77
The authenticity of host '192.168.1.77 (192.168.1.77)' can't be established.
ECDSA key fingerprint is SHA256:5JF7anupYipByCQm2BPvDHRVFJJixeslmppi2NwATYI.
Are you sure you want to continue connecting (yes/no)?

Dopo aver digitato sì e premuto Invio, ti verrà chiesta la password dell’utente remoto. Se è stata inserita con successo, ti verrà mostrato un messaggio di avvertimento e poi sarai connesso all’host remoto:

Warning: Permanently added '192.168.1.77' (ECDSA) to the list of known hosts.
Password:
Last login: Sat Jun 20 10:52:45 2020 from 192.168.1.4
Have a lot of fun...
ina@halof:~>

I messaggi sono abbastanza autoesplicativi: poiché era la prima volta che si stabiliva una connessione al server remoto 192.168.1.77, la sua autenticità non poteva essere verificata con nessun database. Così, il server remoto ha fornito un ECDSA key fingerprint della sua chiave pubblica (usando la funzione hash SHA256). Una volta accettata la connessione, la chiave pubblica del server remoto veniva aggiunta al database degli ospiti conosciuti, permettendo così l’autenticazione del server per le connessioni future. Questa lista di chiavi pubbliche di known hosts è conservata nel file known_hosts che si trova in ~/.ssh:

ina@halof:~> exit
logout
Connection to 192.168.1.77 closed.
carol@debian:~$ ls .ssh/
known_hosts

Sia .ssh che known_hosts sono stati creati dopo aver stabilito la prima connessione remota. ~/.ssh è la directory predefinita per la configurazione specifica dell’utente e le informazioni di autenticazione.

Note	Puoi anche usare `ssh` per eseguire solo un singolo comando sull’host remoto e poi tornare al tuo terminale locale (per esempio: eseguire `ssh ina@halof ls`).

Se stai usando lo stesso utente sia sull’host locale sia su quello remoto, non c’è bisogno di specificare il nome utente quando si stabilisce la connessione SSH. Per esempio: se sei loggato come utente carol su debian e vuoi connetterti a halof sempre come utente carol, devi semplicemente digitare ssh 192.168.1.77 o ssh halof (se il nome può essere risolto):

carol@debian:~$ ssh halof
Password:
Last login: Wed Jul  1 23:45:02 2020 from 192.168.1.55
Have a lot of fun...
carol@halof:~>

Ora supponi di stabilire una nuova connessione remota con un host che per caso ha lo stesso indirizzo IP di halof (una cosa comune se usate il DHCP nella vostra LAN). Sarai avvertito della possibilità di un attacco man-in-the-middle:

carol@debian:~$ ssh john@192.168.1.77
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:KH4q3vP6C7e0SEjyG8Wlz9fVlf+jmWJ5139RBxBh3TY.
Please contact your system administrator.
Add correct host key in /home/carol/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/carol/.ssh/known_hosts:1
  remove with:
  ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77"
ECDSA host key for 192.168.1.77 has changed and you have requested strict checking.
Host key verification failed.

Poiché non hai a che fare con un attacco man-in-the-middle, puoi tranquillamente aggiungere l’impronta della chiave pubblica del nuovo host a .ssh/known_hosts. Come indica il messaggio, puoi prima usare il comando ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77" per rimuovere la chiave offendente (in alternativa, potete andare per ssh-keygen -R 192.168.1.77 per cancellare tutte le chiavi appartenenti a 192.168.1.77 da ~/.ssh/known_hosts). Poi, sai in grado di stabilire una connessione al nuovo host.

Login Basato su Chiavi

Puoi impostare il tuo client SSH in modo che non fornisca alcuna password al momento del login, ma usi invece le chiavi pubbliche. Questo è il metodo preferito per connettersi a un server remoto via SSH, perché è molto più sicuro. La prima cosa da fare è creare una coppia di chiavi sulla macchina client. Per farlo, userai ssh-keygen con l’opzione -t specificando il tipo di crittografia che vuoi (Elliptic Curve Digital Signature Algorithm nel nostro caso). Poi, ti verrà chiesto il percorso in cui salvare la coppia di chiavi (~/.ssh/ è conveniente così come la posizione predefinita) e una passphrase. Mentre una passphrase è opzionale, è altamente raccomandato usarne sempre una.

carol@debian:~/.ssh$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/carol/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/carol/.ssh/id_ecdsa.
Your public key has been saved in /home/carol/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:tlamD0SaTquPZYdNepwj8XN4xvqmHCbe8g5FKKUfMo8 carol@debian
The key's randomart image is:
+---[ECDSA 256]---+
|      .          |
|     o .         |
|    = o o        |
|     B *         |
|    E B S o      |
|     o & O       |
|      @ ^ =      |
|     *.@ @.      |
|    o.o+B+o      |
+----[SHA256]-----+

Note	Quando si crea la coppia di chiavi, si può passare a `ssh-keygen` l’opzione `-b` per specificare la dimensione della chiave in bit (per esempio: `ssh-keygen -t ecdsa -b 521`).

Il comando precedente ha prodotto altri due file nella tua directory ~/.ssh:

carol@debian:~/.ssh$ ls
id_ecdsa  id_ecdsa.pub  known_hosts

id_ecdsa: Questa è la tua chiave privata.
id_ecdsa.pub: Questa è la tua chiave pubblica.

Note	Nella crittografia asimmetrica (o anche crittografia a chiave pubblica), la chiave pubblica e quella privata sono matematicamente legate l’una all’altra in modo tale che qualsiasi cosa sia criptata da una può essere decriptata solo dall’altra.

La prossima cosa che devi fare è aggiungere la tua chiave pubblica al file ~/.ssh/authorized_keys dell’utente con cui vuoi loggarti sull’host remoto (se la directory ~/.ssh non esiste già, dovrai prima crearla). Puoi copiare la tua chiave pubblica nel server remoto in diversi modi: usando una chiavetta USB, attraverso il comando scp - che trasferirà il file usando SSH - o prelevando con cat il contenuto della tua chiave pubblica e inserendolo in ssh come segue:

carol@debian:~/.ssh$ cat id_ecdsa.pub |ssh ina@192.168.1.77 'cat >> .ssh/authorized_keys'
Password:

Una volta che la chiave pubblica è stata aggiunta al file authorized_keys sull’host remoto, puoi affrontare due scenari quando cerchi di stabilire una nuova connessione:

Se non hai fornito una passphrase quando hai creato la coppia di chiavi, sarai loggato automaticamente. Anche se comodo, questo metodo può essere insicuro a seconda della situazione:
```
carol@debian:~$ ssh ina@192.168.1.77
Last login: Thu Jun 25 20:31:03 2020 from 192.168.1.55
Have a lot of fun...
ina@halof:~>
```
Se hai fornito una passphrase quando hai creato la coppia di chiavi, dovrai inserirla a ogni connessione come se fosse una password. Oltre alla chiave pubblica, questo metodo aggiunge un ulteriore livello di sicurezza sotto forma di passphrase e può — quindi — essere considerato più sicuro. Per quanto riguarda la comodità, tuttavia, è esattamente la stessa cosa che dover inserire una password ogni volta che si stabilisce una connessione. Se non usa una passphrase e qualcuno riesce a ottenere il tuo file chiave SSH privato, avrebbe accesso a ogni server su cui è installata la tua chiave pubblica.
```
carol@debian:~/.ssh$ ssh ina@192.168.1.77
Enter passphrase for key '/home/carol/.ssh/id_ecdsa':
Last login: Thu Jun 25 20:39:30 2020 from 192.168.1.55
Have a lot of fun...
ina@halof:~>
```

C’è però un modo che combina sicurezza e convenienza: usare l’agente di autenticazione SSH (ssh-agent). L’agente di autenticazione ha bisogno di creare una propria shell e terrà le tue chiavi private per l’autenticazione a chiave pubblica in memoria per il resto della sessione. Vediamo un po' più in dettaglio come funziona:

Usa ssh-agent per avviare una nuova Shell Bash:

carol@debian:~/.ssh$ ssh-agent /bin/bash
carol@debian:~/.ssh$

Usa il comando ssh-add per aggiungere la tua chiave privata in un’area sicura della memoria. Se hai fornito una passphrase quando hai generato la coppia di chiavi, il che è raccomandato per una maggiore sicurezza, ti verrà richiesta:
```
carol@debian:~/.ssh$ ssh-add
Enter passphrase for /home/carol/.ssh/id_ecdsa:
Identity added: /home/carol/.ssh/id_ecdsa (carol@debian)
```
Una volta che la tua identità è stata aggiunta, potrai accedere a qualsiasi server remoto su cui sia presente la chiave pubblica senza dover digitare nuovamente la tua passphrase. È pratica comune sui desktop moderni eseguire questo comando all’avvio del computer, in quanto rimarrà in memoria fino allo spegnimento del computer (fino a quando la chiave non venga scaricata manualmente).

Completiamo questa sezione elencando i quattro tipi di algoritmi a chiave pubblica che possono essere specificati con ssh-keygen:

RSA: Prende il nome dai suoi creatori Ron Rivest, Adi Shamir e Leonard Adleman e fu pubblicato nel 1977. È considerata sicura e ancora oggi ampiamente utilizzata. La sua dimensione minima della chiave è di 1024 bit (l’impostazione predefinita è 2048).
DSA: Il Digital Signature Algorithm si è dimostrato insicuro ed è stato deprecato a partire da OpenSSH 7.0. Le chiavi DSA devono essere lunghe esattamente 1024 bit.
ecdsa: L'Elliptic Curve Digital Signature Algorithm è un miglioramento del DSA e quindi considerato più sicuro. Utilizza la crittografia a curva ellittica. La lunghezza della chiave ECDSA è determinata da una delle tre possibili dimensioni della curva ellittica in bit: 256, 384 o 512.
ed25519: È un’implementazione di EdDSA — Edwards-curve Digital Signature Algorithm — che usa la più forte curva 25519. È considerata la più sicura di tutte. Tutte le chiavi Ed25519 hanno una lunghezza fissa di 256 bit.

Note	Se invocato senza alcuna specificazione `-t`, `ssh-keygen` genererà per default una coppia di chiavi `RSA`.

Il Ruolo delle Chiavi Host del Server OpenSSH

La directory di configurazione globale per OpenSSH si trova nella directory /etc:

halof:~ # tree /etc/ssh
/etc/ssh
├── moduli
├── ssh_config
├── ssh_host_dsa_key
├── ssh_host_dsa_key.pub
├── ssh_host_ecdsa_key
├── ssh_host_ecdsa_key.pub
├── ssh_host_ed25519_key
├── ssh_host_ed25519_key.pub
├── ssh_host_rsa_key
├── ssh_host_rsa_key.pub
└── sshd_config

0 directories, 11 files

Oltre a moduli e ai file di configurazione per il client (ssh_config) e il server (sshd_config), troverai quattro coppie di chiavi — una coppia di chiavi per ogni algoritmo supportato — che vengono create quando viene installato il server OpenSSH. Come già notato, il server usa queste host key per identificarsi verso i client. Il modello di nome è il seguente:

Chiavi private: ssh_host_ prefix + algorithm + key suffix (es.: ssh_host_rsa_key)
Chiavi pubbliche (o impronte digitali di chiavi pubbliche): ssh_host_ prefix + algorithm + key.pub suffix (es.: ssh_host_rsa_key.pub)

Note	Un’impronta digitale (fingerprint) viene creata applicando una funzione di hash crittografica a una chiave pubblica. Poiché le impronte digitali sono più corte delle chiavi a cui si riferiscono, sono utili per semplificare alcuni compiti di gestione delle chiavi.

I permessi sui file contenenti le chiavi private sono 0600 o -rw-------: leggibili e scrivibili solo dal proprietario (root). D’altra parte, tutti i file delle chiavi pubbliche sono leggibili anche dai membri del gruppo del proprietario e da tutti gli altri (0644 o -rw-r—r--):

halof:~ # ls -l /etc/ssh/ssh_host_*
-rw------- 1 root root 1381 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key
-rw-r--r-- 1 root root  605 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key.pub
-rw------- 1 root root  505 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r-- 1 root root  177 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key.pub
-rw------- 1 root root  411 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key
-rw-r--r-- 1 root root   97 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key.pub
-rw------- 1 root root 1823 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  397 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key.pub

È possibile visualizzare le impronte digitali delle chiavi passando a ssh-keygen l’opzione -l. Devi anche fornire il -f per specificare il percorso del file delle chiavi:

halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)
halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)

Per visualizzare l’impronta della chiave e la sua random art, basta aggiungere -v nel seguente modo:

halof:~ # ssh-keygen -lv -f /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)
+--[ED25519 256]--+
|              +oo|
|             .+o.|
|        .    ..E.|
|         + .  +.o|
|        S +  + *o|
|          ooo Oo=|
|     . . . =o+.==|
|      = o =oo o=o|
|     o.o +o+..o.+|
+----[SHA256]-----+

Tunnel SSH

OpenSSH dispone di una funzione di inoltro molto potente per cui il traffico su una porta sorgente viene fatto transitare - e criptato - attraverso un processo SSH che poi lo reindirizza a una porta su un host di destinazione. Questo meccanismo è noto come port tunnelling o port forwarding e ha importanti vantaggi tra i quali:

Permette di bypassare i firewall per accedere alle porte di host remoti.
Permette l’accesso dall’esterno a un host della rete privata.
Fornisce la crittografia per tutti gli scambi di dati.

In parole povere, possiamo distinguere tra tunnelling di porte locali e remote.

Tunnel Locale di Porta

Si definisce localmente una porta per inoltrare il traffico all’host di destinazione attraverso il processo SSH che si trova nel mezzo. Il processo SSH può essere eseguito sull’host locale o su un server remoto. Per esempio, se per qualche ragione volessi creare un tunnel per una connessione a www.gnu.org attraverso SSH usando la porta 8585 sulla tua macchina locale, faresti qualcosa del genere:

carol@debian:~$ ssh -L 8585:www.gnu.org:80 debian
carol@debian's password:
Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
(...)
Last login: Sun Jun 28 13:47:27 2020 from 127.0.0.1

La spiegazione è la seguente: con l’opzione -L, specifichiamo la porta locale 8585 per connetterci alla porta http 80 su www.gnu.org usando il processo SSH in esecuzione su debian — il nostro localhost. Avremmo potuto scrivere ssh -L 8585:www.gnu.org:80 localhost con lo stesso effetto. Se ora usi un browser web per andare su http://localhost:8585, sarai inoltrato a www.gnu.org. Per scopi dimostrativi, useremo lynx (il "classico" browser web in modalità testo):

carol@debian:~$ lynx http://localhost:8585
(...)
  * Back to Savannah Homepage
     * Not Logged in
     * Login
     * New User
     * This Page
     * Language
     * Clean Reload
     * Printer Version
     * Search
     * _
(...)

Se avessi voluto fare la stessa identica cosa, ma connettendoti tramite un processo SSH in esecuzione su halof, avresti invece proceduto in questo modo:

carol@debian:~$ ssh -L 8585:www.gnu.org:80 -Nf ina@192.168.1.77
Enter passphrase for key '/home/carol/.ssh/id_ecdsa':
carol@debian:~$
carol@debian:~$ lynx http://localhost:8585
(...)
  * Back to Savannah Homepage
     * Not Logged in
     * Login
     * New User
     * This Page
     * Language
     * Clean Reload
     * Printer Version
     * Search
     * _
(...)

È importante notare tre dettagli nel comando:

Grazie all’opzione -N non abbiamo fatto il login su halof ma abbiamo invece fatto il port forwarding.
L’opzione -f ha comunicato a SSH di funzionare in background.
Abbiamo specificato l’utente ina per fare l’inoltro: ina@192.168.1.77.

Tunnel Remoto di Porta

Nel tunneling remoto delle porte (o reverse port forwarding) il traffico che arriva su una porta del server remoto viene inoltrato al processo SSH in esecuzione sul tuo host locale, e da lì alla porta specificata sul server di destinazione (che potrebbe anche essere la tua macchina locale). Per esempio, diciamo che vuoi permettere a qualcuno al di fuori della tua rete di accedere al server web Apache in esecuzione sul tuo host locale attraverso la porta 8585 del server SSH in esecuzione su halof (192.168.1.77). Procederesti con il seguente comando:

carol@debian:~$ ssh -R 8585:localhost:80 -Nf ina@192.168.1.77
Enter passphrase for key '/home/carol/.ssh/id_ecdsa':
carol@debian:~$

Ora chiunque stabilisca una connessione con halof sulla porta 8585 vedrà la homepage predefinita di Apache2 di Debian:

carol@debian:~$ lynx 192.168.1.77:8585
(...)
                                                                 Apache2 Debian Default Page: It works (p1 of 3)
   Debian Logo Apache2 Debian Default Page
   It works!

   This is the default welcome page used to test the correct operation of the Apache2 server after
   installation on Debian systems. If you can read this page, it means that the Apache HTTP server
   installed at this site is working properly. You should replace this file (located at
   /var/www/html/index.html) before continuing to operate your HTTP server.
(...)

Note	C’è un terzo tipo, più complesso, di inoltro delle porte che esula dallo scopo di questa lezione: l'inoltro dinamico delle porte. Invece di interagire con una singola porta, questo tipo di inoltro utilizza varie comunicazioni TCP su una serie di porte.

Tunnel X11

Ora che hai capito i tunnel di porta, completiamo questa lezione discutendo il tunnelling di X11 (conosciuto anche come X11forwarding). Attraverso un tunnel X11, l'X Window System sull’host remoto viene inoltrato alla macchina locale. Per questo, devi solo passare a ssh l’opzione -X:

carol@debian:~$ ssh -X ina@halof
...

Ora puoi lanciare un’applicazione grafica come il browser web firefox con il seguente risultato: l’applicazione verrà eseguita sul server remoto, ma la sua visualizzazione verrà inoltrata al tuo host locale.

Se invece avvii una nuova sessione SSH con l’opzione -x, X11forwarding sarà disabilitato. Prova ad avviare firefox ora e otterrai un errore come il seguente:

carol@debian:~$ ssh -x ina@halof
carol@192.168.0.106's password:
(...)
ina@halof:~$ firefox

(firefox-esr:1779): Gtk-WARNING **: 18:45:45.603: Locale not supported by C library.
	Using the fallback 'C' locale.
Error: no DISPLAY environment variable specified

Note	Le tre direttive di configurazione relative al port forwarding locale, al port forwarding remoto e al forwarding X11 sono rispettivamente `AllowTcpForwarding`, `GatewayPorts` e `X11Forwarding`. Per maggiori informazioni, digitare `man ssh_config` e/o `man sshd_config`.

Esercizi Guidati

Dopo aver eseguito un accesso come utente sonya sulla macchina client, esegui i seguenti compiti SSH sul server remoto halof:
- Esegui il comando per elencare il contenuto di ~/.ssh come utente serena sull’host remoto; poi torna al tuo terminale locale.
- Accedi come utente serena sull’host remoto.
- Accedi come utente sonya sull’host remoto.
- Cancella tutte le chiavi appartenenti a halof dal tuo file locale ~/.ssh/known_hosts.
- Sulla tua macchina client, crea una coppia di chiavi ecdsa da 256 bit.
- Sulla tua macchina client, crea una coppia di chiavi ed25519 da 256 bit.
Metti i seguenti passi nel giusto ordine per stabilire una connessione SSH usando l’agente di autenticazione SSH:
- Sul client, avvia una nuova shell Bash per l'authentication agent con ssh-agent /bin/bash.
- Sul client, crea una coppia di chiavi usando ssh-keygen.
- Sul client, aggiungi la tua chiave privata in un’area sicura della memoria con ssh-add.
- Aggiungi la chiave pubblica del client al file ~/.ssh/authorized_keys dell’utente con cui vuoi effettuare il login sull’host remoto.
- Se non esiste già, crea il file ~/.ssh per l’utente con cui volete fare il login sul server.
- Connettiti al server remoto.
  
  L’ordine corretto è:
  
  Passo 1:
  
  Passo 2:
  
  Passo 3:
  
  Passo 4:
  
  Passo 5:
  
  Passo 6:
Per quanto riguarda il port forwarding, quale opzione e direttiva si usa per i seguenti tipi di tunnel:

Tipo di Tunnel Opzioni Direttiva

Local

Remote o Reverse

X
Supponiamo che tu digiti il comando ssh -L 8888:localhost:80 -Nf ina@halof nel terminale della tua macchina client. Sempre sulla macchina client, punta un browser a http://localhost:8888. Che cosa ottieni?

Esercizi Esplorativi

Per quanto riguarda le direttive di sicurezza SSH:
- Quale direttiva è usata in /etc/ssh/sshd_config per abilitare i login di root:
- Quale direttiva useresti in /etc/ssh/sshd_config per accettare connessioni SSH solo da un account locale :
Quando si usa lo stesso utente sia sul client sia sul server, quale comando ssh si può usare per trasferire la chiave pubblica del client sul server in modo da poter effettuare il login tramite autenticazione a chiave pubblica?
Crea due tunnel di porte locali in un unico comando che inoltra le porte locali non privilegiate 8080 e 8585 attraverso il server remoto halof a rispettivamente i siti web www.gnu.org e www.melpa.org. Usa l’utente ina sul server remoto e non dimenticare di usare le opzioni -Nf:

Sommario

In questa lezione abbiamo discusso di OpenSSH 2, che usa il protocollo Secure Shell per criptare le comunicazioni tra server e client. Hai imparato:

come accedere a un server remoto.
come eseguire comandi a distanza.
come creare coppie di chiavi.
come stabilire login basati su chiavi.
come usare l'authentication agent per una maggiore sicurezza e comodità.
gli algoritmi a chiave pubblica supportati da OpenSSH: RSA, DSA, ecdsa, ed25519.
il ruolo delle chiavi host OpenSSH.
come creare tunnel di porte: locale, remoto e X.

I seguenti comandi sono stati discussi in questa lezione:

ssh: Accede o esegue comandi su una macchina remota.
ssh-keygen: Genera, gestisce e converte le chiavi di autenticazione.
ssh-agent: Agente di autenticazione OpenSSH.
ssh-add: Aggiunge identità a chiave privata all’agente di autenticazione.

Risposte agli Esercizi Guidati

Dopo aver eseguito un accesso come utente sonya sulla macchina client, esegui i seguenti compiti SSH sul server remoto halof:
- Esegui il comando per elencare il contenuto di ~/.ssh come utente serena sull’host remoto; poi torna al tuo terminale locale.
  ssh serena@halof ls .ssh
- Accedi come utente serena sull’host remoto.
  ssh serena@halof
- Accedi come utente sonya sull’host remoto.
  ssh halof
- Cancella tutte le chiavi appartenenti a halof dal tuo file locale ~/.ssh/known_hosts.
  ssh-keygen -R halof
- Sulla tua macchina client, crea una coppia di chiavi ecdsa da 256 bit.
  ssh-keygen -t ecdsa -b 256
- Sulla tua macchina client, crea una coppia di chiavi ed25519 da 256 bit.
  ssh-keygen -t ed25519

Metti i seguenti passi nel giusto ordine per stabilire una connessione SSH usando l’agente di autenticazione SSH:

Sul client, avvia una nuova shell Bash per l'authentication agent con ssh-agent /bin/bash.
Sul client, crea una coppia di chiavi usando ssh-keygen.
Sul client, aggiungi la tua chiave privata in un’area sicura della memoria con ssh-add.
Aggiungi la chiave pubblica del client al file ~/.ssh/authorized_keys dell’utente con cui vuoi effettuare il login sull’host remoto.
Se non esiste già, crea il file ~/.ssh per l’utente con cui vuoi fare il login sul server.

Connettiti al server remoto.

L’ordine corretto è:

Passo 1:

Sul client, crea una coppia di chiavi usando ssh-keygen.

Passo 2:

Se non esiste già, crea il file ~/.ssh per l’utente con cui volete fare il login sul server.

Passo 3:

Aggiungi la chiave pubblica del client al file ~/.ssh/authorized_keys dell’utente con cui vuoi effettuare il login sull’host remoto.

Passo 4:

Sul client, avvia una nuova shell Bash per l'authentication agent con ssh-agent /bin/bash.

Passo 5:

Sul client, aggiungi la tua chiave privata in un’area sicura della memoria con ssh-add.

Passo 6:

Connettiti al server remoto.

Per quanto riguarda il port forwarding, quale opzione e direttiva si usa per i seguenti tipi di tunnel:

Tipo di Tunnel Opzioni Direttiva

Local

-L

AllowTcpForwarding

Remote o Reverse

-R

GatewayPorts

X

-X

X11Forwarding
Supponiamo che tu digiti il comando ssh -L 8888:localhost:80 -Nf ina@halof nel terminale della tua macchina client. Sempre sulla macchina client, punta un browser a http://localhost:8888. Che cosa ottieni?

La homepage del webserver di halof.

Risposte agli Esercizi Esplorativi

Per quanto riguarda le direttive di sicurezza SSH:
- Quale direttiva è usata in /etc/ssh/sshd_config per abilitare i login di root:
  
  PermitRootLogin
- Quale direttiva useresti in /etc/ssh/sshd_config per accettare connessioni SSH solo da un account locale :
  
  AllowUsers
Quando si usa lo stesso utente sia sul client sia sul server, quale comando ssh si può usare per trasferire la chiave pubblica del client sul server in modo da poter effettuare il login tramite autenticazione a chiave pubblica?

ssh-copy-id
Crea due tunnel di porte locali in un unico comando che inoltra le porte locali non privilegiate 8080 e 8585 attraverso il server remoto halof a rispettivamente i siti web www.gnu.org e www.melpa.org. Usa l’utente ina sul server remoto e non dimenticare di usare le opzioni -Nf:

ssh -L 8080:www.gnu.org:80 -L 8585:www.melpa.org:80 -Nf ina@halof