Differenze tra le versioni di "Login SSH"
Da MontelLUG WIKI.
m (Odeeno ha spostato la pagina How-to login in SSH con una chiave criptografica a Login SSH: necessario aggiornamento) |
m |
||
(4 versioni intermedie di uno stesso utente non sono mostrate) | |||
Riga 1: | Riga 1: | ||
− | = | + | = 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 [https://it.wikipedia.org/wiki/Crittografia_asimmetrica 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 [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 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 [http://www.sshguard.net/ sshguard] | ||
− | == | + | = Note = |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
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