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" Debian 8 "jessie" |
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.
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 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.
|
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. |
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), 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, 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;
- password, 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.
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.
|
|
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.
|
|
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:
[...]
# RSAAuthentication 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 siano anche i parametri RSAAuthentication e PubkeyAuthentication:
[...] 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 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
|
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.
|
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), il numero di bit quando permesso dall'algoritmo scelto, la directory dove salvare la coppia di chiavi (la destinazione predefinita è ~/.ssh/) e se inserire o meno un codice di sblocco della chiave.
|
|
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:
$ ssh-keygen
Se invece si vuole aumentare la robustezza delle chiavi è possibile aumentarne il numero di bit (e quindi anche leggermente il tempo di creazione) da 2048 a 4096:
$ ssh-keygen -b 4096
Per creare una coppia di chiavi basata sull'algoritmo 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_rsa -rw-r--r-- 1 nomeutente gruppoutente 749 set 17 23:44 id_rsa.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é i valori predefiniti delle variabili RSAAuthentication e PubkeyAuthentication risultano già essere impostati a yes.
Server
Nessuna modifica da apportare al file /etc/ssh/sshd_config poiché i valori predefiniti delle variabili RSAAuthentication e PubkeyAuthentication risultano già essere impostati 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@nomeremoto
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@nomeremoto:~/.ssh/authorized_keys
|
|
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. |
Analisi di /etc/ssh/sshd_config
La sua struttura è molto intuitiva, però potrebbe valer la pena osservare alcune opzioni:
| Port <Numero porta d'ascolto> | Il valore di questa keyword indica la porta d'ascolto dell'OpenSSH Server, il cui valore predefinito è 22. Per questioni di sicurezza e per evitare che il nostro server SSH possa essere trovato da un portscan occasionale è consigliato cambiarla, scegliendone una superiore alla 1024 che non sia già usato da altri servizi locali o di Internet, poiché le porte fino alla 1024 sono riservate per servizi noti. |
| Protocol 2 | Indica il protocollo da utilizzare. Possono essere indicati 1 o 2 o entrambi, separandoli con la virgola (1,2), tuttavia per motivi di sicurezza non è consigliato permettere connessioni con il protocollo 1. |
| PermitRootLogin no | Il valore di questa keyword evita l'accesso come root da remoto con una sola autenticazione. Ciò garantisce maggior sicurezza alla vostra Linux-Box poiché, se si volesse accedere come root, sarebbe necessario prima autenticarsi come utente normale per poi autenticarsi come root tramite il comando su. In altre parole, con questa keyword impostata su no, chi volesse accedere come root da remoto, dovrebbe autenticarsi due volte anziché una. |
| PasswordAuthentication yes | Il valore di questa keyword permette l'autenticazione mediante un semplice Login (Username e Password) da remoto. |
| KerberosAuthentication no | Il valore di questa keyword evita che la password fornita mediante l'autenticazione tramite password sia convalidata dal KDC (Kerberos Key Distribution Center). |
| PermitEmptyPasswords no | Il valore di questa keyword evita che l'autenticazione mediante un semplice Login remoto avvenga senza la richiesta di una password se la keyword PasswordAuthentication è impostata sul yes. |
| ChallengeResponseAuthentication no | Il valore di questa keyword non permette l'autenticazione mediante richieste-risposte ben precise fra il server ed il client SSH. |
| PubkeyAuthentication yes | Il valore di questa keyword permette l'autenticazione mediante una coppia di chiavi, una pubblica, memorizzata sul server, ed una privata salvata sul client. |
| AuthorizedKeysFile <File chiavi pubbliche> | Il valore di questa keyword è il nome del file in cui vengono memorizzate le chiavi pubbliche degli utenti remoti che servono per verificare se una di queste derivi dalla chiave privata memorizzata dal client SSH che cerca di effettuare una connessione SSH utilizzando un'autenticazione a chiave pubblica. Logicamente, tale keyword viene considerata soltanto se la keyword PubkeyAuthentication è impostata su yes. Il valore di tale keyword deve contenere il path assoluto o relativo di questo file compreso il nome stesso (il valore di default è .ssh/authorized_keys). Normalmente, il path assoluto si usa quando il gestore del Server vuole tenere sott'occhio un unico file (che può anche essere memorizzato, per motivi di sicurezza, su un'altra macchina); mentre il path relativo alla home directory di ogni utente remoto viene, normalmente, usato per far sì che ogni utente gestisca lui stesso il file mettendo una o più delle sue chiavi pubbliche.
|
| GSSAPIAuthentication no | Il valore di questa keyword non permette l'autenticazione utilizzando l'API GSSAPI. |
| Ciphers aes256-cbc,aes256-ctr,3des-cbc | Il valore di questa keyword permette di scegliere quali algoritmi simmetrici verranno usati per cifrare i dati trasferiti. Siccome l'utente del client SSH o il client stesso possono decidere quale sarà l'algoritmo simmetrico da utilizzare per l'intera sessione di lavoro, conviene "obbligare" l'utente o il client SSH a scegliere gli algoritmi che garantiscono la massima sicurezza con un occhio di riguardo alla velocità di trasferimento dei dati fra il server ed il client (e viceversa). |
| ClientAliveInterval 60 | Il valore di questa keyword imposta il numero di secondi dopo i quali, se da un client SSH remoto non viene inviato al server SSH alcun dato, tale server invia un messaggio di verifica, nel canale criptato, dell'ancora esistenza del client (detto alive message) ed aspetta una risposta. Se tale risposta non arriva, interviene la keyword ClientAliveCountMax. |
| ClientAliveCountMax 3 | Il valore di questa keyword indica quante volte mandare un alive message, sempre nel canale criptato, al client SSH che non risponde. Se, dopo l'ultima richiesta "di vita", il client SSH non risponde, il server SSH termina la connessione con quel client. Quindi, impostando correttamente i valori delle keyword ClientAliveInterval e ClientAliveCountMax si evita il sovraccarico del vostro server (con un risparmio delle sue risposte) impostando una disconnessione automatica del client da parte del Server ogni 180 (60·3) secondi. |
| TCPKeepAlive no | Il valore di questa keyword non permette di mandare dei TCP keepalive message per verificare se la rete è caduta o se il client SSH remoto è andato in crash. Poiché i TCP keepalive message non vengono mandati nel canale criptato e possono contenere delle informazioni sensibili, si preferisce disabilitare questa tecnica di analisi sullo stato delle connessioni SSH usufruendo delle keyword ClientAliveInterval e ClientAliveCountMax per eliminare le connessioni SSH non più utilizzate. |
| Subsystem subname subcommand | Il valore di questa keyword permette di configurare un sottosistema esterno, come un server FTP, da avviare insieme al servizio SSH. Di base nessun sistema è indicato, tuttavia se l'utente lo desiderasse potrebbe dichiarare qualcosa di simile a Subsystem sftp /usr/lib/openssh/sftp-server.
|
| ListenAddress 0.0.0.0 | Di default è 0.0.0.0 e indica che il demone SSH è in ascolto su tutte le interfacce di rete configurate e tutti gli indirizzi IP associati. Potrebbe essere utile cambiarlo con l’indirizzo IP specifico sul quale ci si aspettiamo connessioni SSH |
| HostKey /etc/ssh/ssh_host_key | Specifica la posizione che contiene le chiavi private di un host e può essere lasciato il valore di default. Possono essere specificati più file ripetendo HostKey e cambiando il file di destinazione |
| UsePrivilegeSeparation yes | yes è il valore di default, e indica che per ogni login viene creato un processo figlio con i privilegi dell’user che ha effettuato il login per evitare tecniche di “privilege escalation” basati sui privilegi dei processi |
| ServerKeyBits 1024 | Dice quanti bit devono essere utilizzati per la creazione della chiave di criptazione della connessione. Si preferisce di solito utilizzare 1024 che è un buon compromesso tra velocità ed efficacia di crittazione. |
| LoginGraceTime 120 | Rappresenta il tempo massimo in secondi che intercorre tra il momento in cui viene stabilita la connessione e quello in cui avviene un login con successo. |
| KeyRegenerationInterval 3600 | Rappresenta il massimo tempo in secondi che il demone aspetta prima di rigenerare una nuova chiave per la connessione corrente. Non deve essere eccessivamente elevato per evitare il cracking della chiave utilizzata nella sessione corrente |
| IgnoreRhosts yes | Dichiara di ignorare i file rhosts e shosts per l’autenticazione.
|
| IgnoreUserKnownHosts yes | Dice al daemon di ignorare la lista degli hosts conosciuti presente in $HOME/.ssh/known_hosts durante la RhostsRSAAuthentication.
|
| StrictModes yes | Serve per proteggere i file nelle home degli user che di solito vengono lasciati “world-writable”. |
| X11Forwarding no | Permette di disabilitare o abilitare il forwarding su X11. Se non abbiamo una GUI installata nel server (di solito è così) possiamo settarlo su no. |
| PrintMotd yes | Abilita la visualizzazione di /etc/motd a login avvenuto.
|
| IgnoreUserKnownHost yes | Ignora l’utilizzo di ~/.ssh/known_host e per il login si basa unicamente su user e password
|
| SyslogFacility AUTH LogLevel INFO |
Indicano il grado di prolissità dei log. I valori possibili sono QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3. Utilizzare un flag di DEBUG viola la privacy degli utenti e pertanto non è consigliato |
| RSAAuthentication yes | Indica se sono concessi i login con solo RSA |
| AllowUsers user1 user2 | Permette il login via SSH solo agli user specificati. Da notare che gli user sono separati da spazi vuoti, quindi niente virgole o punti o altro |
| AllowGroups group1 group2 | Permette il login via SSH solo ai gruppi specificati. Da notare che i gruppi sono separati da spazi vuoti, quindi niente virgole o punti o altro |
Strumenti complementari opzionali
Fail2ban
Questo strumento serve per limitare gli accessi indesiderati, bandendo per "X" secondi un IP che ha superato un numero di accessi impostato.
|
|
ATTENZIONE
|
Per maggiori informazioni sull'uso di tale applicativo si rimanda alla documentazione ufficiale o alla guida presente sul wiki di debianizzati.
Per fare una prova e verificare subito se tutto funziona è possibile seguire le istruzioni indicate nella sezione Prova 2 della precedente guida, avendo cura di usare la seguente riga di comando invece di quella mostrata (relativa a proftp):
# fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
Moblock
|
|
ATTENZIONEmoblock blockcontrol mobloquer sono ormai considerati deprecati, si usi invece PeerGuardian Linux
|
L'uso di blockcontrol è spiegato nell'e-zine n°4 e nella guida Moblock - mobloquer, quindi ci si 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 sarà inserito 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, è possibile chiudere l'accesso a diversi range di IP. Per un server si consiglia il filtro proxy per ovviare al cambio IP se qualcuno viene bandito.
Si considerino inoltre validi anche i filtri nazioni in cui non ci si recherà mai e dalle quali non ci si 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
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).
Al prompt inserire nome_user@indirizzo_server:porta, et voilà, dopo aver inserito la password si sarà dentro.
PuTTY (Windows)
Prestare attenzione oltre alla generazione delle chiavi a come viene esportata la chiave in modo che sia compatibile con openssh.
Finché è aperta la finestra del generatore di chiave sarà possibile copiarla, altrimenti se la si salva sarà necessario eliminare le prime due righe ed inserire ssh-rsa per rsa oppure ssh-dss per dsa, quindi lasciare uno spazio vuoto e inserire in un'unica riga il testo della chiave.
Alla fine ci deve essere il simbolo =, la parte seguente è opzionale e potete ometterla senza problemi.
Salvare ora la chiave privata in un luogo sicuro.
Per la connessione indicare a putty dove risiede la propria chiave privata .
e nella schermata principale inserire i dati per la connessione.
Al login inserire la password impostata nella chiave.
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.
|
|
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 [...]
È quindi sufficiente decommentare tale riga ed indicare il numero di porta desiderato, ad esempio:
[...]
# IdentityFile ~/.ssh/id_dsa
Port 13462
# Protocol 2,1
[...]
|
|
Note
|
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 [...]
Approfondimenti
Manpages
man sshman ssh_configman sshdman sshd_config
Sitografia
| Guida scritta da: Mm-barabba 00:55, 20 nov 2010 (CET) |  Debianized 40%
|
Estesa da:
| |
Verificata da:
| |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |