OpenSSH
|
Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.
Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione. |
 Versioni Compatibili Debian 5 "lenny" Debian 6 "squeeze" Debian 7 "wheezy" |
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:
# aptitude install ssh
Per installare il solo client:
# aptitude install openssh-client
Per installare il solo server:
# aptitude install openssh-server
Opzionalmente è possibile installare anche il pacchetto openssh-blacklist
# aptitude install openssh-blacklist
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. 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 accettata la chiave pubblica remota viene richiesta la password dell'account remoto cui si sta tentando di accedere. Una volta inseritala comprarirà 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.
Utilizzo avanzato
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.
|
Nota Se si decide di cambiare numero di porta è bene ricordare che i numeri fino a 1024 sono riservati al sistema, pertanto l'utente dovrà scegliere sempre dei valori maggiori di 1024. |
Client
Ci sono due strade per utilizzare un numero di porta differente:
- passare il numero direttamente da riga di comando usando l'opzione
-p; - 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 [...]
È sufficiente decommentare tale riga ed indicare il numero di porta desiderato, ad esempio:
[...]
# IdentityFile ~/.ssh/id_dsa
Port 13462
# Protocol 2,1
[...]
Naturalmente 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.
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 [...]
Metodi di autenticazione
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:
- kerberos (gssapi-with-mic)
- chiave client (hostbased)
- chiave pubblica (publickey)
- keyboard-interactive
- password
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.
|
|
Nota Dei due metodi hostbased e publickey, solo il secondo può dirsi sicuramente più sicuro di quello basato su password. |
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.
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. Per usare un numero di bit maggiore, ammesso che ciò sia possibile (rsa sì, ed25519 no), è necessario crearle manualmente (si veda la sezione dedicata al metodo publickey) e quindi rinominarle correttamente e copiarle in /etc/ssh/.
Client
È necessario modificare il file /etc/ssh/ssh_config come segue:
[...]
# RSAAuthentication yes
# PasswordAuthentication yes
HostbasedAuthentication yes
EnableSSHKeysign yes
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
[...]
Inserire le chiavi pubbliche
|
ATTENZIONE Per la generazione delle chiavi di autenticazione fate riferimento a questa altra guida: |
Creare nella dir /home/m3gac4mmell0/.ssh il file authorized_keys. Se la directory non esiste, crearla con proprietario l'user prescelto:
$ mkdir /home/user/.ssh $ chmod 700 /home/user/.ssh $ cd /home/user/.ssh $ touch authorized_keys $ chmod 600 authorized_keys
Prestiamo attenzione ai permessi attribuiti.
Ora inseriamo le chiavi pubbliche nel file authorized_keys.
Come amante di MC e mcedit faccio la cosa manualmente, ma pare sia possibile usare un semplice comando:
$ scp -P <porta> ~/.ssh/id_rsa.pub <username>@<ip del server>:~/.ssh/authorized_keys
Per maggiori informazioni consultare anche : ssh-copy-id e ssh-add
Se la modifica viene fatta con un editor di testo (es. mcedit) ATTENZIONE a inserire le chiavi in una singola riga.
Configurazione
Quella che riporto ora è la configurazione di SSH inserita nel file /etc/ssh/sshd_config .
# 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 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 RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords PasswordAuthentication no # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding no X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive no #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # 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
La parte modificata per forzare l'accesso con le chiavi è di sole 3 righe:
ChallengeResponseAuthentication no PasswordAuthentication no UsePAM no
Se avete problemi basta riportare a 'yes' le opzioni sopra indicate.
Oltre alla porta cambiata come segnalato a priori, occorre decommentare la riga:
AuthorizedKeysFile %h/.ssh/authorized_keys
In più ho preferito impostare a 'no' questa:
X11Forwarding no
- Se la sessione si blocca per inutilizzo, provare con TCPKeepAlive yes .
- È possibile porre alcune restrizioni aggiuntive quali AllowUsers e MaxAuthTries.
Optional
La seguente parte è da considerarsi opzionale anche se per la sicurezza, da parte mia, resta consigliata
Fail2ban
Fail2ban serve per limitare gli accessi indesiderati, bannando per x secondi un IP che ha superato un numero di accessi impostato.
Attenzione perché il ban riguarda solo la porta interessata.
Installare fail2ban è semplice :
# aptitude install fail2ban
Per maggiori info visitate la documentazione ufficiale, mentre per utilizzarlo come nel nostro caso interverremo operando alcune modifiche al file /etc/fail2ban/jail.conf.
#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 [ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3
L'opzione maxretry 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 ciò che riguarda la riga:
port = ssh
"ssh" va sostituito con la porta scelta in precedenza (vedi il paragrafo Porta). Nel caso si lasci "ssh", il ban avverrà sulla porta di default di SSH (porta 22).
Per cui, continuando a seguire la configurazione descritta in questa guida, la riga va modificata con:
port = 2974
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.
# fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
Se avete abilitato il servizio di avviso a mezzo mail, questa sotto è una parte del messaggio che vi arriverà:
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
Blockcontrol
L'uso di blockcontrol è spiegato 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 /etc/blockcontrol/blockcontrol.conf, dove inseriremo in TCP-in e TCP-out la porta impostata per SSH.
# Do a "blockcontrol restart" (sometimes even "reload" is enough) when you have # edited this file. WHITE_TCP_OUT="2974" WHITE_TCP_IN="2974"
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.
Se si fa una ricerca sul web del tipo "RSA vs DSA" pioveranno un sacco di opinioni più o meno contrastanti ma soprattutto vecchie che riguardano spesso la velocità nel produrre la chiave, verificarla o firmare.
| 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://web.archive.org/web/http://neubia.com/archives/000191.html
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.
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.
C'è inoltre da aggiungere che in passatto RSA era coperto da brevetti e per questo molti consigliavano DSA, ma questi sono scaduti il 21 Settembre del 2000.
La lunghezza di una chiave RSA è modificabile e in modo predefinito è lunga il doppio di una DSA, che invece deve essere specificatamente di 1024 bit. Lo stesso ssh-keygen, se non diversamente specificato, crea di default una chiave RSA a 2048 bit.
Dalla Debian Reference:
«L'uso di una chiave DSA per SSH-2 è deprecato perché la chiave è più piccola e più lenta. Non esistono più motivi per aggirare i brevetti RSA usando DSA, dato che essi sono scaduti.»
Linux
Prepariamo la nostra chiave, che sarà composta da una chiave pubblica e una privata:
$ ssh-keygen
Impostiamo una password robusta di almeno 6 caratteri alfanumerici se possibile.
Una volta creata la coppia di chiavi, dobbiamo andare a inserire la nostra chiave pubblica all'interno del file authorized_keys nella directory /home/<utente_SSH>/.ssh/ dell'utente predefinito per la connessione SSH sul server.
|
Suggerimento Un trucco per evitare che la connessione termini per inutilizzo è inserire in /etc/ssh/ssh_config sulla macchina client ServerAliveInterval 20 il tempo é espresso in secondi e ci permette di non far cadere la connessione |
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 .
$ ssh -p 2794 m3gac4mmell0@IP-server
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 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 scegliamo connessione Shell dal menu (F9).
Al prompt inseriamo: nome_user@indirizzo_server:porta
m3gac4mm3llo@IP_server:2794
et voilà, dopo aver inserito la password saremo dentro.
Windows
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.
Prestiamo attenzione oltre alla generazione delle chiavi a come viene esportata la chiave in modo che sia compatibile con openssh.
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.
Alla fine ci deve essere il simbolo =, la parte seguente è opzionale e potete ometterla senza problemi.
Salvate ora la chiave privata in un luogo sicuro.
Per la connessione indicate a putty dove risiede la vostra chiave privata .
e nella schermata principale inserite i dati per la connessione.
Al login dovrete inserire la password impostata nella chiave.
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
Note
ritenetevi liberi di correggere e/o modificare la seguente guida, che riporta solo alcuni appunti riguardo l'esperienza svolta .
| Guida scritta da: Mm-barabba 00:55, 20 nov 2010 (CET) |  Debianized 20%
|
| Estesa da: | |
| Verificata da: | |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |