SSH

Published by Lello on

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:

ssh1

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:

ssh2

Indichiamo che vogliamo accedere con user utenteditest:

ssh3

Associamo all’utente di test la chiave server01_private.ppk convertita precedentemente:

ssh4

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