greyfox.imente.org • software, codice e crittografia

HomeCodiceCrittografiaFotografiaLinuxSoftware
PhotoblogNewsAboutLicenzeLinks

Linux

  • Bash scripting
  • Gentoo
  • Gestione servizi
  • Hardware
  • Personalizzare
  • Utilità

Ricerca

Newsfeed

Sito: RSS / Atom
Linux: RSS / Atom

Statistiche

Visitatori: 20124
Pagine viste: 36450

OpenSSHGestione servizi

Introduzione
Configurazione del server
Configurazione degli account
Utilizzo dei client
Utilizzo avanzato dei client

Introduzione

Originariamente sviluppata per OpenBSD OpenSSH è la versione free di SSH e probabilmente è il sistema di login remoto più usato in ambito Unix, anche grazie al grado di sicurezza offerto e dalla grande disponibilità dello stesso nelle pacchettizzazioni delle distribuzioni più svariate.

Le componenti principali di OpenSSH sono il client, il sistema di gestione delle chiavi e, fondamentale, il server. In questo articolo vedremo come usarne le funzionalità di base e qualcuna avanzata in un sistema GNU\Linux.

Nel resto della guida per comodità mi riferirò ad OpenSSH come SSH.

Configurazione del server

Il primo punto da prendere in considerazione per poter usare SSH è la configurazione del demone che gestirà le connessioni sul server remoto.

Al suo avvio il demone legge il proprio file di configurazione (/etc/ssh/sshd_config) ed eventuali ulteriori impostazioni specificate tramite riga di comando (queste ultime sovrascrivono le prime). Siccome le impostazioni tramite riga di comando non sono pratiche per l'uso di tutti i giorni, ma piuttosto vengono utili solo in casi particolari in cui si desideri avere il server con una configurazione diversa dal solito, vedremo solo il file di configurazione.

Ogni opzione occupa esattamente una riga; quelle vuote e quelle di commento (che iniziano per #) non vengono considerate.

Vediamo ora una carrellata delle principali opzioni disponibili e dei rispettivi valori consigliati. Molti di essi sono i valori di default, pertanto in un reale file di configurazione sarebbero opzioni superflui.

sshd-example-config.txt [Download #172, 2.56KB]

  1. # Accetta solo connessioni di versione 2 del protocollo
  2. Protocol 2
  3. # Accetta sia connessioni inet che inet6
  4. AddressFamily any
  5. # Livello di dettaglio del logging. Altri valori possibili sono
  6. # QUIET, FATAL, ERROR, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3.
  7. # Non si consiglia di usare un livello DEBUG in quanto
  8. # violerebbe la privacy degli utenti.
  9. LogLevel INFO
  10. # Il tempo a disposizione di un utente per loggarsi prima che il
  11. # server chiuda la connessione.
  12. LoginGraceTime 2m
  13. # Per sicurezza il login remoto per l'utente root.
  14. PermitRootLogin no
  15. # Controlla proprietari e permessi dei file dell'utente nella sua
  16. # home prima di accettare un login.
  17. StrictModes yes
  18. # Numero massimo di tentativi di autenticazione prima di chiudere
  19. # la connessione. Quando i tentativi superano la meta' di questo
  20. # limite i successivi vengono loggati.
  21. MaxAuthTries 6
  22. # Abilita l'autenticazione tramite chiave pubblica.
  23. PubkeyAuthentication yes
  24. # Disabilita l'autenticazione host-based.
  25. HostbasedAuthentication no
  26. # Se lo si ritenesse opportuno, impostare IgnoreUserKnownHosts a yes
  27. # permetterebbe di ritenere validi solo i system-wide known hosts
  28. # ignorando quelli indicati come fidati nelle impostazioni dei singoli
  29. # utenti.
  30. IgnoreUserKnownHosts no
  31. # Disabilita l'invio di password in chiaro nel tunnel cifrato.
  32. PasswordAuthentication no
  33. # Permettiamo l'uso di SSH solo agli utenti elencati
  34. AllowUsers user1 user2
  35. # Permettiamo l'uso di SSH solo agli utenti che appartengono al gruppo
  36. # 'ssh'. Eventuali utenti indicati in AllowUsers dovranno anche
  37. # appartenere ad almeno uno di questi gruppi.
  38. AllowGroups ssh
  39. # Talvolta puo' essere utile per certi fini legali mostrare un messaggio
  40. # con le avvertenze prima che all'utente remoto venga fornita la
  41. # possibilita' di effettuare login.
  42. Banner /etc/ssh/banner
  43. # Indica ad sshd di effettuare il binding delle forwarded ports solo
  44. # sul device di loopback, garantendo che nessun utente remoto possa
  45. # accedere ai tunnel.
  46. GatewayPorts no
  47. # Supponendo che questo pc abbia almeno 2 interfacce di rete,
  48. # ListenAddresspermetterebbe di indicare su quali interfacce di
  49. # rete accettare connessioni in ingresso.
  50. ListenAddress 10.0.0.1
  51. # Controlla periodicamente che la connessione con l'utente remoto sia
  52. # funzionante.
  53. TCPKeepAlive yes
  54. # I processi che gestiscono la comunicazione degli utenti connessi,
  55. # sono in esecuzione con i permessi dell'utente autenticato. Aiuta ad
  56. # impedire la scalata dei privilegi.
  57. UsePrivilegeSeparation yes
  58. # Per sicurezza disabilita l'inoltro di connessioni al server
  59. # grafico X11.
  60. X11Forwarding no

Nell'utilizzo delle direttive che specificano utenti e gruppi ammessi (e non) bisogna tenere conto del fatto che vengono processate in questo ordine: DenyUsers, AllowUsers, DenyGroups ed AllowGroups.

Durante la configurazione di sshd, è sempre buona norma considerare di quali tipi di servizi necessitiamo in modo da disabilitare tutti gli altri, mantenendo quindi attive solo le opzioni assolutamente indispensabili. Questo permette di ridurre il campo di possibili attacchi che potrebbero essere sferrati al sistema.

Per esempio, qualora non avessimo il bisogno di accedere al nostro firewall da internet, potremmo indicare ad sshd (tramite la direttiva ListenAddress) di mettersi in ascolto per connessioni entranti solo sull'interfaccia di rete corrispondente alla rete locale.

Rimando per ulteriori dettagli circa il demone sshd e la sua configurazione alle pagine man:

$ man sshd
$ mah sshd_config

Abilitare sftp

OpenSSH fornisce anche un server sftp (secure ftp). Per abilitarlo occorre inserire (o decommentare) la seguente riga di configurazione in /etc/ssh/sshd_config.

Subsystem       sftp    /usr/lib/misc/sftp-server

Il percorso dell'eseguibile potrebbe variare tra le architetture e tra i sistemi. Qualora non abbiate sftp-server al percorso indicato, dovreste cercare il file. Nel caso, provate questi comandi:

# whereis sftp-server
# slocate sftp-server
# find /usr -name 'sftp-server'

Avvio del demone

Ora che siamo certi della correttezza delle impostazioni, è possibile avviare il demone usando l'initscript appropriato. Mentre il sigificato de parametri start, stop e restart risulta chiaro, quello di reload e di force-reload un po' meno: entrambi vengono usati per indicare al demone di ricaricare il file di configurazione, e sono di fatto sinonimi.

Supponendo che si stia usando gentoo, vediamo i comandi da lanciare in qualità di amministratore per avviare sshd e far si che venga avviato insieme al pc:

# /etc/init.d/ssh
Usage: /etc/init.d/ssh {start|stop|reload|force-reload|restart}
# /etc/init.d/ssh start
# rc-update add sshd default

Qualora si stesse usando un sistema che veda sostituito InitNG all'init classico, la sequenza di comandi sarà diversa:

# ngc --start sshd
# ng-update add sshd

Infine, su un sistema debian-based:

# update-rc.d sshd defaults
# /etc/init.d/sshd start

Configurazione degli account

Nel caso abbiate usato la direttiva AllowGroups dovrete assicurarvi di aver iserito in uno dei gruppi abilitati ad ssh tutti gli utenti ai quali volete fornire questo servizio.

Se l'autenticazione tramite password non è stata disabilitata nel file di configurazione allora gli utenti possono già accedere, altrimenti devono creare la propria coppia di chiavi DSA o RSA (dipende dalle impostazioni del server) ed inserire la chiave pubblica tra le chiavi autorizzate per l'accesso al proprio account.

Al fine di ottenere una coppia di chiavi si procede come segue (qualora disponiate già di una coppia di chiavi, saltate al passo successivo):

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/greyfox/.ssh/id_dsa): [ENTER]
Enter passphrase (empty for no passphrase): *************
Enter same passphrase again: *************
Your identification has been saved in /home/greyfox/.ssh/id_dsa.
Your public key has been saved in /home/greyfox/.ssh/id_dsa.pub.
The key fingerprint is:
f1:92:f6:6a:10:19:5f:d0:52:23:fa:2b:d7:81:52:13 greyfox@localhost

Usando l'opzione -t rsa si andrebbe a creare una chiave RSA la versione 2 del protocollo, mentre con -t rsa1 si otterrebbe una chiave RSA della versione 1.

A questo punto è possibile prelevare il contenuto del file ~/.ssh/id_dsa.pub ed inserirlo nel file denominato ~/.ssh/authorized_keys sul server remoto. Qualora non si disponga dell'accesso fisico al proprio account, bisogna informarsi presso l'amministratore circa le metodologie di consegna della propria chiave pubblica.

Al contrario, se l'accesso tramite password fosse abilitato, potreste lanciare dalla vostra postazione locale il comando che segue (tutto su una riga):

cat ~/.ssh/id_dsa.pub | ssh USERNAME@SERVER "mkdir ~/.ssh; chmod 700 ~/.ssh; cat - >> ~/.ssh/authorized_keys"

Utilizzo dei client

Ora che l'account è correttamente configurato è possibile iniziare ad usare il client ssh.

Nel caso il server remoto sia configurato per funzionare su una porta diversa dalla 22 (valore di default), è possibile indicarla utilizzando l'opzione -p PORTA.

$ ssh USERNAME@SERVER
$ ssh -p PORTA USERNAME@SERVER

Le chiavi private cercate dal client durante l'autenticazione (nella configurazione predefinita) sono ~/.ssh/identity, ~/.ssh/id_rsa ed ~/.ssh/id_dsa, rispettivamente usate dal protocollo SSH 1 (RSA) e dal protocollo SSH 2 (RSA e DSA).

Disponendo di più di una chiave per la stessa versione di protocollo e volendone usare una che sia diversa da quella di default, sarebbe comunque possibile specificarla tramite riga di comando:

$ ssh -i ~/.ssh/mykey USERNAME@SERVER

L'alternativa all'utilizzo della riga di comando per specificare le opzioni di connessione ad un server remoto è l'utilizzo del file di configurazione ~/.ssh/config, oppure ,nella sua versione globale, /etc/ssh/ssh_config.

La sintassi è piuttosto semplice: come al solito righe vuote e quelle che iniziano per # sono commenti. Le impostazioni sono una per riga, e la direttiva Host precede tutte quelle riferite all'host in questione. Senza perderci in discorsi vediamo subito un esempio di configurazione:

ssh-example-config.txt [Download #121, 925.00B]

  1. #Impostazioni per l'host hostonw.it
  2. Host hostone.it
  3.   #Specificando qui l'username si puo' evitare di indicarlo come parametro command-line
  4.   User traverso
  5.   #Chiave privata da usare per l'autenticazione
  6.   IdentityFile ~/.ssh/id_dsa_2
  7.   #Usa solo la versione 2 del protocollo
  8.   Protocol 2
  9.   #Non usare la compressione dei dati
  10.   Compression no
  11.  
  12. #Impostazioni per tutti i sottodomini di hosttwo.com
  13. Host *.hosttwo.com
  14.   User gr3yfox
  15.   IdentityFile ~/.ssh/id_rsa_2
  16.   Protocol 1
  17.  
  18. #Impostazioni per tutti gli host
  19. Host *
  20.   #Elenco delle chiavi private disponibili. Il client le provera' nell'ordine
  21.   #in cui vengono indicate
  22.   IdentityFile ~/.ssh/identity
  23.   IdentityFile ~/.ssh/id_rsa
  24.   IdentityFile ~/.ssh/id_dsa
  25.   IdentityFile ~/.ssh/id_dsa_2
  26.   IdentityFile ~/.ssh/id_rsa_2
  27.   #Usa la compressione dei dati
  28.   Compression yes
  29.   #Prima prova a collegarsi usando la versione 2, altrimenti usa la versione 1
  30.   Protocol 2,1

Per un elenco completo delle opzioni disponibili man ssh_config.

Trasferimento di files

A fianco del client ssh, sono disponibili due tools per il trasferimento di files: scp ed sftp.

Il primo funziona come un normale comando di copia di files (ovviamente funziona anche ricorsivamente su cartelle intere e sottocartelle) ed ha una sintassi simile al comando cp, con qualcosina in più

$ scp
usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-l limit] [-o ssh_option] [-P port] [-S program]
           [[user@]host1:]file1 [...] [[user@]host2:]file2
$ scp -r Documenti hostone:/home/traverso/
$ scp -r hostone:/home/traverso/sorgenti /home/greyfox/

Come vedete, è davvero molto comodo. Il secondo tool, sftp se usato senza una GUI è decisamente più scomodo, in quanto - crittografia a parte - si tratta di un'implementazione del protocollo FTP che non supporta nativamente la copia ricorsiva di intere sottocartelle.

Ad ogni modo sftp può risultare di estrema utilità se usato in coppia con gli strumenti di FUSE (vedere più avanti nell'articolo la sezione Filesystem remoto per ulteriori dettagli.

Come sempre, man scp e man sftp per i dettagli circa il loro utilizzo.

Caching delle chiavi

Un'altra comodità offerta dai tools OpenSSH è l'agente delle chiavi, tramite il quale è possibile mantenerle in cache per tutta una sessione. In questo modo non occorre ridigitarne le rispettive passphrase ad ogni connessione.

Se siete in sessione grafica probabilmente l'agente è già stato avviato, in caso contrario dovrete avviarlo manualmente. Per aggiungere e rimuovere chiavi dalla cache si utilizza il comando ssh-add.

$ ssh-agent &
$ ssh-add ~/.ssh/id_dsa
Enter passphrase for /home/greyfox//.ssh/id_dsa: *****************
Identity added: /home/greyfox//.ssh/id_dsa (/home/greyfox//.ssh/id_dsa)

Utilizzo avanzato dei client

Port Forwarding

Una funzionalità estremamente utile offerta da ssh è il port forwarding: permette di realizzare dei canali cifrati che vadano da una determinata porta locale ad un'altra remota. Così facendo è possibile far comunicare in modo cifrato programmi che nativamente non implementino simili misure di sicurezza.

Per utilizzare il port forwarding deve essere attivo sshd sul pc remoto e dovete disporre di un account. Vediamo una configurazione di esempio sulla quale poter fare pratica:

Abbiamo due pc, rispettivamente chiamati serverpc e clientpc. Su serverpc è in funzione un server ssh e qualche altro genere di servizio non cifrato, per esempio POP, sulla porta 110. Disponiamo inoltre di un account su serverpc come popuser

Quello che vogliamo fare è creare un tunnel cifrato che vada da clientpc a serverpc:110. Per far questo scegliamo una porta locale da utilizzare come ingresso del tunnel. Prendiamo la porta 5123 (è possibile sceglierne anche di minori o uguali a 1024, ma in questo caso occorrono permessi di root su clientpc) . Ora ci basta controllare la sintassi appropriata di ssh e lanciare il comando.

Estratti dal man di ssh:
  -L [bind_address:]port:host:hostport
    Specifies that the given port on the local (client) host is to
    be forwarded to the given host and port on the remote side.
    This works by allocating a socket to listen to port on the
    local side, optionally bound to the specified bind_address.
    Whenever a connection is made to this port, the connection is
    forwarded over the secure channel, and a connection is made to
    host port hostport from the remote machine.  Port forwardings
    can also be specified in the configuration file.  IPv6
    addresses can be specified with an alternative syntax:
    [bind_address/]port/host/hostport or by enclosing the address
    in square brackets.  Only the superuser can forward privileged
    ports.  By default, the local port is bound in accordance with
    the GatewayPorts setting.  However, an explicit bind_address
    may be used to bind the connection to a specific address.  The
    bind_address of ``localhost'' indicates that the listening port
    be bound for local use only, while an empty address or `*'
    indicates that the port should be available from all inter-
    faces.
  -N
    Do not execute a remote command.  This is useful for just for-
    warding ports (protocol version 2 only)
   
greyfox@clientpc$ ssh -N -L 5123:localhost:110 popuser@serverpc

Vediamo che dopo la richiesta della password, il terminale risulta bloccato ed ssh rimane in funzione. Fin tanto che il client ssh non verrà terminato con CTRL-C, connettendosi all'indirizzo localhost:5123 su clientpc ci si ritroverà collegati al POP server su serverpc.

Potrebbe già bastare così, ma notiamo che in questo modo il terminale resta inutilizzabile per tutto il tempo. A questo scopo un'altra occhiata nella pagina del manuale di ssh ci fornisce la soluzione: basta aggiungere al comando l'opzione -f per mandarlo in backgroud subito dopo della richiesta della password.

Una alternativa sarebbe stata scrivere & in fondo al comando in modo che bash lo mandasse direttamente in background, ma in questo modo non avremmo potuto rispondere alla richiesta della password. Ovviamente questa soluzione rimane sempre attuabile nel caso non serva digitare la password, ad esempio disponendo di una chiave DSA in cache.

Reverse Port Forwarding

Similmente al port forwarding diretto, crea dei tunnel cifrati da una porta X di un host Y ad una porta W di un server Z, solo che li realizza al contrario.

Prendiamo in considerazione la stessa situazione descritta per il port forwarding, solo che stavolta serverpc non può collegarsi direttamente con clientpc (clientpc si trova dietro un firewall). Serverpc dispone di un indirizzo pubblico. E' possibile utilizzare il reverse port forwarding al fine di bypassare il firewall e di collegarsi direttamente a clientpc per mezzo di serverpc. Vediamo come:

Per utilizzare il reverse port forwarding abbiamo bisogno come prima di un account su entrambi i pc: a questo scopo continuiamo ad usare gli stessi di prima. Controlliamo la guida e poi apriamo un tunnel dalla porta 5123 (ad esempio) di serverpc alla porta 22 locale (avendo un server ssh attivo anche su clientpc).

Dal man di ssh:
  -R [bind_address:]port:host:hostport
    Specifies that the given port on the remote (server) host is to
    be forwarded to the given host and port on the local side.
    This works by allocating a socket to listen to port on the
    remote side, and whenever a connection is made to this port,
    the connection is forwarded over the secure channel, and a con-
    nection is made to host port hostport from the local machine.
   
    Port forwardings can also be specified in the configuration
    file.  Privileged ports can be forwarded only when logging in
    as root on the remote machine.  IPv6 addresses can be specified
    by enclosing the address in square braces or using an alterna-
    tive syntax: [bind_address/]host/port/hostport.
   
    By default, the listening socket on the server will be bound to
    the loopback interface only.  This may be overriden by specify-
    ing a bind_address.  An empty bind_address, or the address `*',
    indicates that the remote socket should listen on all inter-
    faces.  Specifying a remote bind_address will only succeed if
    the server's GatewayPorts option is enabled (see
    sshd_config(5)).

greyfox@clientpc$ ssh -fN -R 22:localhost:5123 popuser@serverpc

Ora da qualsiasi computer che disponga di un accesso ad internet potremo collegarci con ssh alla porta 5123 di serverpc per ritrovarci collegati a clientpc, che altrimenti sarebbe risultato irraggiungibile.

user@somepc$ ssh greyfox@serverpc -p 5123
greyfox@clientpc$

Perchè il precedente comando di connessione, su serverpc deve essere abilitata l'opzione GatewayPorts yes in /etc/ssh/sshd_config in modo che le porte usate per i tunnel non siano visibili solo tramite localhost ma anche a tutte le altre interfacce di rete. Nel caso che l'opzione non sia abilitata, sarà sempre possibile collegarsi a clientpc accedendo prima a serverpc e poi da serverpc al tunnel:

user@somepc$ ssh popuser@serverpc
popuser@serverpc$ ssh greyfox@localhost -p 5123
greyfox@clientpc$

Filesystem remoto

Una grande oppurtunità che ci offre il software FUSE consiste nell'utilizzare un server sftp remoto come se fosse un filesystem distribuito, e di conseguenza montarlo nell'albero delle directory locali.

Mounting a parte tutte le altre operazioni vengono effettuate in modo completamente trasparente all'utente, il quale lavora sui documenti remoti senza alcuna distinzione da quelli locali.

Prima di procedere con l'installazione bisogna assicurarsi di avere il supporto per i filesystem in userspace. Lo si può trovare alla voce File systems -> File system in Userspace support. Molto probabilmente chi non si sia ricompilato manualmente il proprio kernel ha già l'impostazione corretta.

Ora basta installare il pacchetto sshfs per poter iniziare. In gentoo lo si può fare con:

# emerge -av sys-fs/sshfs-fuse

Mentre per Debian:

# apt-get install sshfs

Assicuriamoci che il modulo del kernel di fuse venga caricato ad ogni avvio:

# echo "fuse" >> /etc/modules.autoload.d/kernel-2.6
# modprobe fuse

Ora che tutto è pronto possiamo iniziare a montare e smontare volumi remoti sshfs:

# sshfs utente@host: /mnt/remote-fs -o allow_other
utente@host's password: **********
# fusermount -u /mnt/remote-fs

Nell'esempio abbiamo montato e successivamente smontato la root del filesystem remoto in /mnt/remote-fs, ma avremmo anche potuto montarne solo una sottocartella indicandone il percorso dopo i due punti che seguono l'indirizzo dell'host.

Esiste tuttavia un metodo più comodo che permette di non specificare ogni volta nome utente, host, mountpoint ed eventuali alte opzioni: inserire una voce per il filesystem remoto in /etc/fstab

Voce sshfs in /etc/fstab

  1. sshfs#user@host: /mnt/remote-fs fuse user,noauto 0 0

Questo ci permette di usare normalmente i comandi mount e umount (nell'esempio anche da utenti normali vista l'opzione user). L'opzione noauto è necessaria perchè il sistema non cerchi di montare il filesystem all'avvio.

$ mount /mnt/remote-fs
$ umount /mnt/remote-fs

Articoli (forse) correlati

  1. Subversion + SSH
  2. Installare Hamachi

— Riccardo Traverso (25 June 2007, 11:02)

Link permanente | Gestione servizi | Linux

Commenti (3)

Bellissima guida… Molto chiara ed esaustiva. Grande Richy! ;)

— Frafra ( 05 July 2007, 20:38 ) · #

Grazie. Vedrai che ne arrivano altre ;)

— GreyFox ( 05 July 2007, 20:45 ) · #

Congratulazioni ottima guida, molto chiara

— Gianfranco ( 24 January 2010, 20:38 ) · #

Lascia un commento

Nome:

E-mail:

Sito:

Messaggio (Aiuto Textile):

Valid CSS

2009 © Traverso Riccardo

Valid XHTML