SSH
SSH (Secure SHell) è un protocollo che permette di stabilire una sessione con un server remoto tramite un canale cifrato; è anche un servizio fornito da tutte le distribuzioni Linux presenti sul mercato.
La connessione SSH ha sostituito con l’andare degli anni quella Telnet, offrendo una shell più sicura e robusta.
Il protocollo SSH è formato da due parti: la parte server e la parte client; per la nostra configurazione utilizzeremo come riferimento la distribuzione Linux CentOS 7.0
I file di configurazione della parte server (e della parte client) li troviamo s0tto la directory /etc/ssh; in particolare:
- ssh_config file di configurazione per la parte client
- sshd_config file di configurazione per la parte server
Ci concentreremo sulla configurazione della parte server, utilizzando per l’accesso al nostro server un sistema basato su chiavi asimmetriche per effettuare l’autenticazione (e dunque senza utilizzo di senza password).
Dopo aver fatto accesso al nostro server con utente root (o analogo utente con diritti amministrativi), apriamo una sessione sull’utente su cui vogliamo creare la coppia di chiavi:
[root@server01 ~]# su - utenteditest [utenteditest@server01 ~]$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/utenteditest/.ssh/id_rsa): Created directory '/home/utenteditest/.ssh'. Enter passphrase (empty for no passphrase): <== E POSSIBILE ASSEGNARE ALLA CHIAVE UNA PASSWORD PER AUMENTARE LA SICUREZZA Enter same passphrase again: Your identification has been saved in /home/utenteditest/.ssh/id_rsa. Your public key has been saved in /home/utenteditest/.ssh/id_rsa.pub. The key fingerprint is: 6f:a0:46:1d:1f:36:a8:30:ac:8c:85:8b:ca:0e:a0:71 utenteditest@minou.anthesia.net The key's randomart image is: +--[ RSA 2048]----+ | | | . . . | |. . + o + | |.= . o o + o | |* E o S . | |=o . . o | |+. o o | |o . . | | . | +-----------------+
Alla fine di questo processo, nella direcotry ~.ssh dell’utente utenteditest, troveremo 2 files:
- id_rsa Rappresenta la chiave privata; questa chiave non dovrà essere comunicata a nessuno, in quanto è quella che ci permetterà di accedere al nostro server;
- id_rsa.pub Rappresenta la chiave pubblica, è quella che, in accoppiata alla chiave privata, permetterà l’accesso al server; tale chiave potrà essere messa in tutti i server a cui dovremo accedere.
Il concetto è molto semplice: la chiave privata è quella che dobbiamo avere solo noi per accedere al server; la chiave pubblica la potremo dare a chiunque e/o metterla nei server a cui dobbiamo accedere.
La coppia di chiavi generata è come la serratura della nostra porta di casa con la sua chiave: non esiste (o meglio non dovrebbe esistere) un’altra chiave che possa aprire la serratura di casa nostra, non esiste (e sicuramente non esiste) un’altra chiave privata che possa combinarsi con la chiave pubblica da noi generata; se perdessimo la chiave privata non sarà più possibile accedere al nostro server se non rigenerando una nuova coppia di chiavi.
Rinominiamo la chiave pubblica (che resterà nel server):
[utenteditest@server01 ~]$ mv id_rsa.pub authorized_keys
Visualizziamo il contenuto della chiave privata dell’utente:
[utenteditest@server01 ~]$ cat id_rsa -----BEGIN RSA PRIVATE KEY----- MIIEoQIBAAKCAQEArsYksUX7Huu8bAciKuSJM9Z7pq+2ua6UzHA9gv0HtI4BFRjf WjkV1/ETYvXpLtdXp2lEsLouH9SHevzg9z4lTUb2zS0LaBvPayjR6GFw56HbXDvG qslQQLswwhaGet4aV+1ruh3+GcWw+IKRvqfIiuwy4tdEj8YRgewlx51Ul5jM+wga zfeLqSgL74vPxefpiiZ1CxOulIvFuIFLcItdchUKp6gj83NH2283DQXeY71ql9oD g+5F+QNs+Yn7uv5+lZ9CJJejrtxG62NEqUpVg488svqKMtqENPwABqyjkE07CujV x3jHENgIFP9TqyLerDPk8hHMBqkJvR+wK2gfNwIBIwKCAQAO+wp1mEi5geuUOyAv j+6AyT3MdXYP6mSGjUcZ2yyL0ahSQ/XjKXbmn6KTdCnuEnU6PDkWdlu5ld+6Fazh /gMygmztA9xoAmI8YpWmNDzgp3kzypwAAqB6k7O43Vv75ybUVi3OH9PzlJoj7e88 OkRjrdh51+/vEPovtSfPR//vvH+LlN9BSHOxW+OG7xUd7bjZhK0o8ldlOX9DI8Of 0XjiQXuZOT9Q82JRrj5LgJut8Tf6tIJGoKWyO6KsaW8o3dxWuUmf0RIMnRmcqcvn Sy3MwyYDscuOw8tqY7VGf7dVO0Ra54/gWngsRoWpntP21PgJ7/rsTXV8ZJxSTRfz uMajAoGBAN7R0V5aINXmpd3Zf2JSjGcXnjc5JFfF3Ocx2MKIsMusWQiT3Jnljo/B 2l4RteijTiBde1C916qCaoAwEc4UArImBsk2nYc4f8lS/o7tSAIH3QsPHZfxszm3 C+1vlelG4NuXHTm+rwc5w805cGaaq12q2EdrBy+JV8JElgCGvMvtAoGBAMjMwzp6 NBqtUiTv0cxrhhXeJwRJjrCHEBHMsfP0pA92FWAYL6ddd+e1+VeKc4gocRJ4JMLj bw5XNoLt/3IfihcmfB36yEnjM6gfUmrcP+fReCDOGAC/kFqkuiULRLS8Y5dPPg15 /5sn3XjLUe7Qwt3iwS4Xgux8u30NsO2JP5szAoGAExlMdc02A7SvIaTtqVeIYJuf 2NkDHXdcE9ESlFTb9DNYFq2WkNkpeglNO0NYvCtBNfliV2C6ttf6gAQeyIVfURkz yBqfycMDo4rFXLVAr7eH+aI1vJEPXLfrFFoFiQYTRgWja1l8t3n61xONSp+LCAdU XeSaN0ZJWctdUICT1vcCgYEAwxAOG4ynpOLiFUC9LPq8xMktN11mCpHVGJr2Au2m r+8Nc0qx8wpXONypEzYJ1LmSabaKHGfoOdEQYe6DHmfH+TtT/92sn4xAzzResPM2 w/AOS8DkHfvrUL1HHKvcV8zzCAPV4TSvKQInmeoVE+C9TJMiD4SNz8mgMFZxW8cn 2JcCgYATCCXcfDgkhXkZCEe4JT90lwnx/HZydUBzv41jB76IzrYuIkdb1csZzmoE yKtSXYQzYXfJoualNX4TvHQ6uA9WohkAnW5kDrujLmHSxfRvutqxyT1kjjFDlham pX62yrOK9QKDpsupDv5V0NJG7T18Dfgxgqmt/DLKv6loBFtSNA== -----END RSA PRIVATE KEY----- [utenteditest@server01 ~]$ rm -f id_rsa <== CANCELLIAMO DAL SERVER LA CHIAVE PRIVATA [utenteditest@server01 ~]$ exit [root@server01 ~]#
Modifichiamo il file di configurazione del nostro server (sshd_config) per permettere l’accesso, oltre ad autenticazione con password, anche l’autenticazione con chiave pubblica:
PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys <== QUESTO E' IL NOME CHE DOBBIAMO DARE ALLA NOSTRA CHIAVE PUBBLICA
e riavviamo il servizio
systemctl restart sshd.service
Copiamo la chiave privata sulla macchina da cui effettiamo l’accesso verso il nostro server; per far questo basta copiare il contenuto del file id_rsa (che abbiamo “visualizzato” precedentemente).
1. Se effettuiamo l’accesso da una macchina windows, vi consiglio di usare come client SSH il programma putty, universalmente il più utilizzato. Scarichiamo il programma PuTTY e copiamolo nella directory c:\putty; scarichiamo anche il programma PuTTYgen che ci servirà per la manipolazione delle chiavi.
Apriamo un editor di testo, ed incolliamoci dentro la chiave privata visualizzata precedentemente (comprese la linea iniziale di BEGIN … KEY e la riga finale di END … KEY; salviamo il file come c:\putty\keys\server01_private.key
Apriamo ora il programma PuTTYgen per convertire la chiave privata in una chiave (con estensione .ppk) riconoscibile dal programma PuTTY; premiamo su “Conversion”, “Import key” e scegliamo il file c:\putty\keys\server01_private.key:
Premiamo sul bottone “Save private key” e scegliamo come percorso c:\putty\keys\server01_private.ppk; a questo punto la nostra chiave privata è utilizzabile da PuTTY. Apriamo PuTTY e creiamo un nuovo profilo per il nostro server:
Indichiamo che vogliamo accedere con user utenteditest:
Associamo all’utente di test la chiave server01_private.ppk convertita precedentemente:
Possiamo salvare il nostro profilo tornando alla categoria “Session” e scegliendo “Save”; la nostra sessione è salvata e ci permetterà nel futuro di accedere al nostro server server01.anthesia.lan con utente di test e chiave crittografata semplicemende scegliendo la sessione appena creata.
2. Se effettuiamo l’accesso da una macchina linux, la procedura è relativamente più semplice; salvate il file della chiave privata nella directory ~.ssh (chiamandolo magari server01_private) dell’utente con cui farete accesso e cambiategli i diritti con:
[utente2@server02 ~]$ chmod 600 ~.ssh/server01_private
Se il comando precedente non venisse dato, al momento della connessione avrete il seguente messaggio di errore:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0664 for 'server01_private' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: server01_private
Per accedere al server server01 con utente di test e chiave server01_private, basterà utilizzare il seguente comando:
[utente2@server02 ~]$ ssh -i ~.ssh/server01_private utenteditest@server01.anthesia.lan
La prima volta che accederete, vi verrà chiesto di confermare l’autenticità del server a cui vi state collegando:
The authenticity of host 'server01.anthesia.lan (172.xx.xx.xx))' can't be established. RSA key fingerprint is 6f:a0:46:1d:1f:36:a8:30:ac:8c:85:8b:ca:0e:a0:71 Are you sure you want to continue connecting (yes/no)
Dovrete rispondere di si (yes) (se volete essre sicuri, verificate la fingerprint della chiave RSA con la fingerprint generata al momento della creazione della vostra coppia di chiavi).
Note:
Come vedete NON abbiamo MAI associato all’utente una password, in quanto non necessaria; l’unica cosa di cui ha necessità l’utente per accedere al server, sarà solo la sua chiave privata (eventualmente abbiamo associato una password alla chiave privata per aumentare la sicurezza, cosa che vi consiglio vivamente di fare).
Come le chiavi di casa, anche le chiavi di crittografia devono essere custodite gelosamente e mai perse, in quanto sono le uniche che permettono l’accesso al server; se tale chiave venisse compromessa (per problemi legati ad uso fraudolento del computer nel quale è custodita, quali ad esempio virus o trojan), vi consiglio di accedere quanto prima al server e ripetere la procedura per generare una nuova coppia di chiavi; vi consiglio anche di rigenerare la coppia di chiavio periodicamente.
Per accedere ad un server diverso da server01, non dovrete necessariamente creare una nuova coppia di chiavi; basterà mettere nel nuovo server la chiave pubblica in vostro possesso nella directory ~.ssh dell’utente con cui effettuerete l’accesso e rinominarla in authorized_keys.
Una volta che siete sicuri che l’accesso al vostro server tramite chiave pubblica funzioni, potrete togliere l’accesso al server tramite password, modificando il file sshd_config:
PasswordAuthentication no
Da questo momento in poi, l’unico modo per accedere al vostro server sarà quello di possedere una coppia di chiavi associate ad un utente; inoltre vi consiglio di togliere l’accesso come root, in maniera tale che solo gli utenti in possesso di chiavi possono accedere e successivamente aprire una shell in modalità superuser:
PermitRootLogin no
In questo modo, nel vostro file di log, saprete di preciso quale utente ha fatto accesso al server; dal file di log /var/log/secure:
Sep 8 11:39:07 server01 sshd[31026]: Accepted publickey for utenteditest from 8.8.8.8 port 50076 ssh2
Facilmente vedremo quale utente ha richiesto privilegi di amministratore:
Sep 8 11:40:20 server01 su: pam_unix(su-l:session): session opened for user root by utenteditest (uid=588)
Per aumentare ulteriormente la sicurezza, potrete inserire all’interno del file di configurazione del servizio ssh, gli utenti a cui è permesso effettuare ssh:
AllowUsers utenteditest
L’unica cosa che rimane da fare è riavviare il servizio applicando tutte le modifiche sopra descritte.
systemctl restart sshd.service