Login SSH - Cronologia

Odeeno il 19:37, 28 mar 2021

2021-03-28T19:37:58Z

Odeeno il 19:26, 28 mar 2021

2021-03-28T19:26:18Z

Odeeno: /* Generare la chiave pubblica e privata */

2021-03-27T23:39:35Z

Generare la chiave pubblica e privata

Odeeno il 23:19, 27 mar 2021

2021-03-27T23:19:04Z

Odeeno: aggiornata completamente la pagina

2020-02-04T19:08:32Z

aggiornata completamente la pagina

Mostra modifiche

Odeeno: Odeeno ha spostato la pagina How-to login in SSH con una chiave criptografica a Login SSH: necessario aggiornamento

2020-02-03T22:51:50Z

Odeeno ha spostato la pagina How-to login in SSH con una chiave criptografica a Login SSH: necessario aggiornamento

EndelWar: Pagina ricreata dopo eliminazione errata

2016-06-06T10:43:50Z

Pagina ricreata dopo eliminazione errata

Nuova pagina

= Howto login SSH con chiave criptografica =

'''Situazione: '''mi trovo connesso in una rete “insicura” e intendo collegarmi ad un server SSH remoto, connesso ad Internet.

'''Cosa significa e a cosa serve questo howto''': una volta seguite le istruzioni che seguono, sarete in grado di loggarvi in un vostro server SSH facendo uso di una chiave crittografica privata con o senza password.

'''Perchè''': utilizzando una chiave crittografica, è migliorato il livello di sicurezza del collegamento:

# non avviene lo scambio della chiave crittografica alla prima connessione al server SSH;
# è possibile utilizzare una password differente da quella di login nel server fisico.

= Premessa =

Chiunque effettui una breve ricerca su questo argomento trova una miriade di collegamenti: spesso però sono incompleti. Questa guida Per aiutare i soci del Montellug
In questo howto non vengono trattati i seguenti argomenti, che verranno eventualmente argomentati in apposite pagine wiki del sito del MontelLug:

* utilizzare SSH per creare un tunnel tra due macchine remote;
* impostare un server SSH; creare un tunnel instradando il traffico VNC sulla connessione SSH; impostare il router affinchè svolga un port-forwarding;
* collegamento ad un server SSH;
* VNC ed altri programmi utilizzabili in un tunnel SSH;

In questo howto si considera che:

* è stato gia installato il server SSH;
* il collegamento è già stato testato ed è possibile loggarsi nel modo tradizionale;
* sia possibile memorizzare una chiave privata su un supporto informatico: tramite una penna USB o un CD o qualunque altro tipo di supporto di memorizzazione mobile.

= Configurazione demone SSH =
== Generare Chiave Pubblica e Privata ==

Creiamo una copia di chiavi crittografiche, una pubblica ed una privata.
Spostiamoci nella cartella ~./ssh e diamo il comando

ssh-keygen -t dsa

Se non esiste la cartella dobbiamo crearla così:

mkdir -p ~/.ssh
chmod 700 ~./ssh
cd ~/.ssh

Seguiamo le istruzioni: verrà chiesto l'inserimento di una password.
Si tratta della password che verrà utilizzata per connettersi via SSH, pertanto è bene inserirne anche una
Al termine nella cartella ~./ssh troveremo 2 files:

* '''''id_rsa''''' la chiave privata
* '''''id_rsa.pub''''' la chiave pubblica

La chiave pubblica verrà conservata nella cartella nascosta ~./ssh nella directory dell'utente nel server. La chiave privata verrà salvata nella chiavetta USB e servirà per connettersi da remoto.

La chiave pubblica andrà memorizzata anche nel seguente file cui fa riferimento il file di configurazione del demone SSH:

cat ~/.ssh/id.pub >> authorized_keys
chmod 600 authorized_keys

== Configurazione demone SSH ==

Il file di configurazione del demone SSH si trova in /etc/ssh/sshd_config: è questo il file che deve essere modificato per configurare il demone.

Salvare il file in questione prima della modifica:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_ORI

Apriamo il file di configurazione per modificarlo:

sudo nano /etc/ssh/sshd_config

Ora bisogna procedere ad effettuare le modiche al file: alcune volte sarà sufficiente togliere il carattere # (che viene interpretato come “tutto ciò che segue è commento e non configurazione), altre volte si dovrà modificare il testo.

=== Impostare la porta di collegamento ===

Cerchiamo la parola port e modifichiamo il numero che la segue a nostra scelta.

port 22

La porta di default sulla quale restano in ascolto i server SSH è 22. Per motivi di sicurezza è possibile cambiarla, considerando però che in seguito si dovrà impostare il collegamento remoto a questa porta. Per semplicità consideriamo di non modificare la porta di default.

=== Disabilitare i login remoti con l'account di root ===

Per disabilitare il login da remoto con i permessi e privilegi disponibili all'account root cerchiamo la parola PermitRootLogin modifichiamo come segue.

PermitRootLogin no

''Nota 1'': probabilmente troverete come parametro yes;

''Nota 2'': in Ubuntu non è abilitaro l'account di root, pertanto è superfluo modificare l'impostazione.

=== Disabilitare la password di autenticazione ===

Se utilizziamo una chiave privata per connettersi al server SSH, una volta avviato il collegamento sarà superfluo che venga richiesta una ulteriore autenticazione alla console. Questo ci consente anche di non utilizzare la nostra vera password sul server per potersi collegare via SSH e costringe colui che si connette al nostro server di avere con se la chiave privata generata in precedenza, senza della quale non sarà possibile autenticarsi ed utilizzare il servizio SSH. Pertanto possiamo decidere di disabilitare tutte le password di autenticazione.

Cerchiamo la riga:

#PasswordAuthentication yes

rimuoviamo il simbolo # e impostiamo il parametro con “no”:

PasswordAuthentication no

=== Conclusioni ===

Salviamo il file di configurazione così modificato ed usciamo dall'editor utilizzato.

Riavviamo il demone SSH affinchè le modifiche apportate diventino operative:

sudo /etc/init.d/ssh restart

= Avviare la connessione da remoto =

Effettuate le modifiche evidenziate sarà possibile connettersi al server utilizzando la chiave privata generata.

Effettuiamo il test da un altro pc connesso direttamente alla rete interna protetta. L'impostazione del port forwarding sul router/firewall non viene trattato in questa guida.

== Avviare una sessione SSH da un client Linux ==

Copiare la propria chiave privata, nel proprio profilo:

sudo cp /media/USBdrive/id_rsa ~/.ssh/

e modificare i permessi sulla chiave appena copiata in modo da renderla usabile solo all'utente:

sudo chmod 600 ~/.ssh/id_rsa

Avviare la sessione SSH:

ssh -p 22 nome_utente@IP_del_server

Se tutto è stato impostato a dovere vi dovrebbe comparire il prompt del vostro ''nome_utente ''sul server a cui vi siete connessi.

''Nota 1'': è utilizzata la porta di default n. 22. Cambiarla nel caso nel file di configurazione del demone SSH del server sia diversa.

== Avviare una sessione SSH da un client Windows ==

Per connettersi alla macchina remota da un computer con SO Windows è necessario procurarsi gli opportuni programmi, dato che windows non è dotato di alcun client SSH:

Si consiglia un semplice e portatile programmino denominato '''Putty''':

* questo è il link ufficiale del progetto: [http://www.chiark.greenend.org.uk/~sgtatham/putty/ http://www.chiark.greenend.org.uk/~sgtatham/putty/]
* questa è la pagina descrittiva in Wikipedia: [http://it.wikipedia.org/wiki/Putty http://it.wikipedia.org/wiki/Putty]

Il programma può essere salvato anche direttamente nella chiavetta USB o nel supporto utilizzato per memorizzare la chiave privata

'''Putty:''' ssh-client che rende usabile ssh su macchine Windows.

'''Puttygen:''' software necessario per trasformare la nostra chiave id_rsa nel formato usato da Putty (.ppk): scaricate anche questo!

== Importare la chiave privata in Putty ==

Prima di tutto è necessario generare una chiave privata (vengono generate entrambe le chiavi, ma a noi serve solo la privata; la pubblica non ci serve) nel formato utilizzabile da putty.

Apriamo il programma puttygen.exe ed eseguiamo le seguenti operazioni:

* andare nel menù ''Conversions | Import Key'';
* scegliere la propria chiave privata (generata da SSH) ed inserire la propria password;
* aggiornare la ''key fingerprint'';
* impostare la password: è possibile lasciare la password di default utilizzata o non impostare alcuna passoword.
* salvare le chiavi usando ''Save public key e Save private key'';

E' possibile in questa fase decidere anche di non impostare una password alla chiave privata:

'''PRO''':
* è comodo: per avviare la sessione SSH non verranno chieste password: è sufficiente la chiave privata.
'''CONTRO''':
* è rischioso: qualora venisse persa la chiavetta USB o vi venisse rubata la chiave privata, non ci sono ostacoli ad avviare una sessione SSH perfettamente funzionante.

''Nota 1'': è sempre possibile partendo dalla propria chiave privata ricostruire la propria chiave pubblica, ma non il contrario.

= Linkografia =

[http://wiki.ubuntu-it.org/InternetRete/ConfigurazioneRete/Vnc/CifraturaSsh http://wiki.ubuntu-it.org/InternetRete/ConfigurazioneRete/Vnc/CifraturaSsh]

----

--[[Utente:Odeeno|odeeno]] 23:24, 12 nov 2008 (CET)

@@ Riga 38: / Riga 38: @@
-=== Aggiunta della chiave a SSH-Agent ===
+= Aggiunta della chiave a SSH-Agent =
 Il comando è semplice: verificare prima che ssh-agent sia attivo con ''eval "$(ssh-agent -s)"''
@@ Riga 46: / Riga 46: @@
 oppure semplicemente ''ssh-add'' per aggiungere tutte le chiavi disponibili.
-== Copia della chiave sul server ==
+= Copia della chiave sul server =
 La copia si effettua con il seguente comando:
@@ Riga 53: / Riga 53: @@
-== Impostazioni del server ==
+= 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:
@@ Riga 69: / Riga 69: @@
 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 =

@@ Riga 20: / Riga 20: @@
 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"
+* -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_rsa_nomeserverimpostato''''' la chiave privata da custodire adeguatamente e '''''id_rsa_nomeserverimpostato.pub''''' la chiave pubblica che verrà poi copiata nel server.
+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 ==
@@ Riga 41: / Riga 50: @@
 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
-De-commentare e modificare le seguenti opzioni (digitare ''man sshd_config'' per ottenere info su tutte le altre opzioni):
+== Impostazioni del server ==
   PermitRootLogin yes
   PubkeyAuthentication yes
 Riavviare sshd con il comando seguente e lanciare nuovamente ssh-copy-id sopra indicato:
@@ Riga 54: / 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.
 == Conclusioni  ==

@@ Riga 16: / Riga 16: @@
 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 -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "$(whoami)@$(hostname)-$(date -I)"
+  ssh-keygen -a 100 -t ed25519 -C "$(whoami)@$(hostname)-$(date -I)"
 vediamo le opzioni:
-* -o
+* -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;
 * -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"
-Il programma chiederà:
+Una volta dato invio, il programma chiederà:
-* il nome del file: consigliato usare una chiave per ciascun server; non costa nulla ed aumenta la sicurezza;
+* 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 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.
+* 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_rsa_nomeserverimpostato''''' la chiave privata da custodire adeguatamente e '''''id_rsa_nomeserverimpostato.pub''''' la chiave pubblica che verrà poi copiata nel server.

@@ 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 -o -a 100 -t ed25519 -f ~/.ssh/id_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.