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) |
(aggiornata completamente la pagina) |
||
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. | |
− | + | 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. | |
− | + | == Premessa == | |
− | + | Si considera che: | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
* è stato gia installato il server SSH; | * è stato gia installato il server SSH; | ||
− | * il collegamento | + | * si ha accesso al server remoto e funziona il collegamento tra esso ed il proprio pc. |
− | |||
− | |||
== Generare Chiave Pubblica e Privata == | == Generare 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 | |
− | Spostiamoci nella cartella ~./ssh e diamo il comando | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | ssh-keygen -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. |
− | + | Aprite poi il file ~./ssh/config ed aggiungete il server a cui collegarsi aggiungendo le seguenti righe: | |
− | + | Host webmail | |
+ | HostName IPDELSERVER | ||
+ | IdentityFile ~/.ssh/id_rsa_nomeserverimpostato | ||
+ | HashKnownHosts yes | ||
+ | GSSAPIAuthentication yes | ||
− | + | == Copia della chiave sul server == | |
− | + | La copia si effettua con il seguente comando: | |
− | |||
− | |||
− | |||
− | |||
− | + | ssh-copy-id -i id_rsa_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): |
− | |||
− | |||
− | |||
− | + | 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, 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 == | ||
− | + | 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 delle 20:08, 4 feb 2020
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 crittografia assimetrica, Wikipedia, l'enciclopedia libera.
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.
Premessa
Si considera che:
- è stato gia installato il server SSH;
- si ha accesso al server remoto e funziona il collegamento tra esso ed il proprio pc.
Generare 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)"
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.
Aprite poi il file ~./ssh/config ed aggiungete il server a cui collegarsi aggiungendo le seguenti righe:
Host webmail HostName IPDELSERVER IdentityFile ~/.ssh/id_rsa_nomeserverimpostato HashKnownHosts yes GSSAPIAuthentication yes
Copia della chiave sul server
La copia si effettua con il seguente comando:
ssh-copy-id -i id_rsa_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):
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, 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
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