OpenSSH: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
 
(121 versioni intermedie di 8 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili | Lenny | Squeeze}}
{{SSH
=Premessa=
|successivo=SFTP: SSH File Transfer Protocol
}}{{Versioni compatibili}}{{OpenSSH}}
== Installazione ==


Da diverso tempo i server dell'MM Team hanno raggiunto una buona stabilità, e gli uptime lunghi e le poche operazioni di
È bene premettere che se lo scopo di chi legge è solo collegarsi ad altri computer, ma non permettere la connessione a quello in uso, allora è sufficiente l'installazione del solo client (normalmente già effettuata durante l'installazione di debian), viceversa è sufficiente l'installazione del solo server.
manutenzione hanno portato fisicamente le macchine fuori dai piedi, con l'avvio senza KDM.<br>
Premesso questo, per installare sia client che server digitare da terminale con [[privilegi di amministrazione]]:
Ora però resta da risolvere come effettuare la periodiche sessioni di aggiornamento.<br>
Da diverso tempo avevo pensato a SSH ma, un po' per paura, ho sempre tardato a provarlo; ora finalmente mi sono deciso ma
adottando alcune precauzioni.<br>
La seguente lettura porterà a ottenere una connessione SSH sicura, con l'autenticazione basata sul controllo della chiave pubblica.


==SSH cos'è?==
<pre># apt-get install ssh</pre>


tratto da Wikipedia : [[http://it.wikipedia.org/wiki/Secure_shell]]
Per installare il solo client:


'''SSH''' ('''Secure SHell''', shell sicura) è un protocollo di rete che permette di stabilire una sessione remota cifrata ad interfaccia a riga di comando con un altro host.
<pre># apt-get install openssh-client</pre>


Il client SSH ha una interfaccia a riga di comando simile a quella di telnet e rlogin, ma l'intera comunicazione (ovvero sia l'autenticazione che la sessione di lavoro) avviene in maniera cifrata. Per questo motivo, SSH è diventato uno standard di fatto per l'amministrazione remota di sistemi UNIX e di dispositivi di rete, rendendo obsoleto il protocollo telnet, giudicato troppo pericoloso per la sua mancanza di protezione contro le intercettazioni.
Per installare il solo server:


Il client ed il server SSH sono installati o installabili su molte versioni di UNIX, GNU/Linux, Mac OS X e Microsoft Windows. Inoltre è disponibile come strumento di amministrazione su alcuni .
<pre># apt-get install openssh-server</pre>
 
== Utilizzo base ==
 
=== Client ===
 
Al termine dell'installazione del client è già possibile collegarsi ad altre macchine a patto di avere già delle credenziali, ovvero ''username'' e ''password'' di un account valido, per la macchina remota cui ci si vuole connettere.
È quindi sufficiente digitare:
<pre>$ ssh username_remoto@host_remoto</pre>
per iniziare il collegamento.<br/>
Si noti che ''host_remoto'' può essere un nome host, un FQDN o un indirizzo IP. Nei primi due casi il computer su cui è installato il client deve essere in grado di risolvere i nomi del computer remoto, o tramite server DNS oppure tramite file <code>/etc/hosts</code>.
 
Quando ci si collega per la prima volta ad una nuova macchina remota verrà chiesto all'utente se intende effettivamente proseguire con la procedura di autenticazione e contestualmente aggiungere la chiave pubblica della macchina remota al proprio file locale <code>~.ssh/known_hosts</code>.<br>
Il messaggio che viene stampato a video contiene "l'impronta digitale" della chiave pubblica che si andrà ad accettare, così che l'utente possa confrontarla con quella eventualmente già in suo possesso e quindi capire se la macchina remota è effettivamente quella cui l'utente vuole connettersi e NON una macchina diversa operata da qualche malintenzionato.


La sintassi su sistemi UNIX-like è la seguente:
<pre>
<pre>
$ ssh [opzioni] nomeutente@host [comando]
utente@localhost:~# ssh server@xxxx.xxxx.xxxxxx
The authenticity of host 'xxxx.xxxxx.xxxxx (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?
</pre>
</pre>


dove con "$" si intende il prompt della shell utilizzata.
Naturalmente l'utente non è obbligato ad effettuare un simile controllo e quindi può limitarsi ad accettare "andando sulla fiducia". Sebbene potenzialmente rischioso come comportamento, il buon senso aiuta sempre in queste situazioni, quindi se l'utente si collega ad un computer della propria LAN oppure alla macchina di un noto provider, è evidente che il rischio di collegarsi ad una macchina "maligna" sarà nullo o ragionevolmente trascurabile. Una volta accettato comparirà il seguente messaggio:


In questo specifico caso useremo una connessione SSH con chiave, questo metodo di autenticazione è basato sulla crittografia asimmetrica. Per utilizzarlo l'utente genera una coppia di chiavi.
<pre>Warning: Permanently added 'xxxx.xxxxx.xxxxx' (ECDSA) to the list of known hosts.</pre>
La chiave pubblica è copiata sul server, tipicamente in un apposito file nella home directory dell'utente; la chiave privata deve essere conservata dall'utente, ed è bene che sia protetta con una parola chiave (passphrase).  


Nella fase di accesso, il client SSH prova al server di essere in possesso della chiave privata, verrà quindi richiesta la passphase e in caso di successo viene consentito l'accesso.
A questo punto sarà richiesta la password dell'account remoto cui si sta tentando di accedere. Una volta inseritala comparirà il prompt dei comandi della macchina remota e l'utente potrà operare come se stesse usando una normalissima istanza del terminale del suo computer.<br/>
Per terminare una connessione è sufficiente digitare:
<pre>$ exit</pre>
eventualmente più volte se nel frattempo si è assunta l'identità di root col comando <code>su</code> (o di qualche altro utente).<br/>


=Configurazione Server=
Si noti infine che se lo username dell'utente sulla macchina client coincide con quello della macchina remota è possibile non indicare il parametro <code>username_remoto</code> e quindi limitarsi a digitare:
In questa prima parte ci soffermeremo a parlare dell'installazione e della corretta configurazione secondo le richieste prima espresse.
<pre>$ ssh host_remoto</pre>


==Installazione==
=== Server ===


L'installazione è molto semplice, basta impartire il solo comando indicato:
Non vi è nulla da configurare, già al termine dell'installazione il computer risulta pronto a ricevere connessioni. L'unico metodo di autenticazione disponibile è però quello tramite password.


<pre># aptitude install ssh</pre>
=== Note ===


Oltre al pacchetto '''ssh''' verrà installato '''openssh-blacklist''','''openssh-client''' e '''openssh-server''' .
* Quanto fin qui scritto presuppone che non vi siano firewall a bloccare le connessioni, in particolare sulla porta 22, quella utilizzata in modo predefinito da OpenSSH.
* L'autenticazione tramite password va benissimo per un ambito LAN, ma non è la scelta migliore in caso di connessioni attraverso internet. Un utente quindi che desideri avere un livello di sicurezza maggiore dovrà necessariamente optare per il meccanismo di autenticazione tramite coppia di chiavi pubblica e privata. Si badi bene che con questo non si vuol affermare che l'autenticazione tramite password sia inadeguata in senso assoluto, infatti per l'utente comune sarà di norma sufficiente, ma si vuol semplicemente rendere noto che esistono opzioni più sicure.
* L'autenticazione tramite chiavi pubblica/privata permette, volendo, di stabilire connessioni senza dover digitare alcuna password o codice di sblocco.


Dopo aver terminato l'installazione, è già possibile autenticarsi a SSH con le impostazioni di default che ora andremo a correggere .


==Porta==
{{Warningbox|Ogni qualvolta si apportano modifiche ai file di configurazione ''/etc/ssh/ssh_config'' e ''/etc/ssh/sshd_config'' è necessario riavviare il demone ssh per renderle operative.}}


La predefinita porta 22 mi andava stretta perché spesso rientra nelle scanlist, così mi prendo una porta a caso ( dopo la 1024).


A seconda del tipo di connessione è probabile sia necessario intervenire per aprirla a monte.
== Autenticazione con chiavi ==


Nel mio caso dovrò nattare la porta scelta sul router e, come esempio, userò la porta : 2974
Come già scritto il metodo di autenticazione utilizzabile fin da subito, cioè l'inserimento della password relativa all'account remoto, non è il più sicuro poiché suscettibili di attacchi a forza bruta o in ogni caso di rivelare la stessa nel caso di collegamento a server fittizi gestiti da malintenzionati.<br/>
OpenSSH supporta attualmente cinque tipi di autenticazione:
# kerberos (gssapi-with-mic), basata su un'API generica implementata su vari sistemi operativi, utilizza un protocollo che normalmente è Kerberos 5, per trasferire i dati per l'autenticazione;
# chiave client ('''hostbased'''), concettualmente simile al metodo della chiave pubblica, ma con la differenza che il server remoto verifica l'identità della macchina client e non degli utenti;
# chiave pubblica ('''publickey'''), in sintesi la macchina remota invia all'utente una stringa cifrata con una chiave pubblica precedentemente indicata dall'utente stesso, se il client dell'utente possiede la chiave privata corretta procede a decodificare tale stringa e quindi prova la sua identità al computer remoto che gli garantisce l'accesso;
# keyboard-interactive (''ChallengeResponseAuthentication''), utilizza una serie di autenticazioni caratterizzate da richieste, fatte dal server SSH, che devono essere confermate dalle risposte mandate dal client SSH. Se le risposte coincidono con quelle memorizzate sul Server, l'utente è autorizzato ad accedere da remoto alla macchina Linux altrimenti questi non può accedere alla macchina Linux. Di default avviene tramite [[PAM]], e corrisponde alla richiesta di password dell'account remoto a cui si intende accedere;
# '''password''' (''PasswordAuthentication''), si richiede la password dell'utenza indicata in fase di login per verificare se l'utente è autorizzato ad accedere a tale utenza sulla macchina remota Linux, a prescindere dalla procedura prevista per l'autenticazione sulla macchina remota.


==Utente per la connessione==
Ai fini di questa guida saranno trattate, in aggiunta all'ultimo tipo già descritto, anche le modalità ''hostbased'' e ''publickey'', tuttavia prima di procedere a descriverle nel dettaglio è bene precisare che i due metodi sono simili tra loro poiché entrambi sfruttano l'accoppiata chiave pubblica e privata per suggellare l'autenticazione dell'utente.


Sul server ho un solo utente e per giunta oltre ad avere una password fragile, ha abilitato l'uso di sudo ( che saltuariamente uso).
{{Box|Nota|Dei due metodi ''hostbased'' e ''publickey'', solo il secondo può dirsi sicuramente più sicuro di quello basato su password.


Per fornire maggior sicurezza al sistema, si dovrà creare un nuovo utente dedicato alla sola connessione SSH, a cui possiamo dare un bel nome a scelta :
Ed entrambi aggiungeranno una nuova possibilità di autenticazione, senza rimuovere quella tramite password, attiva di default. Se si intende rendere possibile l'autenticazione unicamente via chiave pubblica dell'utente oppure del client, è necessario disabilitare l'autenticazione via password ("<code>PasswordAuthentication no</code>" e, se abilitato, "<code>ChallengeResponseAuthentication no</code>") modificando il [[OpenSSH: file di configurazione | file di configurazione]].}}


<pre># adduser m3gac4mmell0</pre>
=== hostbased ===


basta seguire l'output e in pochi secondi avremo il nostro nuovo user con la sua home pulita.
Usando questa modalità non vengono autenticati i singoli utenti, ma la macchina stessa. In pratica la macchina remota controlla solo che la macchina client sia veramente chi dice di essere, ma non esegue alcun controllo sugli utenti. Superata tale verifica gli account della macchina client hanno immediatamente accesso all'account omonimo presente sulla macchina remota.


Se l'utente non ci piace e vogliamo cambiarlo, occorrerà rimuoverlo e crearne un altro.
Risulta quindi evidente come una compromissione di uno o più account della macchina client implichino necessariamente la compromissione immediata dei corrispondenti account della macchina remota. Si può dunque affermare che questa modalità di autenticazione risulta utile quando:
* sulla macchina client esistono diversi account presenti anche sulla macchina remota e tutti quanti, o buona parte di essi, necessitano di usare SSH. Si noti che tali account debbono necessariamente avere '''lo stesso nome''';
* la macchina client è considerata "assolutamente" sicura.


<pre># deluser m3gac4mmell0</pre>
{{Box|Alternative|Il server SSH in modalità autenticazione ''hostbased'' può essere anche configurato per permettere ad un singolo utente della macchina client di accedere ad utenze multiple, o perfino tutte, della macchina remota. In questa guida ci si limiterà al caso ''utente client --> utente remoto omonimo''. Se il lettore fosse interessato alle altre possibilità veda il manuale relativamente ai file <code>/etc/hosts.equiv</code> e <code>~/shosts</code>}}


==Inserire le chiavi pubbliche==
==== Generazione chiavi ====


Creare nella dir <code>/home/m3gac4mmell0/.ssh</code> il file <code>authorized_keys</code>. Se la directory non esiste, crearla con proprietario l'user prescelto:
Normalmente in fase di installazione vengono già generate automaticamente una coppia di chiavi pubblica/privata per ogni tipo di algoritmo di cifratura. Tali chiavi sono conservate in <code>/etc/ssh/</code>, insieme ai file di configurazione, e condividono tutte la parte iniziale del loro nome, ovvero ''ssh_host_''.<br/>
Digitando quindi <code>$ ls -hl /etc/ssh/ssh_host_*</code> si otterrà un elenco simile a questo:
<pre>
<pre>
  $mkdir /home/user/.ssh
-rw------- 1 root root 668 set 18 21:59 /etc/ssh/ssh_host_dsa_key
  $chmod 700 /home/user/.ssh
-rw-r--r-- 1 root root  602 set 18 21:59 /etc/ssh/ssh_host_dsa_key.pub
$cd /home/user/.ssh
-rw------- 1 root root  227 set 18 21:59 /etc/ssh/ssh_host_ecdsa_key
  $touch authorized_keys
-rw-r--r-- 1 root root 174 set 18 21:59 /etc/ssh/ssh_host_ecdsa_key.pub
  $chmod 600 authorized_keys
-rw------- 1 root root  399 set 18 21:59 /etc/ssh/ssh_host_ed25519_key
-rw-r--r-- 1 root root  94 set 18 21:59 /etc/ssh/ssh_host_ed25519_key.pub
-rw------- 1 root root  977 set 18 21:59 /etc/ssh/ssh_host_key
-rw-r--r-- 1 root root 642 set 18 21:59 /etc/ssh/ssh_host_key.pub
-rw------- 1 root root 1,7K set 18 22:00 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root 394 set 18 22:00 /etc/ssh/ssh_host_rsa_key.pub
</pre>
</pre>
Di queste cinque coppie di chiavi le uniche da considerare sono di fatto:
<pre>
-rw------- 1 root root  399 set 18 21:59 /etc/ssh/ssh_host_ed25519_key
-rw-r--r-- 1 root root  94 set 18 21:59 /etc/ssh/ssh_host_ed25519_key.pub
-rw------- 1 root root 1,7K set 18 22:00 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  394 set 18 22:00 /etc/ssh/ssh_host_rsa_key.pub
</pre>
poiché <code>ssh_host_key/ssh_host_key.pub</code> (''rsa1'') relative alla versione 1.5 di SSH e le rimanenti due (''dsa'', ''ecdsa'') sono poco sicure e/o comunque deprecate.


Prestiamo attenzione ai permessi attribuiti.
Qualora l'utente lo desiderasse è possibile eliminare le chiavi già generate e successivamente ricrearne di nuove. I comandi da usare sono:
<pre>
# rm /etc/ssh/ssh_host_*
# ssh-keygen -A
</pre>
Si noti che il comando <code>ssh-keygen -A</code> ignora l'opzione <code>-b</code>, quindi le chiavi saranno create usando il numero di bit predefinito, ad es. 2048 per RSA.


Ora inseriamo le chiavi pubbliche nel file <code>authorized_keys</code>.
{{Box|Nota|Per usare un numero di bit maggiore, ammesso che ciò sia possibile (rsa sì, ed25519 no), è necessario creare le chiavi manualmente, rinominarle correttamente e copiarle in <code>/etc/ssh/</code>. Per i dettagli si rimanda alla sezione dedicata alla modalità ''publickey'', avendo cura però di creare le chiavi usando l'utenza di ''root'' e di non specificare alcun codice di sblocco.}}


Come amante di MC e mcedit faccio la cosa maualmente, ma pare sia possibile usare un semplice comando :
==== Client ====


<pre>$ scp -P <porta> ~/.ssh/id_dsa.pub <username>@<ip del server>:~/.ssh/ authorized_keys</pre>
È necessario modificare il file <code>/etc/ssh/ssh_config</code> decommentando <code>HostbasedAuthentication</code> e indicando ''yes'' come valore, oltre ad aggiungere <code>EnableSSHKeysign yes</code>:
<pre>
[...]
#  PasswordAuthentication yes
    HostbasedAuthentication yes
    EnableSSHKeysign yes
#  GSSAPIAuthentication no
#  GSSAPIDelegateCredentials no
[...]
</pre>


Per maggiori informazioni consultare anche : ''ssh-copy-id'' e ''ssh-add''
==== Server ====


Se la modifica viene fatta con un editor di testo (''es. mcedit'') '''ATTENZIONE''' a inserire le chiavi in una singola riga.
È necessario modificare il file <code>/etc/ssh/ssdh_config</code> decommentando <code>HostbasedAuthentication</code> e indicando ''yes'' come valore, oltre ad assicurarsi che lo sia anche il parametro <code>PubkeyAuthentication</code>:
 
<pre>
==Configurazione==
[...]
 
Quella che riporto ora è la configurazione di SSH inserita nel file <code>''/etc/ssh/sshd_config''</code> .
 
<pre># Package generated configuration file
# See the sshd_config(5) manpage for details
 
# What ports, IPs and protocols we listen for
Port 2974
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
 
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
 
# Logging
SyslogFacility AUTH
LogLevel INFO
 
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
 
RSAAuthentication yes
PubkeyAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
#AuthorizedKeysFile     %h/.ssh/authorized_keys


# Don't read the user's ~/.rhosts and ~/.shosts files
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
# similar for protocol version 2
HostbasedAuthentication no
HostbasedAuthentication yes
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
[...]
#IgnoreUserKnownHosts yes
</pre>


# To enable empty passwords, change to yes (NOT RECOMMENDED)
Inserire la chiave pubblica del client <code>/etc/ssh/ssh_host_rsa_key.pub</code> nel file <code>/etc/ssh/ssh_unknown_hosts</code> (da creare se non ancora presente), avendo cura di premettere il FQDN del client e/o il suo indirizzo IP, ad esempio:
PermitEmptyPasswords no
<pre>
nomeclient.small.lan,IP_client ssh-rsa lunghissima_stringa_di_caratteri root@nomeclient
</pre>
Creare un file <code>/etc/ssh/shosts.equiv</code> in cui indicare riga per riga tutti i FQDN e/o IP dei client autorizzati a connettersi al server, ad esempio:
<pre>
nomeclient.small.lan
IP_client
</pre>


# Change to yes to enable challenge-response passwords (beware issues with
{{Suggerimento|Durante la prima configurazione usare sempre l'indirizzo IP, con o senza FQDN, per provare che tutto funzioni, infatti a chi scrive è capitato di perdere diverse ore prima di accorgersi che il non funzionamento era dovuto ad un qualche problema di risoluzione del FQDN.
# some PAM modules and threads)
* Si noti che digitare dalla macchina remota il comando <code>host ip_client</code>, è condizione necessaria, ma NON sufficiente per assicurarsi che SSH risolva correttamente i FQDN.
ChallengeResponseAuthentication no
* Controllare sempre di aver scritto correttamente il FQDN della macchina client.}}


# Change to no to disable tunnelled clear text passwords
=== publickey ===
PasswordAuthentication no


# Kerberos options
Questa modalità si basa sull'autenticazione dell'utente esattamente come per la modalità ''password'', ma per l'appunto sfruttando l'accoppiata chiave pubblica/privata.
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes


# GSSAPI options
==== Generazione chiavi ====
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes


X11Forwarding no
Il primo passo è creare le chiavi col solito <code>ssh-keygen</code>, tuttavia la procedura è leggermente diversa da quella descritta per il caso ''hostbased''. In questo caso l'utente avrà infatti facoltà di scegliere l'algoritmo di cifratura (''rsa'' è quello predefinito in Debian, mentre ''ed25519'' è il predefinito in Ubuntu), il numero di bit quando permesso dall'algoritmo scelto (solo se si sceglie un algoritmo diverso da ''rsa''), la directory dove salvare la coppia di chiavi (la destinazione predefinita è <code>~/.ssh/</code>) e se inserire o meno un codice di sblocco della chiave.
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive no
#UseLogin no


#MaxStartups 10:30:60
{{Box|Sicurezza e codice di sblocco|La sicurezza della procedura di autenticazione NON dipende in alcun modo dal codice di sblocco eventualmente scelto, infatti quest'ultimo serve solo a cifrare la propria chiave privata in modo che questa possa essere utilizzata solo dopo aver inserito correttamente il suddetto codice. Il fine è evidente, cioè impedire l'utilizzo immediato della chiave da parte di persone non autorizzate che in qualche modo siano riuscite a farsene una copia. Si noti che indicare un codice di sblocco implica il doverlo inserire ogni volta che si deve usare tale chiave.}}
#Banner /etc/issue.net


# Allow client to pass locale environment variables
Supponendo di voler creare una coppia di chiavi ''rsa'' basterà quindi digitare sulla '''macchina client''':
AcceptEnv LANG LC_*
<pre>$ ssh-keygen</pre>
Volendo invece aumentare la robustezza delle chiavi è possibile aumentare il numero di bit (e quindi anche leggermente il tempo di creazione) da 2048 a 4096:
<pre>$ ssh-keygen -b 4096</pre>
Infine per generare in debian una coppia di chiavi ''ed25519''
<pre>$ ssh-keygen -t ed25519</pre>


Subsystem sftp /usr/lib/openssh/sftp-server
Se si sono mantenuti algoritmo e locazione predefiniti digitando <code>$ ls -hl ~/.ssh/</code> si otterrà:
 
<pre>
# Set this to 'yes' to enable PAM authentication, account processing,
-rw------- 1 nomeutente gruppoutente 3,2K set 17 23:44 id_ed25519
# and session processing. If this is enabled, PAM authentication will
-rw-r--r-- 1 nomeutente gruppoutente  749 set 17 23:44 id_ed25519.pub
# be allowed through the ChallengeResponseAuthentication and
-rw-r--r-- 1 nomeutente gruppoutente 1,4K set 18 23:34 known_hosts
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no
</pre>
</pre>
Si noti che i permessi della chiave privata sono impostati a 600, cioè solo l'utente proprietario del file può accedervi.


La parte modificata per forzare l'accesso con le chiavi è di sole 3 righe:
==== Client ====
<pre>ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no</pre>
Se avete problemi basta riportare a 'yes' le opzioni sopra indicate.


Oltre alla porta cambiata come segnalato a priori, occorre decommentare la riga:
Nessuna modifica da apportare al file <code>/etc/ssh/ssh_config</code> poiché il valore predefinito della variabile <code>PubkeyAuthentication</code> risulta già essere impostato a ''yes''.
<pre>AuthorizedKeysFile %h/.ssh/authorized_keys</pre>


In più ho preferito impostare a 'no' questa:
È tuttavia necessario appendere la chiave pubblica dell'utenza sul client al file <code>~/.ssh/authorized_keys</code> della stessa utenza sulla macchina remota. Tale operazione può essere eseguita manualmente dall'utente, ad esempio copiando e incollando il contenuto della chiave pubblica nel succitato file <code>authorized_keys</code>, oppure usando il seguente comando:
<pre>X11Forwarding no</pre>
<pre>ssh-copy-id -i ~/.ssh/id_rsa.pub utenteremoto@nome_host_remoto</pre>
posto di aver utilizzato il percorso predefinito suggerito da <code>ssh-keygen</code>, diversamente sostituire tale percorso col proprio.<br/>
Si noti che usare <code>scp</code> è fattibile, tuttavia in tal caso si andrà a sovrascrivere il file <code>authorized_keys</code> cancellando quindi eventuali altre chiavi pubbliche presenti. Ad ogni modo il comando da usare in questo caso è:
<pre>$ scp ~/.ssh/id_rsa.pub utenteremoto@nome_host_remoto:~/.ssh/authorized_keys</pre>
Per collegarsi ad una macchina remota specificando una chiave privata con nome diverso da quello predefinito (cioè <code>id_ed25519</code>, <code>id_rsa</code>, ecc.), ma sempre presente in <code>~/.ssh/</code>
<pre>ssh nome_utente@nome_host -i ~/.ssh/nome_chiave_privata</pre>


* Se la sessione si blocca per inutilizzo, provare con ''TCPKeepAlive yes'' .
==== Server ====
* È possibile porre alcune restrizioni aggiuntive quali ''AllowUsers'' e ''MaxAuthTries''.


==Optional==
Nessuna modifica da apportare al file <code>/etc/ssh/sshd_config</code> poiché il valore predefinito della variabile <code>PubkeyAuthentication</code> risulta già essere impostato a ''yes''.


La seguente parte è da considerarsi opzionale anche se per la sicurezza, da parte mia, resta consigliata
Rimane in ogni caso consigliato di:
* impedire l'autenticazione con utente <code>root</code> (<code>PermitRootLogin no</code>)
* disabilitare l'autenticazione tramite password (<code>PasswordAuthentication no</code>), ma evidentemente solo dopo aver verificato che l'autenticazione tramite chiave pubblica funziona.


===Fail2ban===


[[Fail2ban | Fail2ban]] serve per limitare gli accessi indesiderati, bannando per x secondi un IP che ha superato un numero di accessi impostato.
{{Box|Nota|Se si trasferisce manualmente la chiave pubblica facendo copia ed incolla tra due editor di testo si presti ATTENZIONE a non spezzare la chiave su più righe. È infatti obbligatoria l'indicazione di '''una sola chiave per riga'''.}}
<br/>
{{Warningbox|Se non si riuscisse a collegarsi ricevendo invece il messaggio ''Permission denied (publickey)'' verificare che:
* la chiave privata usata in fase di autenticazione sia quella corretta;
* la chiave pubblica necessaria sia stata effettivamente (e correttamente) aggiunta al file <code>authorized_keys</code>;
* il file <code>~/.ssh/authorized_keys</code> sia accessibile solo e soltanto al proprietario (600);
* la home dell'utenza che si vuole usare sia scrivibile solo da essa (755, 750 o 700)}};
<br/>


Attenzione perché il ban riguarda solo la posta interessata.
== Analisi dei file di configurazione ==


Installare fail2ban è semplice :
Si veda [[OpenSSH: file di configurazione | la guida dedicata]].
<pre>#aptitude install fail2ban</pre>


Per maggiori info visitate la documentazione ufficiale, mentre per utilizzarlo come nel nostro caso interverremo operando alcune modifiche al file <code>''/etc/fail2ban/jail.conf''</code>.
<pre>#tempo di ban espresso in secondi es: 3600 = 1 ora
#un tempo corto ferma ugualmente i robot e facilità il vostro ingresso in tempi brevi in caso di errore
bantime = 14400
#Numero di tentativi massimo , prima dell'azione di ban
maxretry = 3


== Altri client OpenSSH compatibili ==


[ssh]
=== Midnight Commander ===


enabled = true
[[Midnight Commander | Midnight Commander]] può essere utile quando si devono trasferire dei file, infatti è possibile tenere aperto uno dei due pannelli su SSH e l'altro in locale sulla nostra macchina.
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 3</pre>


L'opzione <code>maxretry</code> risulta doppia dato che è possibile diversificare l'uso a seconda dei servizi utilizzati: la prima opzione è generale, la seconda sottostante al servizio indicato personalizza la singola applicazione.
Per il collegamento spostiamoci nel pannello desiderato e si scelga ''connessione Shell'' dal menu (F9).


Per fare una prova e verificare subito se tutto funziona, generiamo alcuni accessi con user sbagliato sul nostro server SSH e con il comando sotto riportato saremo subito in grado di verificare la presenza di errori.
[[Immagine:MmteamSshmc.jpeg|480px| center|MC Shell]]
<pre># fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf</pre>
 
Se avete abilitato il servizio di avviso a mezzo mail, questa sotto è una parte del messaggio che vi arriverà:
 
<pre>Hi,
 
The IP 78.xx.xx.113 has just been banned by Fail2Ban after
3 attempts against ssh.
 
whois ..............
Lines containing IP:78.xx.xx.113 in /var/log/auth.log
 
Oct 17 19:10:38 kserver sshd[23844]: Invalid user admin from 78.xx.xx.113
Oct 17 19:11:26 kserver sshd[23851]: Invalid user admin from 78.xx.xx.113
Oct 17 19:11:28 kserver sshd[23853]: Invalid user admin from 78.xx.xx.113</pre>
 
===Blockcontrol===
 
L'uso di <code>blockcontrol</code> è spiegato [http://e-zine.debianizzati.org/web-zine/numero_4/?page=82 nell'e-zine n°4], detto ciò mi limiterò ad alcune considerazioni.
 
L'unica eccezione che si aggiunge alla guida sull'e-zine riguarda l'apertura delle porte per la connessione all'interno del file di configurazione <code>''/etc/blockcontrol/blockcontrol.conf''</code>, dove inseriremo in TCP-in e TCP-out la porta impostata per SSH.
 
<pre># Do a "blockcontrol restart" (sometimes even "reload" is enough) when you have
# edited this file.
 
WHITE_TCP_OUT="2974"
WHITE_TCP_IN="2974"</pre>
 
Grazie all'aggiunta di filtri, possiamo chiudere l'accesso a diversi range di IP. Per un server consiglio il filtro proxy per ovviare al cambio IP se uno viene bannato.
 
Poi considero validi anche i filtri nazioni in cui non andrò mai e dalle quali non aspetto connessioni, come Cina, Taiwan, Korea e Russia dalle quali è più probabile ricevere connessioni malevole.
 
Per maggiori informazioni sulle liste disponibili, visitare: http://www.iblocklist.com/lists.php
 
=Configurazione Client=
Per la connessione illustrerò in pochi passaggi ciò che serve per configurare il client in ambiente Win e Linux.
 
Resta da definire il tipo di chiave, infatti è possibile scegliere tra 2 tipi di criptazione: RSA o DSA.
 
Da una semplice ricerca ho trovato poche differenze, e dai manuali ufficiali verrebbe consigliato di usare DSS (che sarebbe DSA).


{| border="1" cellpadding="20" cellspacing="0"
Al prompt inserire <code>nome_user@indirizzo_server:porta</code>, et voilà, dopo aver inserito la password si sarà dentro.
!Algorithm
!Key Generation * 1(ms.)
!Sign * 100 (ms.)
!Verify*100(ms.)
|-
|RSA 512
|544.61
|915
|160
|-
|RSA 1024
|1120.46
|4188
|263
|-
|DSA 512
|6.62
|634
|988
|-
|DSA 1024
|17.87
|1775
|3397
|}


LINK http://neubia.com/archives/000191.html
== Esempi ==


DSA offre più o meno lo stesso grado di robustezza di RSA, ma ha contro il tempo: è un algoritmo giovane, molto più di RSA. RSA è stato crittanalizzato per anni e non si è mai trovato il modo di forzarlo. DSA, essendo sulla piazza da molto meno tempo, è stato quindi studiato molto meno, e questo mi autorizza a ritenerlo meno collaudato di RSA, motivo per cui scelgo di non usarlo.
=== Cambio del numero di porta ===


Dal punto di vista delle prestazioni sono ancora una volta simili: si tratta sempre di operazioni di complessità elevatissima, ma è anche vero che con le macchine che abbiamo a disposizione oggi, considerazioni come queste, basate sulle prestazioni, lasciano un po' il tempo che trovano.
Una delle personalizzazioni più semplici che si può adottare è la modifica della porta predefinita, ovvero l'indicazione di un numero di porta differente dalla 22. Tale scelta può essere una necessità pratica, dovuta ad esempio alla necessità di collegarsi a più macchine tutte poste dietro uno stesso router/NAT, oppure un piccolo artificio per rendere un po' più difficili gli attacchi al proprio server SSH da parte di malintenzionati.


LINK https://forums.gentoo.org/viewtopic-t-486433-start-0.html
{{Box|Nota|Se si decide di cambiare numero di porta è bene ricordare che i numeri fino a 1023 sono riservati al sistema, pertanto '''l'utente dovrà scegliere sempre dei valori maggiori o uguali a 1024'''.}}


==Linux==
==== Client ====


Prepariamo la nostra chiave, che sarà composta da una chiave pubblica e una privata:
Ci sono due strade per utilizzare un numero di porta differente:
# passare il numero direttamente da riga di comando usando l'opzione <code>-p</code>;
# modificare il file di configurazione <code>/etc/ssh/ssh_config</code>
Un esempio della prima opzione è il seguente:
<pre>$ ssh utente_remoto@host_remoto -p 13462</pre>
La riga da modificare nel file di configurazione è invece quella dove compare la voce <code>'''#  Port 22'''</code>:
<pre>
<pre>
$ssh-keygen -t rsa -b 1024
[...]
#  IdentityFile ~/.ssh/id_dsa
#  Port 22
#  Protocol 2,1
[...]
</pre>
</pre>
 
È quindi sufficiente decommentare tale riga ed indicare il numero di porta desiderato, ad esempio:
Impostiamo una password robusta di almeno 6 caratteri alfa numerici se possibile.
 
Una volta creata la coppia di chiavi, dobbiamo andare a inserire la nostra chiave pubblica all'interno del file <code>authorized_keys</code> nella directory <code>/home/user_SSH/.ssh/</code> dell'utente predefinito per la connessione SSH sul server.
 
===openssh-client===
 
Fatto questo siamo pronti per provare la connessione, usando la shell dal nostro user per il quale abbiamo generato la coppia di chiavi .
<pre>$ ssh -p 2794 m3gac4mmell0@IP-server</pre>
 
Inseriamo, quando richiesta, la password usata per generare la chiave, e in pochi secondi ci troveremo all'interno del nostro server.
 
===Midnight Commander===
 
[[Midnight Commander | Midnight Commander]] può essere utile quando si devono trasferire dei file, infatti è possibile tenere aperta una delle due tab su SSH e l'altra in locale sulla nostra macchina.
 
Per il collegamento spostiamoci con F9 nella tab desiderata e scegliamo ''connessione Shell''
 
[[Immagine:MmteamSshmc.jpeg|480px| center|MC Shell]]
 
Al prompt inseriamo: ''nome_user@indirizzo_server:porta''
<pre>
<pre>
m3gac4mm3llo@IP_server:2794
[...]
#  IdentityFile ~/.ssh/id_dsa
    Port 13462
#  Protocol 2,1
[...]
</pre>
</pre>


et voilà, dopo aver inserito la password saremo dentro.
{{Box|Note|
* Tutto quanto qui scritto presuppone che l'utente abbia già configurato il server SSH della macchina remota per comunicare su una porta diversa dalla 22.
* Se l'utente modifica il file <code>/etc/ssh/ssh_config</code> indicando la stessa porta contenuta nel file <code>/etc/ssh/sshd_config</code> presente sulla macchina remota chiaramente non è necessario usare l'opzione ''-p'' da riga di comando.}}


==Windows==
==== Server ====


Consiglio putty che ho provato e uso ancora in ufficio dove sono costretto all'uso di WinXP, forse perché in una vita precedente sono stato cattivo.
Se si opta per l'utilizzo di una porta differente da quella standard è necessario specificare tale valore non solo nella configurazione del client, ma anche in quello del server operante sulla macchina remota.<br>
Si tratta cioè di editare il file <code>/etc/ssh/sshd_config</code> e modificare la voce <code>'''Port 22'''</code>:
<pre>
# Package generated configuration file
# See the sshd_config(5) manpage for details


Prestiamo attenzione oltre alla generazione delle chiavi a come viene esportata la chiave in modo che sia compatibile con openssh.
# What ports, IPs and protocols we listen for
Port 22
[...]
</pre>
per esempio in:
<pre>
# Package generated configuration file
# See the sshd_config(5) manpage for details


Finché avete aperta la finestra del generatore di chiave vi sarà possibile copiarla, altrimenti se la salvate dovrete eliminare le prime 2 righe e inserire ssh-rsa per rsa oppure ssh-dss per dsa, lasciate uno spazio vuoto e inserite in un'unica riga il testo della chiave.
# What ports, IPs and protocols we listen for
Port 13462
[...]
</pre>


[[Immagine:MmteamPutty001.JPG |320px | center]]
== Informazioni superate ==


Alla fine ci deve essere il simbolo =, la parte seguente è opzionale e potete ometterla senza problemi.
Opzionalmente è possibile installare anche il pacchetto <code>openssh-blacklist</code>


Salvate ora la chiave privata in un luogo sicuro.
<pre># apt-get install openssh-blacklist</pre>


Per la connessione indicate a putty dove risiede la vostra chiave privata .
Nelle precedenti versioni di questa guida era scritto di impostare <code>RSAAuthentication yes</code>. Oggigiorno il parametro <code>RSAAuthentication</code> è stato deprecato.


[[Immagine:Mmteamputty2.JPG |320px | center]]
== Approfondimenti ==


e nella schermata principale inserite i dati per la connessione.
=== Manpages ===


[[Immagine:MmteamPutty003.JPG |320px | center]]
* <code>man ssh</code>
* <code>man ssh_config</code>
* <code>man sshd</code>
* <code>man sshd_config</code>


Al login dovrete inserire la password impostata nella chiave.
=== Sitografia ===
 
* [https://www.openssh.com/ Pagina ufficiale]
=Conclusioni=
 
Per ora mi ritengo soddisfatto anche se la sicurezza non è mai troppa.
 
Dalla configurazione eseguita, l'accesso deve essere fatto con il nome user corretto altrimenti fail2ban interviene bannando l'IP.
 
Se il nome nella connessione è esatto, occorre avere una chiave privata che coincida con una delle chiavi pubbliche inserite sul server altrimenti la sessione vine chiusa immediatamente.
 
Nel caso ci sia stato un furto di chiavi, al login è necessario inserire la password per la chiave utilizzata.
 
 
=Link Utili=
* http://lackof.org/taggart/hacking/ssh/
* http://lackof.org/taggart/hacking/ssh/
* [http://guide.debianizzati.org/index.php/Categoria:SSH_server_e_amministrazione_remota SSH_server_e_amministrazione_remota]
* [http://users.telenet.be/mydotcom/howto/linux/sshpasswordless.htm SSH passwordless]
 
* [https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication Host based authentication]
=Note=
ritenetevi liberi di correggere e/o modificare la seguente guida, che riporta solo alcuni appunti riguardo l'esperienza svolta .


--[[Utente:Mm-barabba|Mm-barabba]] 00:55, 20 nov 2010 (CET)
{{Autori
|Autore = [[Utente:Mm-barabba|Mm-barabba]] 00:55, 20 nov 2010 (CET)
|Estesa_da =
:[[Utente:Wtf|Wtf]] 13:05, 20 set 2015 (CEST)
|Verificata_da=
:[[Utente:Wtf|Wtf]] 13:05, 20 set 2015 (CEST)
:[[Utente:HAL 9000|HAL 9000]] 13:56, 26 set 2015 (CEST)
:[[Utente:Ferdybassi|Ferdybassi]] 15:42, 12 mar 2016 (CET)
|Numero_revisori=3
}}


[[Categoria:SSH_server_e_amministrazione_remota]]
[[Categoria:SSH_server_e_amministrazione_remota]]

Versione attuale delle 17:51, 14 lug 2024

SSH

Guide correlate

Arrow right.png


Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian
OpenSSH

Sommario

Installazione

È bene premettere che se lo scopo di chi legge è solo collegarsi ad altri computer, ma non permettere la connessione a quello in uso, allora è sufficiente l'installazione del solo client (normalmente già effettuata durante l'installazione di debian), viceversa è sufficiente l'installazione del solo server. Premesso questo, per installare sia client che server digitare da terminale con privilegi di amministrazione:

# apt-get install ssh

Per installare il solo client:

# apt-get install openssh-client

Per installare il solo server:

# apt-get install openssh-server

Utilizzo base

Client

Al termine dell'installazione del client è già possibile collegarsi ad altre macchine a patto di avere già delle credenziali, ovvero username e password di un account valido, per la macchina remota cui ci si vuole connettere. È quindi sufficiente digitare:

$ ssh username_remoto@host_remoto

per iniziare il collegamento.
Si noti che host_remoto può essere un nome host, un FQDN o un indirizzo IP. Nei primi due casi il computer su cui è installato il client deve essere in grado di risolvere i nomi del computer remoto, o tramite server DNS oppure tramite file /etc/hosts.

Quando ci si collega per la prima volta ad una nuova macchina remota verrà chiesto all'utente se intende effettivamente proseguire con la procedura di autenticazione e contestualmente aggiungere la chiave pubblica della macchina remota al proprio file locale ~.ssh/known_hosts.
Il messaggio che viene stampato a video contiene "l'impronta digitale" della chiave pubblica che si andrà ad accettare, così che l'utente possa confrontarla con quella eventualmente già in suo possesso e quindi capire se la macchina remota è effettivamente quella cui l'utente vuole connettersi e NON una macchina diversa operata da qualche malintenzionato.

utente@localhost:~# ssh server@xxxx.xxxx.xxxxxx 
The authenticity of host 'xxxx.xxxxx.xxxxx (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? 

Naturalmente l'utente non è obbligato ad effettuare un simile controllo e quindi può limitarsi ad accettare "andando sulla fiducia". Sebbene potenzialmente rischioso come comportamento, il buon senso aiuta sempre in queste situazioni, quindi se l'utente si collega ad un computer della propria LAN oppure alla macchina di un noto provider, è evidente che il rischio di collegarsi ad una macchina "maligna" sarà nullo o ragionevolmente trascurabile. Una volta accettato comparirà il seguente messaggio:

Warning: Permanently added 'xxxx.xxxxx.xxxxx' (ECDSA) to the list of known hosts.

A questo punto sarà richiesta la password dell'account remoto cui si sta tentando di accedere. Una volta inseritala comparirà il prompt dei comandi della macchina remota e l'utente potrà operare come se stesse usando una normalissima istanza del terminale del suo computer.
Per terminare una connessione è sufficiente digitare:

$ exit

eventualmente più volte se nel frattempo si è assunta l'identità di root col comando su (o di qualche altro utente).

Si noti infine che se lo username dell'utente sulla macchina client coincide con quello della macchina remota è possibile non indicare il parametro username_remoto e quindi limitarsi a digitare:

$ ssh host_remoto

Server

Non vi è nulla da configurare, già al termine dell'installazione il computer risulta pronto a ricevere connessioni. L'unico metodo di autenticazione disponibile è però quello tramite password.

Note

  • Quanto fin qui scritto presuppone che non vi siano firewall a bloccare le connessioni, in particolare sulla porta 22, quella utilizzata in modo predefinito da OpenSSH.
  • L'autenticazione tramite password va benissimo per un ambito LAN, ma non è la scelta migliore in caso di connessioni attraverso internet. Un utente quindi che desideri avere un livello di sicurezza maggiore dovrà necessariamente optare per il meccanismo di autenticazione tramite coppia di chiavi pubblica e privata. Si badi bene che con questo non si vuol affermare che l'autenticazione tramite password sia inadeguata in senso assoluto, infatti per l'utente comune sarà di norma sufficiente, ma si vuol semplicemente rendere noto che esistono opzioni più sicure.
  • L'autenticazione tramite chiavi pubblica/privata permette, volendo, di stabilire connessioni senza dover digitare alcuna password o codice di sblocco.


Warning.png ATTENZIONE
Ogni qualvolta si apportano modifiche ai file di configurazione /etc/ssh/ssh_config e /etc/ssh/sshd_config è necessario riavviare il demone ssh per renderle operative.



Autenticazione con chiavi

Come già scritto il metodo di autenticazione utilizzabile fin da subito, cioè l'inserimento della password relativa all'account remoto, non è il più sicuro poiché suscettibili di attacchi a forza bruta o in ogni caso di rivelare la stessa nel caso di collegamento a server fittizi gestiti da malintenzionati.
OpenSSH supporta attualmente cinque tipi di autenticazione:

  1. kerberos (gssapi-with-mic), basata su un'API generica implementata su vari sistemi operativi, utilizza un protocollo che normalmente è Kerberos 5, per trasferire i dati per l'autenticazione;
  2. chiave client (hostbased), concettualmente simile al metodo della chiave pubblica, ma con la differenza che il server remoto verifica l'identità della macchina client e non degli utenti;
  3. chiave pubblica (publickey), in sintesi la macchina remota invia all'utente una stringa cifrata con una chiave pubblica precedentemente indicata dall'utente stesso, se il client dell'utente possiede la chiave privata corretta procede a decodificare tale stringa e quindi prova la sua identità al computer remoto che gli garantisce l'accesso;
  4. keyboard-interactive (ChallengeResponseAuthentication), utilizza una serie di autenticazioni caratterizzate da richieste, fatte dal server SSH, che devono essere confermate dalle risposte mandate dal client SSH. Se le risposte coincidono con quelle memorizzate sul Server, l'utente è autorizzato ad accedere da remoto alla macchina Linux altrimenti questi non può accedere alla macchina Linux. Di default avviene tramite PAM, e corrisponde alla richiesta di password dell'account remoto a cui si intende accedere;
  5. password (PasswordAuthentication), si richiede la password dell'utenza indicata in fase di login per verificare se l'utente è autorizzato ad accedere a tale utenza sulla macchina remota Linux, a prescindere dalla procedura prevista per l'autenticazione sulla macchina remota.

Ai fini di questa guida saranno trattate, in aggiunta all'ultimo tipo già descritto, anche le modalità hostbased e publickey, tuttavia prima di procedere a descriverle nel dettaglio è bene precisare che i due metodi sono simili tra loro poiché entrambi sfruttano l'accoppiata chiave pubblica e privata per suggellare l'autenticazione dell'utente.

Info.png Nota
Dei due metodi hostbased e publickey, solo il secondo può dirsi sicuramente più sicuro di quello basato su password.

Ed entrambi aggiungeranno una nuova possibilità di autenticazione, senza rimuovere quella tramite password, attiva di default. Se si intende rendere possibile l'autenticazione unicamente via chiave pubblica dell'utente oppure del client, è necessario disabilitare l'autenticazione via password ("PasswordAuthentication no" e, se abilitato, "ChallengeResponseAuthentication no") modificando il file di configurazione.


hostbased

Usando questa modalità non vengono autenticati i singoli utenti, ma la macchina stessa. In pratica la macchina remota controlla solo che la macchina client sia veramente chi dice di essere, ma non esegue alcun controllo sugli utenti. Superata tale verifica gli account della macchina client hanno immediatamente accesso all'account omonimo presente sulla macchina remota.

Risulta quindi evidente come una compromissione di uno o più account della macchina client implichino necessariamente la compromissione immediata dei corrispondenti account della macchina remota. Si può dunque affermare che questa modalità di autenticazione risulta utile quando:

  • sulla macchina client esistono diversi account presenti anche sulla macchina remota e tutti quanti, o buona parte di essi, necessitano di usare SSH. Si noti che tali account debbono necessariamente avere lo stesso nome;
  • la macchina client è considerata "assolutamente" sicura.
Info.png Alternative
Il server SSH in modalità autenticazione hostbased può essere anche configurato per permettere ad un singolo utente della macchina client di accedere ad utenze multiple, o perfino tutte, della macchina remota. In questa guida ci si limiterà al caso utente client --> utente remoto omonimo. Se il lettore fosse interessato alle altre possibilità veda il manuale relativamente ai file /etc/hosts.equiv e ~/shosts


Generazione chiavi

Normalmente in fase di installazione vengono già generate automaticamente una coppia di chiavi pubblica/privata per ogni tipo di algoritmo di cifratura. Tali chiavi sono conservate in /etc/ssh/, insieme ai file di configurazione, e condividono tutte la parte iniziale del loro nome, ovvero ssh_host_.
Digitando quindi $ ls -hl /etc/ssh/ssh_host_* si otterrà un elenco simile a questo:

-rw------- 1 root root  668 set 18 21:59 /etc/ssh/ssh_host_dsa_key
-rw-r--r-- 1 root root  602 set 18 21:59 /etc/ssh/ssh_host_dsa_key.pub
-rw------- 1 root root  227 set 18 21:59 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r-- 1 root root  174 set 18 21:59 /etc/ssh/ssh_host_ecdsa_key.pub
-rw------- 1 root root  399 set 18 21:59 /etc/ssh/ssh_host_ed25519_key
-rw-r--r-- 1 root root   94 set 18 21:59 /etc/ssh/ssh_host_ed25519_key.pub
-rw------- 1 root root  977 set 18 21:59 /etc/ssh/ssh_host_key
-rw-r--r-- 1 root root  642 set 18 21:59 /etc/ssh/ssh_host_key.pub
-rw------- 1 root root 1,7K set 18 22:00 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  394 set 18 22:00 /etc/ssh/ssh_host_rsa_key.pub

Di queste cinque coppie di chiavi le uniche da considerare sono di fatto:

-rw------- 1 root root  399 set 18 21:59 /etc/ssh/ssh_host_ed25519_key
-rw-r--r-- 1 root root   94 set 18 21:59 /etc/ssh/ssh_host_ed25519_key.pub
-rw------- 1 root root 1,7K set 18 22:00 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  394 set 18 22:00 /etc/ssh/ssh_host_rsa_key.pub

poiché ssh_host_key/ssh_host_key.pub (rsa1) relative alla versione 1.5 di SSH e le rimanenti due (dsa, ecdsa) sono poco sicure e/o comunque deprecate.

Qualora l'utente lo desiderasse è possibile eliminare le chiavi già generate e successivamente ricrearne di nuove. I comandi da usare sono:

# rm /etc/ssh/ssh_host_*
# ssh-keygen -A

Si noti che il comando ssh-keygen -A ignora l'opzione -b, quindi le chiavi saranno create usando il numero di bit predefinito, ad es. 2048 per RSA.

Info.png Nota
Per usare un numero di bit maggiore, ammesso che ciò sia possibile (rsa sì, ed25519 no), è necessario creare le chiavi manualmente, rinominarle correttamente e copiarle in /etc/ssh/. Per i dettagli si rimanda alla sezione dedicata alla modalità publickey, avendo cura però di creare le chiavi usando l'utenza di root e di non specificare alcun codice di sblocco.


Client

È necessario modificare il file /etc/ssh/ssh_config decommentando HostbasedAuthentication e indicando yes come valore, oltre ad aggiungere EnableSSHKeysign yes:

[...]
#   PasswordAuthentication yes
    HostbasedAuthentication yes
    EnableSSHKeysign yes
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
[...]

Server

È necessario modificare il file /etc/ssh/ssdh_config decommentando HostbasedAuthentication e indicando yes come valore, oltre ad assicurarsi che lo sia anche il parametro PubkeyAuthentication:

[...]
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
# similar for protocol version 2
HostbasedAuthentication yes
[...]

Inserire la chiave pubblica del client /etc/ssh/ssh_host_rsa_key.pub nel file /etc/ssh/ssh_unknown_hosts (da creare se non ancora presente), avendo cura di premettere il FQDN del client e/o il suo indirizzo IP, ad esempio:

nomeclient.small.lan,IP_client ssh-rsa lunghissima_stringa_di_caratteri root@nomeclient

Creare un file /etc/ssh/shosts.equiv in cui indicare riga per riga tutti i FQDN e/o IP dei client autorizzati a connettersi al server, ad esempio:

nomeclient.small.lan
IP_client
Bulb.png Suggerimento
Durante la prima configurazione usare sempre l'indirizzo IP, con o senza FQDN, per provare che tutto funzioni, infatti a chi scrive è capitato di perdere diverse ore prima di accorgersi che il non funzionamento era dovuto ad un qualche problema di risoluzione del FQDN.
  • Si noti che digitare dalla macchina remota il comando host ip_client, è condizione necessaria, ma NON sufficiente per assicurarsi che SSH risolva correttamente i FQDN.
  • Controllare sempre di aver scritto correttamente il FQDN della macchina client.


publickey

Questa modalità si basa sull'autenticazione dell'utente esattamente come per la modalità password, ma per l'appunto sfruttando l'accoppiata chiave pubblica/privata.

Generazione chiavi

Il primo passo è creare le chiavi col solito ssh-keygen, tuttavia la procedura è leggermente diversa da quella descritta per il caso hostbased. In questo caso l'utente avrà infatti facoltà di scegliere l'algoritmo di cifratura (rsa è quello predefinito in Debian, mentre ed25519 è il predefinito in Ubuntu), il numero di bit quando permesso dall'algoritmo scelto (solo se si sceglie un algoritmo diverso da rsa), la directory dove salvare la coppia di chiavi (la destinazione predefinita è ~/.ssh/) e se inserire o meno un codice di sblocco della chiave.

Info.png Sicurezza e codice di sblocco
La sicurezza della procedura di autenticazione NON dipende in alcun modo dal codice di sblocco eventualmente scelto, infatti quest'ultimo serve solo a cifrare la propria chiave privata in modo che questa possa essere utilizzata solo dopo aver inserito correttamente il suddetto codice. Il fine è evidente, cioè impedire l'utilizzo immediato della chiave da parte di persone non autorizzate che in qualche modo siano riuscite a farsene una copia. Si noti che indicare un codice di sblocco implica il doverlo inserire ogni volta che si deve usare tale chiave.


Supponendo di voler creare una coppia di chiavi rsa basterà quindi digitare sulla macchina client:

$ ssh-keygen

Volendo invece aumentare la robustezza delle chiavi è possibile aumentare il numero di bit (e quindi anche leggermente il tempo di creazione) da 2048 a 4096:

$ ssh-keygen -b 4096

Infine per generare in debian una coppia di chiavi ed25519

$ ssh-keygen -t ed25519

Se si sono mantenuti algoritmo e locazione predefiniti digitando $ ls -hl ~/.ssh/ si otterrà:

-rw------- 1 nomeutente gruppoutente 3,2K set 17 23:44 id_ed25519
-rw-r--r-- 1 nomeutente gruppoutente  749 set 17 23:44 id_ed25519.pub
-rw-r--r-- 1 nomeutente gruppoutente 1,4K set 18 23:34 known_hosts

Si noti che i permessi della chiave privata sono impostati a 600, cioè solo l'utente proprietario del file può accedervi.

Client

Nessuna modifica da apportare al file /etc/ssh/ssh_config poiché il valore predefinito della variabile PubkeyAuthentication risulta già essere impostato a yes.

È tuttavia necessario appendere la chiave pubblica dell'utenza sul client al file ~/.ssh/authorized_keys della stessa utenza sulla macchina remota. Tale operazione può essere eseguita manualmente dall'utente, ad esempio copiando e incollando il contenuto della chiave pubblica nel succitato file authorized_keys, oppure usando il seguente comando:

ssh-copy-id -i ~/.ssh/id_rsa.pub utenteremoto@nome_host_remoto

posto di aver utilizzato il percorso predefinito suggerito da ssh-keygen, diversamente sostituire tale percorso col proprio.
Si noti che usare scp è fattibile, tuttavia in tal caso si andrà a sovrascrivere il file authorized_keys cancellando quindi eventuali altre chiavi pubbliche presenti. Ad ogni modo il comando da usare in questo caso è:

$ scp ~/.ssh/id_rsa.pub utenteremoto@nome_host_remoto:~/.ssh/authorized_keys

Per collegarsi ad una macchina remota specificando una chiave privata con nome diverso da quello predefinito (cioè id_ed25519, id_rsa, ecc.), ma sempre presente in ~/.ssh/

ssh nome_utente@nome_host -i ~/.ssh/nome_chiave_privata

Server

Nessuna modifica da apportare al file /etc/ssh/sshd_config poiché il valore predefinito della variabile PubkeyAuthentication risulta già essere impostato a yes.

Rimane in ogni caso consigliato di:

  • impedire l'autenticazione con utente root (PermitRootLogin no)
  • disabilitare l'autenticazione tramite password (PasswordAuthentication no), ma evidentemente solo dopo aver verificato che l'autenticazione tramite chiave pubblica funziona.


Info.png Nota
Se si trasferisce manualmente la chiave pubblica facendo copia ed incolla tra due editor di testo si presti ATTENZIONE a non spezzare la chiave su più righe. È infatti obbligatoria l'indicazione di una sola chiave per riga.


Warning.png ATTENZIONE
Se non si riuscisse a collegarsi ricevendo invece il messaggio Permission denied (publickey) verificare che:
  • la chiave privata usata in fase di autenticazione sia quella corretta;
  • la chiave pubblica necessaria sia stata effettivamente (e correttamente) aggiunta al file authorized_keys;
  • il file ~/.ssh/authorized_keys sia accessibile solo e soltanto al proprietario (600);
  • la home dell'utenza che si vuole usare sia scrivibile solo da essa (755, 750 o 700)


Analisi dei file di configurazione

Si veda la guida dedicata.


Altri client OpenSSH compatibili

Midnight Commander

Midnight Commander può essere utile quando si devono trasferire dei file, infatti è possibile tenere aperto uno dei due pannelli su SSH e l'altro in locale sulla nostra macchina.

Per il collegamento spostiamoci nel pannello desiderato e si scelga connessione Shell dal menu (F9).

MC Shell

Al prompt inserire nome_user@indirizzo_server:porta, et voilà, dopo aver inserito la password si sarà dentro.

Esempi

Cambio del numero di porta

Una delle personalizzazioni più semplici che si può adottare è la modifica della porta predefinita, ovvero l'indicazione di un numero di porta differente dalla 22. Tale scelta può essere una necessità pratica, dovuta ad esempio alla necessità di collegarsi a più macchine tutte poste dietro uno stesso router/NAT, oppure un piccolo artificio per rendere un po' più difficili gli attacchi al proprio server SSH da parte di malintenzionati.

Info.png Nota
Se si decide di cambiare numero di porta è bene ricordare che i numeri fino a 1023 sono riservati al sistema, pertanto l'utente dovrà scegliere sempre dei valori maggiori o uguali a 1024.


Client

Ci sono due strade per utilizzare un numero di porta differente:

  1. passare il numero direttamente da riga di comando usando l'opzione -p;
  2. modificare il file di configurazione /etc/ssh/ssh_config

Un esempio della prima opzione è il seguente:

$ ssh utente_remoto@host_remoto -p 13462

La riga da modificare nel file di configurazione è invece quella dove compare la voce # Port 22:

[...]
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
[...]

È quindi sufficiente decommentare tale riga ed indicare il numero di porta desiderato, ad esempio:

[...]
#   IdentityFile ~/.ssh/id_dsa
    Port 13462
#   Protocol 2,1
[...]
Info.png Note
  • Tutto quanto qui scritto presuppone che l'utente abbia già configurato il server SSH della macchina remota per comunicare su una porta diversa dalla 22.
  • Se l'utente modifica il file /etc/ssh/ssh_config indicando la stessa porta contenuta nel file /etc/ssh/sshd_config presente sulla macchina remota chiaramente non è necessario usare l'opzione -p da riga di comando.


Server

Se si opta per l'utilizzo di una porta differente da quella standard è necessario specificare tale valore non solo nella configurazione del client, ma anche in quello del server operante sulla macchina remota.
Si tratta cioè di editare il file /etc/ssh/sshd_config e modificare la voce Port 22:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
[...]

per esempio in:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 13462
[...]

Informazioni superate

Opzionalmente è possibile installare anche il pacchetto openssh-blacklist

# apt-get install openssh-blacklist

Nelle precedenti versioni di questa guida era scritto di impostare RSAAuthentication yes. Oggigiorno il parametro RSAAuthentication è stato deprecato.

Approfondimenti

Manpages

  • man ssh
  • man ssh_config
  • man sshd
  • man sshd_config

Sitografia




Guida scritta da: Mm-barabba 00:55, 20 nov 2010 (CET) Swirl-auth80.png Debianized 80%
Estesa da:
Wtf 13:05, 20 set 2015 (CEST)
Verificata da:
Wtf 13:05, 20 set 2015 (CEST)
HAL 9000 13:56, 26 set 2015 (CEST)
Ferdybassi 15:42, 12 mar 2016 (CET)

Verificare ed estendere la guida | Cos'è una guida Debianized