In questo articolo articolo continuiamo ad affrontare il tema dell'accesso ai sistemi remoti tramite SSH. Innanzitutto possiamo fare riferimento ai files di configurazione di SSH che a livello server sono localizzati nella cartella /etc/ssh/. In questa cartella troveremo il file fondamentale che raduna le principali configurazioni, ossia sshd_config.
Questo file può essere editato con un qualsiasi editor di testo dall'utente root del sistema. Vediamo alcune delle principali configurazioni modificabili per le nostre esigenze.
L'operazione preliminare prima di ogni modifica, consigliata in caso di problematiche riscontrate successivamente è effettuare un backup del file config in modo da poter sempre effettuare comparazioni o un ripristino futuro.
$ cp sshd_config sshd_config.bak
Iniziamo ora la configurazione specifica. Innanzitutto, controlliamo sempre che sia settato il protocollo che SSH dovrà utilizzare, impostare la versione 2 poiché più recente, compatibile con la stragrande maggioranza dei sistemi nonchè più robusta e sicura. Editare il file di configurazione, o controllare la presenza, con il record:
Protocol 2
Successivamente, potremmo avere la necessità di cambiare la porta di ascolto di SSH, di default la porta utilizzata è la 22. Prima di cambiare la porta di default è consigliabile verificare nella lista di porte standard (disponibile qui) che la porta che abbiamo in mente sia libera, onde evitare la sovrapposizione tra servizi e protocollo diversi potenzialmente problematica. Supponiamo di scegliere la porta 34567, dovremmo modificare quindi il record Port in:
Port 34567
E' bene precisare che l'indicazione delle porta di ascolto potrebbe includere più opzioni, ad esempio porte diverse a seconda delle nostre esigenze.
Per rendere effettiva la configurazione bisognerà riavviare il servizio SSH:
$ systemctl restart sshd
Da questo momento in poi per connetterci alla nostra macchina dovremmo usare:
$ ssh -p 34567 myaccount@100.100.100.100
La variazione della porta SSH, tuttavia, è una pratica di sicurezza limitata, in quanto una basilare software per il Port Scanning permetterà facilmente l'individuazione della porta “alternativa” scelta. L'efficacia è concentrata invece sull'esigenza che potremmo maturare nel mantenere la porta 22 libera per altre motivazioni oppure per “mitigare”, quanto più possibile, i tentativi di intrusione che vengono costantemente effettuati da sistemi deputati allo scopo (bot, ecc.). Una volte che un sistema è in rete con IP accessibile al mondo si viene sistematicamente bombardati da tentativi di accesso automatizzati che continuamente tentano centinaia di migliaia di combinazioni nome utente / password per accedere alla macchina e prenderne il controllo. Approfondiremo questo tema in un futuro articolo, presentando appositi software che si occupano del monitoraggio e blocco degli accessi ai sistemi (ad es. Fail2Ban).
L'account privilegiato per i tentativi di accesso ai sistemi è certamente l'utente root. Consigliamo vivamente di disabilitare in ogni caso l'accesso al sistema tramite utente root, anche se abbiamo scelto (o ci è stata fornita in automatico da alcuni provider) una password particolarmente lunga e complessa.
La configurazione da impostare è - modificando il record nel file sshd_config da ‘yes' a ‘no' - rimuovendo, se necessario, il commento ad inizio riga ‘#' che rende l'istruzione effettiva:
PermitRootLogin no
Che andrebbe sempre accompagnata dalla disabilitazione delle password vuote:
PermitEmptyPasswords no
Cioè, in fase di accesso, è sempre necessario fornire una stringa come password (indipendentemente da quale) per l'accesso al sistema.
Inoltre, è consigliato disabilitare sempre l'accesso basato sui nomi host con:
HostbasedAuthentication no
Per l'accesso ai sistemi tramite SSH, il modo più sicuro è la creazione di opportune chiavi di accesso piuttosto che l'utilizzo delle password. Per quanto complessa, un soggetto che conosce il nome utente d'accesso presente sulla macchina potrebbe indovinare la password o sottrarla in altri modi al legittimo amministratore se quest'ultimo l'abbia incautamente conservata o divulgata.
Prima di proseguire è necessario chiarire alcuni concetti spesso ignorati. L'accesso tramite chiavi è una procedura sicura migliore dell'accesso tramite password. E' sicura fintanto che il PC (laptop, fisso, ecc) su cui generiamo le chiavi venga custodito / usato da soggetti responsabili. Se ad esempio un amministratore di rete incauto subisce il furto del proprio laptop aziendale (senza nessuna precauzione, ad esempio cifratura del disco dati del PC) un utente esperto potrebbe facilmente recuperare le chiavi di accesso ai sistemi target. Infine, disabilitando l'accesso tramite password e generando una sola chiave, la perdita di quest'ultima potrebbe determinale l'impossibilità futura di aver mai più accesso ai sistemi gestiti (nell'eventualità in cui i Provider di sistemi virtuali non forniscano assistenza, o nel caso di macchine “fisiche”, sotto il nostro controllo, si abbia a disposizione personale tecnico in grado di risolvere la problematica).
Ci sono ovviamente numerosi pro per l'accesso ai sistemi tramite chiavi. Oltre alla maggiore sicurezza, lo stesso si rende necessario nel caso in cui abbiamo la necessità di configurare ed automatizzare software / script per operazioni automatizzate (ad es. backup, monitoraggio, logging, ecc.) oppure abbiamo in gestione decine di macchine per cui memorizzare, conservare ed utilizzare continuamente le diverse password di accesso sarebbe un'operazione sconveniente e soggetta ad errori continui.
Vediamo ora in pratica come generare la nostra chiave di accesso ad una macchina con IP 100.100.100.100. Per farlo possiamo dare la seguente istruzione:
$ ssh-keygen -t key_type -b bits -C "commento opzionale"
Subito dopo il lancio del comando ci verrà chiesto un nome del file in cui sarà conservata la chiave, di default è id_xxx (tuttavia modificabile a piacimento) e una “passphrase” da inserire. La chiave potrebbe essere usata richiedendo questa passphrase ogni volta all'utente, oppure, se lasciata in bianco dando semplicemente Invio 2 volte, priva di passphrase. Ciò è conveniente per gli accessi (semi)automatizzati con chiave di cui parlavamo poc'anzi.
Proviamo adesso a generare una chiave tramite algoritmo RSA a 4096 bits flaggandola con un commento a nostra scelta. L'inserimento di un commento potrebbe aiutarci in futuro a distinguere le varie chiavi. Ad esempio:
$ ssh-keygen -t rsa -b 4096 -C "chiave mionome@localhost"
Se volessimo scegliere algoritmi diversi per la generazione della chiave potremmo ad esempio utilizzare il comando -t dsa, -t ecdsa oppure -t ed25519 per utilizzare varianti del Digital Signature Algorithm o altri algoritmi al posto di RSA. Per un elenco degli algoritmi utilizzabili sul nostro sistema possiamo lanciare il comando:
$ ssh -Q key
Possiamo verificare la creazione della chiave dando il comando:
$ cat .ssh/id_xxx
Il file id_xxx, o qualsiasi nome scelto, contiene la chiave appena creata.
Non ci resta che scambiare col la macchina remota su cui vogliamo avere accesso la chiave appena creata, rechiamoci nella cartella in cui è presente la chiave e lanciamo il comando:
$ cd .ssh/ (se non eravamo già presenti)
$ ssh-copy-id -i id_rsa.pub myuser@100.100.100.100
Ci verrà chiesta la password di accesso del relativo utente, digitiamola. Se tutto andrà a buon fine con lo scambio della chiave presso il sistema remoto otterremo conferma con una stringa simile a:
Number of key(s) added: 1
Per i prossimi login nel sistema remoto, dalla macchina su cui abbiamo generato la chiave, ci basterà lanciare il comando:
$ ssh (-p 34567) myuser@100.100.100.100
Senza la richiesta di alcuna password, naturalmente l'indicazione di una porta specifica è opzionale.
Per concludere tutta l'operazione di configurazione della procedura di accesso tramite chiavi dovremmo settare alcune impostazioni specifiche nel file sshd_config sulla macchina remota. Le stesse consentiranno in futuro ESCLUSIVAMENTE l'accesso tramite chiave. Queste sono:
AuthenticationMethods publickey
PubkeyAuthentication yes
Che vengono completate con:
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
Che disattivano l'accesso tramite password e modulo PAM. Attenzione al settato di tali record in quanto è necessario accertarsi preventivamente dell'accesso tramite chiavi nonché del nostro caso specifico che andrebbe ad escludere il login tramite password anche ad altri utenti.
Ricordiamo, infine, che ogni modifica del file /etc/sshd_config richiede il riavvio del server ssh per divenire effettiva.
Nella terza parte di questo articolo continueremo ad affrontare in dettaglio alcune impostazioni mirate di SSH per sfruttarne tutte le potenzialità aumentando il livello di sicurezza.
Qualsivoglia richiesta può essere inviata a NAOSDATA che offre servizi di consulenza, implementazione e managment specifico sulle infrastrutture ICT.
Ci auguriamo che questo articolo vi sia piaciuto e vi possa essere d'aiuto nell'orientarvi nel mondo SSH. Se apprezzate il nostro lavoro seguite i nostri profili su Facebook e LinkedIn.
Questo lavoro è offerto tramite licenza Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Risorse e Link:
- • https://www.ssh.com/academy/ssh/command
- • https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys