Versione attuale delle 20:37, 28 mar 2021

Login in un server via SSH con chiave pubblica

Lasciare aperta la porta di un server SSH su internet è rischioso: lo è un poco meno se il server è impostato per non accettare l'autenticazione tramite password e di accettare solo l'accesso tramite chiave pubblica, ovvero sfruttando la crittografia assimetrica.

Questa pagina vuol esser un semplice manuale o un pro-memoria delle impostazioni da fare: eventuali approfondimenti sulle configurazioni di SSH, di sshd_config o altro non verranno trattate qui.

Premesse

Si considera che:

è stato già installato/disponibile un server SSH;
si ha accesso al server remoto e funziona il collegamento.

Generare la chiave pubblica e privata

Prima di tutto dobbiamo aver a disposizione una una copia di chiavi crittografiche, una pubblica ed una privata. Spostiamoci nella cartella ~./ssh e diamo il comando

ssh-keygen -a 100 -t ed25519 -C "$(whoami)@$(hostname)-$(date -I)"

vediamo le opzioni:

-t ed25519 stabilisce la tipologia di algoritmo da utilizzare per la chiave criptografica: senza entrare nei tecnicismi ed25519 è l'algoritmo ora più raccomandato per la generazione di chiavi;
-a 100 è il numero di KDF (Key Derivation Function); più alto è il numero e più è lenta la verifica della password: di default è 16, incrementa la resistenza agli attacchi di tipo brute-force in caso di furto della chiave privata. E' un opzione aggiuntiva: va valutato il caso specifico per capire se serve impostare l'opzione;
-C "$(whoami)@$(hostname)-$(date -I)" serve ad aggiungere un commento alla chiave quando verrà memorizzata sul server: è utile per riconoscere le chiavi memorizzate sul server. Potrebbe anche esser impostata l'opzione -C "email@dominio.com"

Una volta dato invio, il programma chiederà:

il nome del file: consigliato usare una chiave per ciascun server; non costa nulla dare un nome specifico ed aumenta la sicurezza;
una password: da salvare in modo sicuro; si può anche non impostare nessuna password, ma ovviamente aumenta il rischio in caso di furto della chiave privata; ovviamente in questo caso non ha senso l'opzione -a ed in questo secondo caso la chiave privata deve esser conservata con assoluta cura e non deve finire in dispositivi mobili o passare su internet, perché non è protetta.

Troveremo nella directory il file id_ed25519_nomeserverimpostato la chiave privata da custodire adeguatamente e id_ed25519_nomeserverimpostato.pub la chiave pubblica che verrà poi copiata nel server.

Aprite poi il file ~./ssh/config ed aggiungete il server a cui collegarsi aggiungendo le seguenti righe:

Host nomeserver
  HostName IP_del_server
  IdentityFile ~/.ssh/id_ed25519_nomeserverimpostato
  HashKnownHosts yes
  GSSAPIAuthentication yes

Aggiunta della chiave a SSH-Agent

Il comando è semplice: verificare prima che ssh-agent sia attivo con eval "$(ssh-agent -s)"

ssh-add ~/.ssh/id_ed25519_nomeserverimpostato

oppure semplicemente ssh-add per aggiungere tutte le chiavi disponibili.

Copia della chiave sul server

La copia si effettua con il seguente comando:

ssh-copy-id -i id_ed25519_nomeserverimpostato.pub utenteserver@ipserver

Impostazioni del server

Il comando potrebbe non funzionare per autenticare root perché su alcune distribuzioni (es. Debian), per impostazione di sicurezza a root, di defaut, non è concesso l'accesso remoto: va pertanto modificato questo file /etc/ssh/sshd_config sul server:

cercare e de-commentare/modificare le seguenti opzioni:

PermitRootLogin yes
PubkeyAuthentication yes

Riavviare sshd con il comando seguente e lanciare nuovamente ssh-copy-id sopra indicato:

systemctl restart sshd.service

Fatta la copia della chiave pubblica con il comando indicato nel paragrafo precedente, ri-commentare PermitRootLogin yes o impostare il valore di default PermitRootLogin prohibit-password impostare PasswordAuthentication no e riavviare sshd con il comando di cui sopra.

Conclusioni

Usare una chiave per autenticarsi riduce il rischio di accessi indesiderati: ma se il server è esposto su Internet non basta; è fondamentale se non obbligatorio preoccuparsi di impostare un firewall. E siccome vi sarà possibile vedere quante migliaia di tentativi di accesso verranno fatti sulla porta 22 aperta è consigliabile adottare anche un ulteriore misura di prevenzione tipo sshguard

@@ Riga 1: / Riga 1: @@
 = Login in un server via SSH con chiave pubblica =
-Lasciare disponibile la porta di collegamento ad un server via SSH su internet è rischioso: lo è un poco meno se il server è impostato per non accettare il collegamento tramite password e di accettare solo collegamento tramite chiave pubblica, ovvero sfruttando la [https://it.wikipedia.org/wiki/Crittografia_asimmetrica crittografia assimetrica], Wikipedia, l'enciclopedia libera.
+Lasciare aperta la porta di un server SSH su internet è rischioso: lo è un poco meno se il server è impostato per non accettare l'autenticazione tramite password e di accettare solo l'accesso tramite chiave pubblica, ovvero sfruttando la [https://it.wikipedia.org/wiki/Crittografia_asimmetrica crittografia assimetrica].
-La presente pagina vuol esser un manuale / una guida molto sintetica / un pro-memoria dei passaggi da svolgere per ottenere tutto ciò: eventuali approfondimenti sulle configurazioni di SSH, di sshd_config o altro non verranno trattate qui.
+Questa pagina vuol esser un semplice manuale o un pro-memoria delle impostazioni da fare: eventuali approfondimenti sulle configurazioni di SSH, di sshd_config o altro non verranno trattate qui.
-== Premessa ==
+= Premesse =
 Si considera che:
-* è stato gia installato il server SSH;
+* è stato già installato/disponibile un server SSH;
-* si ha accesso al server remoto e funziona il collegamento tra esso ed il proprio pc.
+* si ha accesso al server remoto e funziona il collegamento.
-== Generare Chiave Pubblica e Privata ==
+= Generare la chiave pubblica e privata =
 Prima di tutto dobbiamo aver a disposizione una una copia di chiavi crittografiche, una pubblica ed una privata. Spostiamoci nella cartella ~./ssh e diamo il comando
-  ssh-keygen -C "$(whoami)@$(hostname)-$(date -I)"
+  ssh-keygen -a 100 -t ed25519 -C "$(whoami)@$(hostname)-$(date -I)"
-l'opzione ''-C "$(whoami)@$(hostname)-$(date -I)'' serve ad aggiungere un commento alla chiave quando verrà memorizzata sul server. Utile per andar bene eventualmente a cancellare le chiavi giuste. Il programma chiederà:
-* il nome del file: consigliato usare una chiave per ciascun server; non costa nulla ed aumenta la sicurezza;
-* una password: da salvare in modo sicuro; si può anche non impostare nessuna password, ma ovviamente aumenta il rischio; in questo secondo caso la chiave privata deve esser conservata con assoluta cura e non deve finire in dispositivi mobili o passare su internet, perchè non è protetta.
-Troveremo nella directory il file '''''id_rsa_nomeserverimpostato''''' la chiave privata da custodire adeguatamente e '''''id_rsa_nomeserverimpostato.pub''''' la chiave pubblica che verrà poi copiata nel server.
+vediamo le opzioni:
+* -t ed25519 stabilisce la tipologia di algoritmo da utilizzare per la chiave criptografica: senza entrare nei tecnicismi [https://en.wikipedia.org/wiki/EdDSA#Ed25519 ed25519] è l'algoritmo ora più raccomandato per la generazione di chiavi;
+* -a 100 è il numero di KDF (Key Derivation Function); più alto è il numero e più è lenta la verifica della password: di default è 16, incrementa la resistenza agli attacchi di tipo brute-force in caso di furto della chiave privata. E' un opzione aggiuntiva: va valutato il caso specifico per capire se serve impostare l'opzione;
+* -C "$(whoami)@$(hostname)-$(date -I)" serve ad aggiungere un commento alla chiave quando verrà memorizzata sul server: è utile per riconoscere le chiavi memorizzate sul server. Potrebbe anche esser impostata l'opzione -C "email@dominio.com"
+Una volta dato invio, il programma chiederà:
+* il nome del file: consigliato usare una chiave per ciascun server; non costa nulla dare un nome specifico ed aumenta la sicurezza;
+* una password: da salvare in modo sicuro; si può anche non impostare nessuna password, ma ovviamente aumenta il rischio in caso di furto della chiave privata; ovviamente in questo caso non ha senso l'opzione -a ed in questo secondo caso la chiave privata deve esser conservata con assoluta cura e non deve finire in dispositivi mobili o passare su internet, perché non è protetta.
+Troveremo nella directory il file '''''id_ed25519_nomeserverimpostato''''' la chiave privata da custodire adeguatamente e '''''id_ed25519_nomeserverimpostato.pub''''' la chiave pubblica che verrà poi copiata nel server.
 Aprite poi il file ~./ssh/config ed aggiungete il server a cui collegarsi aggiungendo le seguenti righe:
-  Host webmail
+  Host nomeserver
- HostName IPDELSERVER
+   HostName IP_del_server
- IdentityFile ~/.ssh/id_rsa_nomeserverimpostato
+   IdentityFile ~/.ssh/id_ed25519_nomeserverimpostato
- HashKnownHosts yes
+   HashKnownHosts yes
- GSSAPIAuthentication yes
+   GSSAPIAuthentication yes
-== Copia della chiave sul server ==
+= Aggiunta della chiave a SSH-Agent =
+Il comando è semplice: verificare prima che ssh-agent sia attivo con ''eval "$(ssh-agent -s)"''
+ ssh-add ~/.ssh/id_ed25519_nomeserverimpostato
+oppure semplicemente ''ssh-add'' per aggiungere tutte le chiavi disponibili.
+= Copia della chiave sul server =
 La copia si effettua con il seguente comando:
-  ssh-copy-id -i id_rsa_nomeserverimpostato.pub utenteserver@ipserver
+  ssh-copy-id -i id_ed25519_nomeserverimpostato.pub utenteserver@ipserver
-Il comando potrebbe non funzionare perchè se sul server gira Debian e dovete autenticare root, per impostazione di sicurezza di defaut non è abilitato l'accesso remoto. Accedete al server e modificate questo file /etc/ssh/sshd_config
-De-commentare e modificare le seguenti opzioni (digitare ''man sshd_config'' per ottenere info su tutte le altre opzioni):
+= Impostazioni del server =
+Il comando potrebbe non funzionare per autenticare ''root'' perché su alcune distribuzioni (es. Debian), per impostazione di sicurezza a ''root'', di defaut, non è concesso l'accesso remoto: va pertanto modificato questo file /etc/ssh/sshd_config sul server:
+cercare e de-commentare/modificare le seguenti opzioni:
   PermitRootLogin yes
   PubkeyAuthentication yes
 Riavviare sshd con il comando seguente e lanciare nuovamente ssh-copy-id sopra indicato:
@@ Riga 49: / Riga 66: @@
   systemctl restart sshd.service
-Fatta la copia della chiave pubblica, ricommentare ''PermitRootLogin yes'' o impostare il valore di default ''PermitRootLogin prohibit-password'' impostare ''PasswordAuthentication no'' e riavviare sshd con il comando di cui sopra.
+Fatta la copia della chiave pubblica con il comando indicato nel paragrafo precedente, ri-commentare ''PermitRootLogin yes'' o impostare il valore di default ''PermitRootLogin prohibit-password'' impostare ''PasswordAuthentication no'' e riavviare sshd con il comando di cui sopra.
-== Conclusioni  ==
+= Conclusioni  =
 Usare una chiave per autenticarsi riduce il rischio di accessi indesiderati: ma se il server è esposto su Internet non basta; è fondamentale se non obbligatorio preoccuparsi di impostare un firewall.
 E siccome vi sarà possibile vedere quante migliaia di tentativi di accesso verranno fatti sulla porta 22 aperta è consigliabile adottare anche un ulteriore misura di prevenzione tipo [http://www.sshguard.net/ sshguard]
-== Note ==
+= Note =

Differenze tra le versioni di "Login SSH"

Da MontelLUG WIKI.