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"

Premessa

Da diverso tempo i server dell'MM Team hanno raggiunto una buona stabilità, e gli uptime lunghi e le poche operazioni di manutenzione hanno portato fisicamente le macchine fuori dai piedi, con l'avvio senza KDM.
Ora però resta da risolvere come effettuare la periodiche sessioni di aggiornamento.
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.
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.
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.

Configurazione Server

In questa prima parte ci soffermeremo a parlare dell'installazione e della corretta configurazione secondo le richieste prima espresse.

Installazione

L'installazione è molto semplice, basta impartire il solo comando indicato:

# aptitude install ssh

Oltre al pacchetto ssh verrà installato openssh-blacklist,openssh-client e openssh-server .

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

Porta

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.

Nel mio caso dovrò nattare la porta scelta sul router e, come esempio, userò la porta : 2974

Utente per la connessione

Sul server ho un solo utente e per giunta oltre ad avere una password fragile, ha abilitato l'uso di sudo ( che saltuariamente uso).

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 :

# adduser m3gac4mmell0

basta seguire l'output e in pochi secondi avremo il nostro nuovo user con la sua home pulita.

Se l'utente non ci piace e vogliamo cambiarlo, occorrerà rimuoverlo e crearne un altro.

# deluser m3gac4mmell0

Inserire le chiavi pubbliche

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 posta 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 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.

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.

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

• http://lackof.org/taggart/hacking/ssh/
• SSH_server_e_amministrazione_remota

Note

ritenetevi liberi di correggere e/o modificare la seguente guida, che riporta solo alcuni appunti riguardo l'esperienza svolta .

--Mm-barabba 00:55, 20 nov 2010 (CET)