Difference between revisions of "Secure Shell (Italiano)"

From ArchWiki
Jump to: navigation, search
m (Daemon)
(48 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:Daemons and system services (Italiano)]]
+
[[Category:Secure Shell (Italiano)]]
{{i18n|SSH}}
+
[[en:Secure Shell]]
 
+
[[es:Secure Shell]]
 
+
[[fr:ssh]]
Secure Shell o SSH è un protocollo di rete che consente lo scambio di dati su un canale protetto tra due computer. Encryption si incarica della riservatezza e l'integrità dei dati. SSH utilizza la crittografia a chiave pubblica per autenticare il computer remoto e permettere allo stesso di autenticarne l'utente, se necessario.
+
[[ko:Secure Shell]]
 +
[[pl:Secure Shell]]
 +
[[pt:Secure Shell]]
 +
[[ru:Secure Shell]]
 +
[[sr:Secure Shell]]
 +
[[zh-CN:Secure Shell]]
 +
'''Secure Shell''' ('''SSH''') è un protocollo di rete che consente lo scambio di dati su un canale protetto tra due computer. Encryption si incarica della riservatezza e l'integrità dei dati. SSH utilizza la crittografia a chiave pubblica per autenticare il computer remoto e permettere allo stesso di autenticarne l'utente, se necessario.
  
 
SSH è in genere utilizzato per accedere a una macchina remota ed eseguire comandi, ma supporta anche il tunneling, l'inoltro (forwarding arbitrary) su porte TCP e connessioni X11; il trasferimento dei file può essere eseguito utilizzando i  protocolli associati SFTP o SCP.
 
SSH è in genere utilizzato per accedere a una macchina remota ed eseguire comandi, ma supporta anche il tunneling, l'inoltro (forwarding arbitrary) su porte TCP e connessioni X11; il trasferimento dei file può essere eseguito utilizzando i  protocolli associati SFTP o SCP.
Line 11: Line 17:
 
(Fonte: [[Wikipedia:Secure Shell]])
 
(Fonte: [[Wikipedia:Secure Shell]])
  
= OpenSSH =
+
==OpenSSH==
 
+
 
OpenSSH (OpenBSD Secure Shell) è un insieme di programmi per computer che forniscono sessioni di comunicazione criptate su una rete di computer usando il protocollo SSH. È stato creato come alternativa open source al software proprietario Secure Shell suite, offerto da SSH Communications Security. OpenSSH è sviluppato come parte del progetto OpenBSD, che è guidato da Theo de Raadt.
 
OpenSSH (OpenBSD Secure Shell) è un insieme di programmi per computer che forniscono sessioni di comunicazione criptate su una rete di computer usando il protocollo SSH. È stato creato come alternativa open source al software proprietario Secure Shell suite, offerto da SSH Communications Security. OpenSSH è sviluppato come parte del progetto OpenBSD, che è guidato da Theo de Raadt.
  
 
OpenSSH è a volte confuso con OpenSSL per la somiglianza del nome, tuttavia, i progetti hanno scopi diversi e sono sviluppati da team differenti. La similitudine del nome è derivata solamente da obiettivi simili.
 
OpenSSH è a volte confuso con OpenSSL per la somiglianza del nome, tuttavia, i progetti hanno scopi diversi e sono sviluppati da team differenti. La similitudine del nome è derivata solamente da obiettivi simili.
  
== Installazione di OpenSSH ==
+
===Installazione di OpenSSH===
# pacman -S openssh
+
[[Pacman (Italiano)|Installare]] il pacchetto {{Pkg|openssh}}
  
== Configurazione di SSH ==
+
===Configurazione di SSH===
===Client===
+
====Client====
Il file di configurazione del client SSH può essere trovato e modificato in {{Filename|/etc/ssh/ssh_config}}.
+
Il file di configurazione del client SSH può essere trovato e modificato in {{ic|/etc/ssh/ssh_config}}.
  
 
Un esempio di configurazione:  
 
Un esempio di configurazione:  
  
{{File|name=/etc/ssh/ssh_config|content=
+
{{hc|/etc/ssh/ssh_config|2=<nowiki>
 
+
# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $
#       $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $
+
  
 
# This is the ssh client system-wide configuration file.  See
 
# This is the ssh client system-wide configuration file.  See
Line 47: Line 51:
 
# ssh_config(5) man page.
 
# ssh_config(5) man page.
  
Host *
+
# Host *
 
#  ForwardAgent no
 
#  ForwardAgent no
 
#  ForwardX11 no
 
#  ForwardX11 no
Line 74: Line 78:
 
#  PermitLocalCommand no
 
#  PermitLocalCommand no
 
#  VisualHostKey no
 
#  VisualHostKey no
HashKnownHosts yes
+
#  ProxyCommand ssh -q -W %h:%p gateway.example.com</nowiki>}}
StrictHostKeyChecking ask}}
+
  
 
Si consiglia di modificare la riga del protocollo in questo modo:
 
Si consiglia di modificare la riga del protocollo in questo modo:
Line 82: Line 85:
 
Ciò significa che sarà utilizzato solo il protocollo 2, dal momento che il protocollo 1 è considerato poco sicuro.
 
Ciò significa che sarà utilizzato solo il protocollo 2, dal momento che il protocollo 1 è considerato poco sicuro.
  
===Daemon===
+
====Daemon====
Il file di configurazione del demone SSH può essere trovato e modificato in {{Filename|/etc/ssh/ssh'''d'''_config}}.
+
Il file di configurazione del demone SSH può essere trovato e modificato in {{ic|/etc/ssh/ssh'''d'''_config}}.
  
 
Un esempio di configurazione:  
 
Un esempio di configurazione:  
  
{{File|name=/etc/ssh/sshd_config|content=
+
{{hc|/etc/ssh/sshd_config|2=<nowiki>
 
+
# $OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy Exp $
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $
+
  
 
# This is the sshd server system-wide configuration file.  See
 
# This is the sshd server system-wide configuration file.  See
Line 102: Line 104:
  
 
#Port 22
 
#Port 22
#Protocol 2,1
+
#AddressFamily any
ListenAddress 0.0.0.0
+
#ListenAddress 0.0.0.0
 
#ListenAddress ::
 
#ListenAddress ::
 +
 +
# The default requires explicit activation of protocol 1
 +
#Protocol 2
  
 
# HostKey for protocol version 1
 
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh''host''key
+
#HostKey /etc/ssh/ssh_host_key
 
# HostKeys for protocol version 2
 
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh''host''rsa_key
+
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh''host''dsa_key
+
#HostKey /etc/ssh/ssh_host_dsa_key
 +
#HostKey /etc/ssh/ssh_host_ecdsa_key
  
 
# Lifetime and size of ephemeral version 1 server key
 
# Lifetime and size of ephemeral version 1 server key
 
#KeyRegenerationInterval 1h
 
#KeyRegenerationInterval 1h
#ServerKeyBits 768
+
#ServerKeyBits 1024
  
 
# Logging
 
# Logging
#obsoletes ~QuietMode and ~FascistLogging
+
# obsoletes QuietMode and FascistLogging
 
#SyslogFacility AUTH
 
#SyslogFacility AUTH
 
#LogLevel INFO
 
#LogLevel INFO
Line 127: Line 133:
 
#StrictModes yes
 
#StrictModes yes
 
#MaxAuthTries 6
 
#MaxAuthTries 6
 +
#MaxSessions 10
  
 
#RSAAuthentication yes
 
#RSAAuthentication yes
 
#PubkeyAuthentication yes
 
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys
+
#AuthorizedKeysFile .ssh/authorized_keys
  
# For this to work you will also need host keys in /etc/ssh/ssh''known''hosts
+
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
 
#RhostsRSAAuthentication no
 
#RhostsRSAAuthentication no
 
# similar for protocol version 2
 
# similar for protocol version 2
Line 147: Line 154:
  
 
# Change to no to disable s/key passwords
 
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
+
ChallengeResponseAuthentication no
  
 
# Kerberos options
 
# Kerberos options
Line 159: Line 166:
 
#GSSAPICleanupCredentials yes
 
#GSSAPICleanupCredentials yes
  
# Set this to 'yes' to enable PAM authentication, account processing,
+
# Set this to 'yes' to enable PAM authentication, account processing,  
# and session processing. If this is enabled, PAM authentication will
+
# and session processing. If this is enabled, PAM authentication will  
# be allowed through the ~ChallengeResponseAuthentication mechanism.
+
# be allowed through the ChallengeResponseAuthentication and
# Depending on your PAM configuration, this may bypass the setting of
+
# PasswordAuthentication.  Depending on your PAM configuration,
# PasswordAuthentication, ~PermitEmptyPasswords, and
+
# PAM authentication via ChallengeResponseAuthentication may bypass
# "PermitRootLogin without-password". If you just want the PAM account and
+
# the setting of "PermitRootLogin without-password".
# session checks to run without PAM authentication, then enable this but set
+
# If you just want the PAM account and session checks to run without
# ChallengeResponseAuthentication=no
+
# PAM authentication, then enable this but set PasswordAuthentication
#UsePAM no
+
# and ChallengeResponseAuthentication to 'no'.
 +
UsePAM yes
  
 +
#AllowAgentForwarding yes
 
#AllowTcpForwarding yes
 
#AllowTcpForwarding yes
 
#GatewayPorts no
 
#GatewayPorts no
Line 180: Line 189:
 
#UsePrivilegeSeparation yes
 
#UsePrivilegeSeparation yes
 
#PermitUserEnvironment no
 
#PermitUserEnvironment no
#Compression yes
+
#Compression delayed
 
#ClientAliveInterval 0
 
#ClientAliveInterval 0
 
#ClientAliveCountMax 3
 
#ClientAliveCountMax 3
Line 186: Line 195:
 
#PidFile /var/run/sshd.pid
 
#PidFile /var/run/sshd.pid
 
#MaxStartups 10
 
#MaxStartups 10
 +
#PermitTunnel no
 +
#ChrootDirectory none
  
 
# no default banner path
 
# no default banner path
#Banner /some/path
+
#Banner none
  
 
# override default of no subsystems
 
# override default of no subsystems
Subsystem       sftp   /usr/lib/ssh/sftp-server}}
+
Subsystem sftp /usr/lib/ssh/sftp-server
  
 +
# Example of overriding settings on a per-user basis
 +
#Match User anoncvs
 +
# X11Forwarding no
 +
# AllowTcpForwarding no
 +
# ForceCommand cvs serveri</nowiki>}}
  
 
Per consentire l'accesso solo ad alcuni utenti aggiungere questa riga:
 
Per consentire l'accesso solo ad alcuni utenti aggiungere questa riga:
 +
 
  AllowUsers    user1 user2
 
  AllowUsers    user1 user2
  
Si possono anche modificare alcune righe nel modo seguente:
+
Per disabilitare l'accesso SSH per l'utente ''root'', aggiungere la seguente linea:
<pre>
+
PermitRootLogin no
Protocol 2
+
.
+
.
+
.
+
LoginGraceTime 120
+
.
+
.
+
.
+
PermitRootLogin no # (put yes here if you want root login)
+
</pre>
+
  
Si potrebbe anche rimuovere l'opzione BANNER e modificare il file {{Filename|/etc/issue}} per un gradevole messaggio di benvenuto.
+
Si potrebbe anche rimuovere l'opzione BANNER e modificare il file {{ic|/etc/issue}} per un gradevole messaggio di benvenuto.
  
 
{{Tip| Si consiglia di modificare la porta di default 22 ad una di numero più alto (consultare [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}}  
 
{{Tip| Si consiglia di modificare la porta di default 22 ad una di numero più alto (consultare [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}}  
  
Anche se la porta ssh è in esecuzione e può essere rilevata utilizzando un port scanner come nmap, cambiandola si ridurrà il numero di voci del registro di log, causato dai tentativi di autenticazione automatica.
+
Anche se la porta SSH è in esecuzione e può essere rilevata utilizzando un port scanner come nmap, cambiandola si ridurrà il numero di voci del registro di log, causato dai tentativi di autenticazione automatica. Per un aiuto sulla scelta della porta consultare la [[Wikipedia:List of TCP and UDP port numbers|lista dei numeri delle porte TCP ed UDP]].
  
{{Tip| Disabilitando gli accessi con la password, può aumentare il livello di sicurezza, dato che ogni utente con accesso al server avrà bisogno di creare delle chiavi ssh. (consultare [http://wiki.archlinux.org/index.php/Using_SSH_Keys Using SSH Keys]).}}
+
{{Tip| Disabilitando gli accessi con la password, aumenta il livello di sicurezza. (consultare [[SSH Keys (Italiano)|SSH Keys]]).}}
  
{{File|name=/etc/ssh/sshd_config|content=
+
===Gestione demone SSHD===
PasswordAuthentication no
+
Aggiungere {{ic|sshd}} alla lista di [[Daemon (Italiano)|demoni]] {{ic|DAEMONS}} nel file {{ic|/etc/[[rc.conf]]}}:
ChallengeResponseAuthentication no}}
+
  
===Permessi d'accesso===
+
Per avviare/riavviare/fermare il demone, usare il seguente comando (da root):
{{Box Note | È necessario modificare questo file per connettersi da remoto al computer in quanto il file è vuoto di default}}
+
# rc.d {start|stop|restart} sshd
  
Per consentire l'accesso tramite ssh al computer è necessario modificare {{Filename|/etc/hosts.allow}}, aggiungendo quanto segue:
+
===Connessione al server===
 +
Per connettersi ad un server, dare il comando:
 +
$ ssh -p port user@server-address
  
<pre>
+
==Trucchi e consigli==
# let everyone connect to you
+
===Tunnel criptati===
sshd: ALL
+
Questo tipo di collegamento è molto utile per, ad esempio, l'utenza laptop collegata a varie connessioni wireless non sicure. L'unica cosa necessaria è un server SSH in esecuzione in un qualche luogo sicuro, come casa o il luogo di lavoro. Potrebbe essere utile l'utilizzo di un servizio DNS dinamico come [http://www.dyndns.org/ DynDNS] in modo da non dover ricordare l'indirizzo IP a cui ci si vuole collegare.
  
# OR you can restrict it to a certain ip
+
====Step 1: Avviare la connessione====
sshd: 192.168.0.1
+
È sufficiente eseguire questo comando nel terminale preferito per avviare la connessione:
 +
$ ssh -ND 4711 user@host
 +
dove {{ic|"user"}} è il nome utente del server SSH in esecuzione sull' {{ic|"host"}}. Verrà richiesta la password, e la connessione sarà stabilita! Il flag {{ic|"N"}} disabilita il prompt interattivo, il flag {{ic|"D"}} specifica la porta locale su cui ascoltare (si può scegliere qualsiasi numero di porta).
  
# OR restrict for an IP range
+
Un modo per facilitare questa operazione è quello di mettere una riga di "alias" nel file {{ic|~/.bashrc}} come segue:
sshd: 10.0.0.0/255.255.255.0
+
alias sshtunnel="ssh -ND 4711 -v user@host"
 +
Può risultare utile aggiungere il flag "verbose" {{ic|"-v"}}, in modo da poter verificare dall'output che si è realmente connessi. Ora basta eseguire il comando {{ic|"sshtunnel"}}
  
# OR restrict for an IP match
+
====Step 2: Configurare il Browser (o altri programmi)====
sshd: 192.168.1.
+
Il passo precedente è del tutto inutile se non si configura il browser web (o altri programmi) da utilizzare con il tunnel appena creato. A partire dalla corrente versione di SSH sono supportati sia SOCKS4 che SOCKS5 sarà possibile scegliere uno dei due.
</pre>
+
  
Ora si dovrebbe verificare nel file {{Filename|/etc/hosts.deny}} che la seguente riga appaia come segue, oppure modificarla, nel caso non lo sia:
+
* Per Firefox: ''Modificare &rarr; Preferenze &rarr; Avanzate &rarr; Rete &rarr; Connessione &rarr; Impostazioni'':
ALL: ALL
+
: Controllare il bottone ''"Configurazione manuale del proxy"'', ed immettere "localhost" nel campo testuale ''"SOCKS host"'', ed immettere infine il numero della porta nel prossimo campo testuale (usata in questo caso la 4711, come sopra).
  
Con questo, le configurazioni sono complete. Si può ora usare SSH per connettersi o far connettere gli altri con noi.
+
Firefox non effettua automaticamente le richieste DNS attraverso il tunnel. Questo inconveniente riguardo alla privacy può essere ovviato con questi passi:
  
Per iniziare a utilizzare la nuova configurazione, riavviare il demone (da root):
+
# digitare {{ic|about:config}} nella barra dell'indirizzo di Firefox.
# /etc/rc.d/sshd restart
+
  
== Gestione demone SSHD ==
+
# cercare la chiave {{ic|network.proxy.socks_remote_dns}}
Aggiungere sshd alla stringa "DAEMONS" del file {{Filename|/etc/[[rc.conf]]}}:
+
DAEMONS=(... ... '''sshd''' ... ...)
+
  
Per avviare/riavviare/fermare il demone, usare il seguente comando (da root):
+
# impostare il valore a {{ic|true}}-
# /etc/rc.d/sshd {start|stop|restart}
+
  
==Connessione al server==
+
# riavviare il browser.
Per connettersi ad un server, dare il comando:
+
* Per Chromium: è possibile configurare le impostazioni del SOCKS come variabili di ambiente oppure come opzione di lancio da riga di comando. Il metodo raccomandato consiste nell'inserire una delle seguenti funzioni nel proprio {{ic|.bashrc}}:
$ ssh -p port user@server-address
+
  
= Suggerimenti =
+
function secure_chromium {
 +
  port=4711
 +
  export SOCKS_SERVER=localhost:$port
 +
  export SOCKS_VERSION=5
 +
  chromium &
 +
  exit
 +
}
  
== Tunnel criptati ==
+
oppure
Questo tipo di collegamento è molto utile per, ad esempio, l'utenza laptop collegata a varie connessioni wireless non sicure. L'unica cosa necessaria è un server SSH in esecuzione in un qualche luogo sicuro, come casa o il luogo di lavoro. Potrebbe essere utile l'utilizzo di un servizio DNS dinamico come [http://www.dyndns.org/ DynDNS] in modo da non dover ricordare l'indirizzo IP a cui ci si vuole collegare.
+
  
=== Step 1: Avviare la connessione ===
+
function secure_chromium {
È sufficiente eseguire questo comando nel terminale preferito per avviare la connessione:
+
  port=4711
  $ ssh -ND 4711 user@host
+
  chromium --proxy-server="socks://localhost:$port" &
dove {{Codeline|"user"}} è il nome utente del server SSH in esecuzione sull' {{Codeline|"host"}}. Verrà richiesta la password, e la connessione sarà stabilita! Il flag {{Codeline|"N"}} disabilita il prompt interattivo, il flag {{Codeline|"D"}} specifica la porta locale su cui ascoltare (si può scegliere qualsiasi numero di porta).
+
  }
  
Un modo per facilitare questa operazione è quello di mettere una riga di "alias" nel file {{Filename|~/.bashrc}} come segue:
+
In questo modo basterà digitare nel terminale:
alias sshtunnel="ssh -ND 4711 -v user@host"
+
Può risultare utile aggiungere il flag "verbose" {{Codeline|"-v"}}, in modo da poter verificare dall'output che si è realmente connessi. Ora basta eseguire il comando {{Codeline|"sshtunnel"}}
+
  
=== Step 2: Configurare il Browser (o altri programmi) ===
+
$ secure_chromium
  
Il passo precedente è del tutto inutile se non si configura il browser web (o altri programmi) da utilizzare con il tunnel appena creato.
+
Godetevi il vostro tunnel sicuro!
  
* Per Firefox: ''Modificare &rarr; Preferenze &rarr; Avanzate &rarr; Rete &rarr; Connessione &rarr; Impostazioni'':
+
===X11 Forwarding===
: Controllare il bottone ''"Configurazione manuale del proxy"'', ed immettere "localhost" nel campo testuale ''"SOCKS host"'', ed immettere infine il numero della porta nel prossimo campo testuale (usata in questo caso la 4711, come sopra).
+
Per eseguire programmi grafici tramite una connessione SSH è possibile attivare X11 forwarding. Un'opzione dovrà essere impostata nel file di configurazione sul server e client (dove "client" significa la propria macchina (desktop) sulla quale il server X11 è in esecuzione, e le applicazioni in X verranno eseguite sul "server").
  
: Assicurarsi di selezionare SOCKS4 come protocollo da usare.  Questa procedura non funziona per SOCKS5.
+
Installare il pacchetto {{pkg|xorg-xauth}} sul server.
  
 +
* Abilitare l'opzione '''AllowTcpForwarding''' in {{ic|sshd_config}} sul '''server'''.
 +
* Abilitare l'opzione '''X11Forwarding''' in {{ic|sshd_config}} sul '''server'''.
 +
* Abilitare l'opzione '''X11DisplayOffset''' in {{ic|sshd_config}} sul '''server''' e impostare su 10.
 +
* Abilitare l'opzione '''X11UseLocalhost''' in {{ic|sshd_config}} sul '''server'''.
  
== X11 Forwarding ==
+
Inoltre sarà necessario:
 +
* Abilitare l'opzione '''ForwardX11''' in {{ic|ssh_config}} sul '''client'''.
 +
Abilitare l'opzione '''ForwardX11Trusted''' può essere utile nel caso che le interfacce grafiche vengano visualizzate male.
  
Per eseguire programmi grafici tramite una connessione SSH è possibile attivare X11 forwarding. Un'opzione dovrà essere impostata nel file di configurazione sul server e client (dove "client" significa la propria macchina (desktop) sulla quale il server X11 è in esecuzione, e le applicazioni in X verranno eseguite sul "server").
+
Per usare il forwarding, accedere al server con SSH:
 +
$ ssh -X -p port user@server-address
 +
Nel caso vengano restituiti degli errori avviando applicazioni grafiche, provare con il trusted forwarding:
 +
$ ssh -Y -p port user@server-address
 +
Sarà possibile avviare ora qualsiasi programma X sul server remoto, l'output sarà trasmesso alla sessione locale:
 +
$ xclock
  
Installare xorg-xauth sul server:
+
Se si ottiene l'errore "Cannot open display" provare i seguenti comandi come utente normale, non come root:
  # pacman -S xorg-xauth
+
  $ xhost +
 +
Il precedente comando consentira a tutti i client di effettuare il forward delle applicazioni grafiche(X11). Per restringere l'accesso a determinati client:
 +
$ xhost +nomemacchina
 +
Dove ''nomemacchina'' è il nome della macchina a cui si vuole garantire l'accesso. Digitare "{{ic|man xhost}}" per maggiori informazioni.
  
* Abilitare l'opzione '''AllowTcpForwarding''' in {{Filename|sshd_config}} sul '''server'''.
+
Alcune applicazioni verificano la presenza di altre istanze sulla macchina locale. Ad esempio Firefox. Sarà necessario quindi chiudere l'applicazione oppure usare la seguente opzione per avviare una sessione remota dalla macchina locale.
* Abilitare l'opzione '''X11Forwarding''' in {{Filename|sshd_config}} sul '''server'''.
+
* Abilitare l'opzione '''X11DisplayOffset''' in {{Filename|sshd_config}} sul '''server''' e impostare su 10.
+
* Abilitare l'opzione '''X11UseLocalhost''' in {{Filename|sshd_config}} sul '''server'''.
+
  
 +
$ firefox -no-remote
  
* Abilitare l'opzione '''ForwardX11''' in {{Filename|ssh_config}} sul '''client'''.
+
===Effettuare il Forwarding di altre porte===
 +
In aggiunta al supporto nativo per X11, SSH può essere usato per incanalare in un tunnel sicuro qualsiasi connessione TCP, usando il forwarding locale o remoto.
  
Per usare il forwarding, accedere al server con ssh:
+
Il forwarding locale apre una porta sulla macchina locale, tutte le connessioni ad essa saranno inviate all'host remoto e da quindi ad una specifica destinazione. Molto spesso, la destinazione finale sarà la solita dell'host remoto, questo fornisce una shell sicura ed, ad esempio, una connessione VNC sicura, alla stessa macchina. Il forwarding locale viene specificato mediante l'uso dell'opzione {{ic|-L}} e seguita dalle appropriate impostazioni per il forwarding in questa forma  {{ic|<porta tunnel>:<indirizzo destinazione>:<porta destinazione>}}.
  # ssh -X -p port user@server-address
+
 
Nel caso vengano restituiti degli errori avviando applicazioni grafiche, provare con il trusted forwarding:
+
Ad esempio:
  # ssh -Y -p port user@server-address
+
 
Sarà possibile avviare ora qualsiasi programma X sul server remoto, l'output sarà trasmesso alla sessione locale:
+
$ ssh -L 1000:mail.google.com:25 192.168.0.100
  # xclock
+
 
 +
utilizzerà SSH per effettuare il login ad una shell remota sul server 192.168.0.100, ed inoltre creerà un tunnel dalla porta 1000 TCP locale alla destinazione remota mail.google.com alla porta 25. Una volta stabilita la connessione, tutte le connessioni a localhost:1000 verranno indirizzate al servizio SMTP di Gmail. A Google, risulterà che ogni richiesta (ma non necessariamente i dati inviati dalla connessione) provenga da 192.168.0.100, inoltre questi dati saranno criptati nel transito dalla macchina locale al server 192.168.0.100, ma non oltre 192.168.0.100, a meno che non vengano presi provvedimenti al riguardo.
 +
 
 +
Similmente:
 +
 
 +
  $ ssh -L 2000:192.168.0.100:6001 192.168.0.100
 +
 
 +
permetterà alle connessioni verso localhost:2000 di essere inviate all'host remoto alla porta 6001. Il precedente esempio è molto utile per le connessioni VNC, ad esempio, usando l'utility {{ic|vncserver}} (parte delle applicazioni fornite dal pacchetto {{Pkg|tightvnc}}, il quale non fornisce misure di sicurezza proprie.
 +
 
 +
Il remote forwarding permette alla macchina remota di connettersi ad un host tramite il tunnel SSH e la la macchina locale, fornendo una funzione inversa al forwarding locale, questo risulta utile, ad esempio, nel caso in cui l'host remoto ha una connettività limitata a causa di un firewall. Il remote forwarding viene specificato dall'opzione {{ic|-R}} ed alle impostazioni del forwarding nella forma {{ic|<porta tunnel>:<indirizzo destinazione>:<porta destinazione>}}.
 +
 
 +
Ad esempio:
 +
 
 +
  $ ssh -R 3000:irc.freenode.net:6667 192.168.0.200
 +
 
 +
aprirà una shell sul server 195.168.0.200, e le connessioni provenienti da 192.168.0.200 a se stesso sulla porta 3000(parlando in termini remoti localhost:3000) verranno inviate attraverso il tunnel verso la macchina locale e poi verso irc.freenode.net alla porta 6667, quindi, in questo esempio, permetterà l'uso dei programmi IRC sulla macchina remota anche se normalmente la porta 6667 sarebbe chiusa.
 +
 
 +
Entrambi i tipi di forwarding locale e remoto possono essere usati per creare un "gateway" sicuro permettendo agli altri computer di godere dei vantaggi di un tunnel SSH, senza dover eseguire un client SSH oppure un demone SSH fornendo un indirizzo di ascolto per definire l'inizio del tunnel come argomento del forwarding, nella forma: {{ic|<indirizzo tunnel>:<porta tunnel>:<indirizzo destinazione>:<porta destinazione>}}.
 +
 
 +
{{ic|<indirizzo tunnel>}} può essere un qualsiasi indirizzo sulla macchina all'inizio del tunnel, {{ic|localhost}}, {{ic|*}} (oppure lasciato in bianco), che rispettivamente, permettono connessioni tramite uno specifico indirizzo, tramite l'interfaccia di loopback, oppure tramite qualunque interfaccia. Come default, il forwarding è limitato alle connessioni provenienti dalla macchina all'inizio del tunnel, quindi {{ic|<tunnel address>}} è impostato su {{ic|localhost}}. Il forwarding locale non richiede configurazioni addizionali, mentre il forwarding remoto è condizionato dalle configurazioni del demone SSH sulla macchina remota. Per maggiori informazioni consultare le informazioni riguardo all'opzione {{ic|GatewayPorts}} nella pagina di manuale {{ic|sshd_config(5)}}.
 +
 
 +
===Velocizzare SSH===
 +
Sarà possibile che tutte le sessioni con lo stesso host utilizzino una singola connessione, il che velocizza notevolmente i login successivi, aggiungendo queste righe nell'host appropriato in {{ic|/etc/ssh/ssh_config}}:
 +
  ControlMaster auto
 +
ControlPath ~/.ssh/socket-%r@%h:%p
  
== velocizzare SSH ==
+
Modificando i valori usati da SSH per una minore richiesta di risorse cpu può aumentarne la velocità. Sotto questo aspetto, le scelte migliori ricadono su arcfour e blowfish-cbc. '''Non usare queste opzioni a meno che non si sappia ciò che si sta facendo; arcfour ha alcune vulnerabilità note.'''  Per provarli, avviare SSH con il flag {{ic|"c"}}, in questo modo:
Modificando i valori usati da SSH per una minore richiesta di risorse cpu può aumentarne la velocità. Sotto questo aspetto, le scelte migliori ricadono su arcfour e blowfish-cbc. Per provarli, avviare SSH con il flag {{Codeline|"c"}}, in questo modo:
+
  $ ssh -c arcfour,blowfish-cbc user@server-address
  # ssh -c arcfour,blowfish-cbc user@server-address
+
Per renderne l'utilizzo predefinito, aggiungere questa riga sotto il proper host in {{ic|/etc/ssh/ssh_config}}:
Per renderne l'utilizzo predefinito, aggiungere questa riga sotto il proper host in {{Filename|/etc/ssh/ssh_config}}:
+
 
  Ciphers arcfour,blowfish-cbc
 
  Ciphers arcfour,blowfish-cbc
Un'altra opzione per aumentare la velocità è abilitare la compressione con il flag {{Codeline|"C"}}. Una soluzione permanente è aggiungere questa riga nell'host appropriato in {{Filename|/etc/ssh/ssh_config}}:
+
Un'altra opzione per aumentare la velocità è abilitare la compressione con il flag {{ic|"C"}}. Una soluzione permanente è aggiungere questa riga nell'host appropriato in {{ic|/etc/ssh/ssh_config}}:
 
  Compression yes
 
  Compression yes
Il tempo di login può essere diminuito usando il flag {{Codeline|"4"}}, che bypassa IPv6 lookup. Ciò può essere reso permanente con l'aggiunta di questa riga nell'host appropriato in {{Filename|/etc/ssh/ssh_config}}:
+
Il tempo di login può essere diminuito usando il flag {{ic|"4"}}, che bypassa IPv6 lookup. Ciò può essere reso permanente con l'aggiunta di questa riga nell'host appropriato in {{ic|/etc/ssh/ssh_config}}:
 
  AddressFamily inet
 
  AddressFamily inet
Un altro modo di fare queste modifiche è sempre quella di creare un alias in {{Filename|~/.bashrc}}:
+
Un altro modo di fare queste modifiche è sempre quella di creare un alias in {{ic|~/.bashrc}}:
 
  alias ssh='ssh -C4c arcfour,blowfish-cbc'
 
  alias ssh='ssh -C4c arcfour,blowfish-cbc'
Infine, si possono realizzarere tutte le sessioni con lo stesso host usando una singola connessione, il che velocizza notevolmente i login successivi, aggiungendo queste righe nell'host appropriato in {{Filename|/etc/ssh/ssh_config}}:
 
ControlMaster auto
 
ControlPath ~/.ssh/socket-%r@%h:%p
 
 
=== Risoluzione dei problemi ===
 
  
 +
====Risoluzione di problemi====
 
Assicurarsi che la stringa DISPLAY punti sul server remoto:
 
Assicurarsi che la stringa DISPLAY punti sul server remoto:
  
Line 331: Line 371:
 
  localhost/6010: lookup failure: Temporary failure in name resolution   
 
  localhost/6010: lookup failure: Temporary failure in name resolution   
  
la soluzione possibile è aggiungendo localhost a {{Filename|/etc/hosts}}.
+
la soluzione possibile consiste nell'aggiungere {{ic|localhost}} al file {{ic|/etc/hosts}}.
  
== Montaggio di un filesystem remoto con SSHFS ==
+
===Montaggio di un filesystem remoto con SSHFS===
 +
Installare il pacchetto {{Pkg|sshfs}}
  
Installare sshfs
+
Caricare il modulo {{ic|fuse}}
# pacman -S sshfs
+
 
+
Caricare il modulo fuse
+
 
  # modprobe fuse
 
  # modprobe fuse
Aggiungere fuse alla stringa ''modules'' in {{Filename|/etc/rc.conf}} per caricarlo ad ogni avvio del sistema.
+
Aggiungere {{ic|fuse}} all'array {{ic|MODULES}} nel file {{ic|/etc/rc.conf}} per caricarlo ad ogni avvio del sistema.
  
 
Montare la cartella remota con sshfs
 
Montare la cartella remota con sshfs
Line 351: Line 389:
 
  # fusermount -u ~/remote_folder
 
  # fusermount -u ~/remote_folder
  
Avendo la necessità di lavorare su questa cartella quotidianamente, può risultare comodo aggiungerla alla tabella di montaggio di {{Filename|/etc/fstab}}. In questo modo la si può avere montata automaticamente all'avvio del sistema o da montare manualmente (se si sceglie l'opzione {{Codeline|noauto}}), senza la necessità di specificare la posizione remota ogni volta. Ecco un esempio di voce aggiunta nella tabella:
+
Avendo la necessità di lavorare su questa cartella quotidianamente, può risultare comodo aggiungerla alla tabella di montaggio di {{ic|/etc/fstab}}. In questo modo la si può avere montata automaticamente all'avvio del sistema o da montare manualmente (se si sceglie l'opzione {{ic|noauto}}), senza la necessità di specificare la posizione remota ogni volta. Ecco un esempio di voce aggiunta nella tabella:
 
  sshfs#USER@remote_server:/tmp /full/path/to/directory fuse    defaults,auto,allow_other    0 0
 
  sshfs#USER@remote_server:/tmp /full/path/to/directory fuse    defaults,auto,allow_other    0 0
  
=== Mantenere la sessione attiva ===
+
===Mantenere la sessione attiva===
 +
La sessione SSH effettuerà  automaticamente un log out dopo un certo tempo di inattività. Per mantenere la connessione attiva aggiungere in {{ic|~/.ssh/config}} o in {{ic|/etc/ssh/ssh_config}} del client, la seguente riga:
 +
 
 +
ServerAliveInterval 120
 +
 
 +
Questo invierà un segnale di "mantenimento di stato attivo" al server ogni 120 secondi.
 +
 
 +
Invece per mantenere le connessioni in entrata attive, si può impostare
 +
 
 +
ClientAliveInterval 120
 +
 
 +
(oppure un qualsiasi numero maggiore di 0) nel file {{ic|/etc/ssh/sshd_config}} del server.
 +
 
 +
===Salvare i dati di connessione in .ssh/config===
 +
Ogni volta che ci si connette ad un server SSH, è necessario digitare il suo indirizzo ed il nome utente. Per evitare di scrivere questi dati ogni volta per i server a cui siamo soliti connetterci, è possibile utilizzare il file {{ic|$HOME/.ssh/config}} oppure il file di configurazione globale {{ic|/etc/ssh/ssh_config}} come nel seguente esempio:
 +
 
 +
{{hc|$HOME/.ssh/config|2=<nowiki>
 +
Host myserver
 +
    HostName 123.123.123.123
 +
    Port 12345
 +
    User bob
 +
Host other_server
 +
    HostName test.something.org
 +
    User alice
 +
    CheckHostIP no
 +
    Cipher blowfish
 +
</nowiki>}}
 +
 
 +
Adesso sarà possibile connettersi al server usando il nome che si è specificato:
 +
 
 +
$ ssh myserver
 +
 
 +
Per una lista completa delle opzioni che si posso utilizzare, consultare il manuale di ssh_config del proprio sistema oppure [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config la documentazione di ssh_config] sul sito ufficiale.
 +
 
 +
===Cambiare la promt di accesso di SSH===
 +
Può essere utile distinguere la shell locale da quella remota, in particolare quando entrambe sono configurate allo stesso modo. Per fare ciò basterà semplicemente inserire questo nel proprio bashrc:
 +
 
 +
{{hc|$HOME/.bashrc|2=<nowiki>
 +
 
 +
if [ -n "$SSH_CLIENT" ]; then
 +
        PS1='\[\e[0;33m\]\u@\h:\wSSH$\[\e[m\] '
 +
else
 +
        PS1='\[\e[0;32m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[1;32m\]\$\[\    e[m\] '
 +
fi</nowiki>}}
 +
 
 +
Vedi [[Color Bash Prompt (Italiano)|Color Bash Promt]] per maggiori informazioni riguardo alla personalizzazione della variabile PS1.
 +
 
 +
===Effettuare il logout automatico degli utenti ssh quando il server si spegne===
 +
Per chiudere automaticamente le connessioni degli utenti collegati via SSH quando il server viene spento o per un riavvio, aggiungere questa linea al file {{ic|/etc/rc.local.shutdown}} del server SSH:
 +
 
 +
who | cut -d " " -f1 | uniq | xargs pkill -KILL -u
 +
 
 +
Questo evita che i terminali dei client restino bloccati per un lungo tempo, ed eventualmente terminino con il messaggio:
 +
 
 +
Write failed: Broken pipe
 +
 
 +
==Risoluzione di problemi==
 +
===Connection Refused===
 +
====SSH è in esecuzione, ed in ascolto sulla porta?====
 +
# netstat -tnlp | grep ssh
 +
 
 +
Se il precedente comando non mostra alcun output, allora SSH '''non''' è in esecuzione. Controllare il file {{ic|/var/log/messages}} per trovare i messaggi di errore.
 +
 
 +
====Le regole del firewall stanno bloccando la connessione?====
 +
Fermare il firewall per assicurarsi che non sia esso a bloccare le connessioni in entrata:
 +
 
 +
# rc.d stop iptables
 +
 
 +
oppure
 +
 
 +
# iptables -P INPUT ACCEPT
 +
# iptables -P OUTPUT ACCEPT
 +
# iptables -F INPUT
 +
# iptables -F OUTPUT
 +
 
 +
====Il computer è raggiungibile dalle richieste?====
 +
Avviare un dump del traffico sul server che restituisce l'errore:
 +
 
 +
# tcpdump -lnn -i any port ssh and tcp-syn
 +
 
 +
Questo comando dovrebbe mostrare alcune informazioni di base, fino a che non si ottengo le informazioni relative al traffico(in questo caso al traffico di SSH). Se non si ottiene nessun risultato nel tentare la connessione, allora qualcosa al di fuori del computer blocca il traffico (es. firewall hardware, NAT, router ecc.).
 +
 
 +
====Read from socket failed: Connection reset by peer====
 +
Le recenti versioni di OpenSSH a volte, falliscono segnalando il precedente messaggio di errore, a causa di un bug riguardante la crittografia ECDSA. In questo caso, modificare il file {{ic|~/.ssh/config}} o crearlo, se non esiste. Aggiungere la seguente linea:
 +
 
 +
{{hc|~/.ssh/config|2=<nowiki>.....
 +
HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
 +
.....</nowiki>}}
 +
 
 +
Dalla versione 5.9 di OpenSSH, il fix precedente non funziona. Inserire invece le seguenti righe nel file {{ic|~/.ssh/config}}
  
La sessione ssh effettuerà automaticamente un log out dopo un certo tempo di inattività. Per mantenere la connessione attiva aggiungere in {{Filename|~/.ssh/config}} o in {{Filename|/etc/ssh/ssh_config}} del client, la seguente riga:
+
  Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
 +
MACs hmac-md5,hmac-sha1,hmac-ripemd160
  
ServerAliveInterval 5
+
Leggere anche [http://www.gossamer-threads.com/lists/openssh/dev/51339 la discussione] sul forum dei bug di OpenSSH.
  
Questo invierà un segnale di "mantenimento di stato attivo" al server ogni 5 secondi. È possibile incrementare questo intervallo, impostando, per esempio, 120.
+
==="[nome della shell in uso]: No such file or directory" / ssh_exchange_identification Problem===
 +
Una possibile causa di questo errore, è causata da alcuni client SSH che necessitano di un cammino assoluto (può essere ottenuto con il comando {{ic|whereis -b [nome della shell in uso]}}, ad esempio) nella variabile {{ic|$SHELL}}, anche se l'eseguibile della shell si trova all'interno di uno dei percorsi specificati nella variabile {{ic|$PATH}}. Un altra ragione può essere che l'utente non appartiene al [[Users and Groups (Italiano)#Gruppi|gruppo]] {{ic|network}}.
  
= Ulteriori informazioni =
+
==Altre risorse==
*[[Using SSH Keys]]
+
*[[SSH Keys (Italiano)|Chiavi SSH]]
 +
*[[Pam_abl]]
 +
*[[fail2ban]]
 +
*[[sshguard]]
 +
*[[Sshfs (Italiano)|Sshfs]]
  
= Link e Riferimenti =
+
==Link e riferimenti==
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]
+
*[http://www.soloport.com/iptables.html Rimedi ai comuni attacchi di accesso a SSH]
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]
+
*[http://webssh.cz.cc Usare il proprio browser come client SSH]
 +
*[http://www.la-samhna.de/library/brutessh.html Difenersi dagli attacchi di tipo brute force]

Revision as of 11:44, 16 December 2012

Secure Shell (SSH) è un protocollo di rete che consente lo scambio di dati su un canale protetto tra due computer. Encryption si incarica della riservatezza e l'integrità dei dati. SSH utilizza la crittografia a chiave pubblica per autenticare il computer remoto e permettere allo stesso di autenticarne l'utente, se necessario.

SSH è in genere utilizzato per accedere a una macchina remota ed eseguire comandi, ma supporta anche il tunneling, l'inoltro (forwarding arbitrary) su porte TCP e connessioni X11; il trasferimento dei file può essere eseguito utilizzando i protocolli associati SFTP o SCP.

Un server SSH rimane, in maniera predefinita, in ascolto sulla porta standard TCP 22. Un programma client SSH viene in genere utilizzato per stabilire le connessioni a un demone sshd che accetta connessioni remote. Entrambi sono comunemente presenti nei sistemi operativi più moderni, incluso Mac OS X, GNU/Linux, Solaris e OpenVMS. Esistono versioni proprietarie, freeware e open source a vari livelli, sia di complessità che di completezza.

(Fonte: Wikipedia:Secure Shell)

OpenSSH

OpenSSH (OpenBSD Secure Shell) è un insieme di programmi per computer che forniscono sessioni di comunicazione criptate su una rete di computer usando il protocollo SSH. È stato creato come alternativa open source al software proprietario Secure Shell suite, offerto da SSH Communications Security. OpenSSH è sviluppato come parte del progetto OpenBSD, che è guidato da Theo de Raadt.

OpenSSH è a volte confuso con OpenSSL per la somiglianza del nome, tuttavia, i progetti hanno scopi diversi e sono sviluppati da team differenti. La similitudine del nome è derivata solamente da obiettivi simili.

Installazione di OpenSSH

Installare il pacchetto openssh

Configurazione di SSH

Client

Il file di configurazione del client SSH può essere trovato e modificato in /etc/ssh/ssh_config.

Un esempio di configurazione:

/etc/ssh/ssh_config
#	$OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com

Si consiglia di modificare la riga del protocollo in questo modo:

Protocol 2

Ciò significa che sarà utilizzato solo il protocollo 2, dal momento che il protocollo 1 è considerato poco sicuro.

Daemon

Il file di configurazione del demone SSH può essere trovato e modificato in /etc/ssh/sshd_config.

Un esempio di configurazione:

/etc/ssh/sshd_config
#	$OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys

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

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# 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 yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	/usr/lib/ssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs serveri

Per consentire l'accesso solo ad alcuni utenti aggiungere questa riga:

AllowUsers    user1 user2

Per disabilitare l'accesso SSH per l'utente root, aggiungere la seguente linea:

PermitRootLogin no

Si potrebbe anche rimuovere l'opzione BANNER e modificare il file /etc/issue per un gradevole messaggio di benvenuto.

Tip: Si consiglia di modificare la porta di default 22 ad una di numero più alto (consultare security through obscurity).

Anche se la porta SSH è in esecuzione e può essere rilevata utilizzando un port scanner come nmap, cambiandola si ridurrà il numero di voci del registro di log, causato dai tentativi di autenticazione automatica. Per un aiuto sulla scelta della porta consultare la lista dei numeri delle porte TCP ed UDP.

Tip: Disabilitando gli accessi con la password, aumenta il livello di sicurezza. (consultare SSH Keys).

Gestione demone SSHD

Aggiungere sshd alla lista di demoni DAEMONS nel file /etc/rc.conf:

Per avviare/riavviare/fermare il demone, usare il seguente comando (da root):

# rc.d {start|stop|restart} sshd

Connessione al server

Per connettersi ad un server, dare il comando:

$ ssh -p port user@server-address

Trucchi e consigli

Tunnel criptati

Questo tipo di collegamento è molto utile per, ad esempio, l'utenza laptop collegata a varie connessioni wireless non sicure. L'unica cosa necessaria è un server SSH in esecuzione in un qualche luogo sicuro, come casa o il luogo di lavoro. Potrebbe essere utile l'utilizzo di un servizio DNS dinamico come DynDNS in modo da non dover ricordare l'indirizzo IP a cui ci si vuole collegare.

Step 1: Avviare la connessione

È sufficiente eseguire questo comando nel terminale preferito per avviare la connessione:

$ ssh -ND 4711 user@host

dove "user" è il nome utente del server SSH in esecuzione sull' "host". Verrà richiesta la password, e la connessione sarà stabilita! Il flag "N" disabilita il prompt interattivo, il flag "D" specifica la porta locale su cui ascoltare (si può scegliere qualsiasi numero di porta).

Un modo per facilitare questa operazione è quello di mettere una riga di "alias" nel file ~/.bashrc come segue:

alias sshtunnel="ssh -ND 4711 -v user@host"

Può risultare utile aggiungere il flag "verbose" "-v", in modo da poter verificare dall'output che si è realmente connessi. Ora basta eseguire il comando "sshtunnel"

Step 2: Configurare il Browser (o altri programmi)

Il passo precedente è del tutto inutile se non si configura il browser web (o altri programmi) da utilizzare con il tunnel appena creato. A partire dalla corrente versione di SSH sono supportati sia SOCKS4 che SOCKS5 sarà possibile scegliere uno dei due.

  • Per Firefox: Modificare → Preferenze → Avanzate → Rete → Connessione → Impostazioni:
Controllare il bottone "Configurazione manuale del proxy", ed immettere "localhost" nel campo testuale "SOCKS host", ed immettere infine il numero della porta nel prossimo campo testuale (usata in questo caso la 4711, come sopra).

Firefox non effettua automaticamente le richieste DNS attraverso il tunnel. Questo inconveniente riguardo alla privacy può essere ovviato con questi passi:

  1. digitare about:config nella barra dell'indirizzo di Firefox.
  1. cercare la chiave network.proxy.socks_remote_dns
  1. impostare il valore a true-
  1. riavviare il browser.
  • Per Chromium: è possibile configurare le impostazioni del SOCKS come variabili di ambiente oppure come opzione di lancio da riga di comando. Il metodo raccomandato consiste nell'inserire una delle seguenti funzioni nel proprio .bashrc:
function secure_chromium {
  port=4711
  export SOCKS_SERVER=localhost:$port
  export SOCKS_VERSION=5
  chromium &
  exit
}

oppure

function secure_chromium {
  port=4711
  chromium --proxy-server="socks://localhost:$port" &
}

In questo modo basterà digitare nel terminale:

$ secure_chromium

Godetevi il vostro tunnel sicuro!

X11 Forwarding

Per eseguire programmi grafici tramite una connessione SSH è possibile attivare X11 forwarding. Un'opzione dovrà essere impostata nel file di configurazione sul server e client (dove "client" significa la propria macchina (desktop) sulla quale il server X11 è in esecuzione, e le applicazioni in X verranno eseguite sul "server").

Installare il pacchetto xorg-xauth sul server.

  • Abilitare l'opzione AllowTcpForwarding in sshd_config sul server.
  • Abilitare l'opzione X11Forwarding in sshd_config sul server.
  • Abilitare l'opzione X11DisplayOffset in sshd_config sul server e impostare su 10.
  • Abilitare l'opzione X11UseLocalhost in sshd_config sul server.

Inoltre sarà necessario:

  • Abilitare l'opzione ForwardX11 in ssh_config sul client.

Abilitare l'opzione ForwardX11Trusted può essere utile nel caso che le interfacce grafiche vengano visualizzate male.

Per usare il forwarding, accedere al server con SSH:

$ ssh -X -p port user@server-address

Nel caso vengano restituiti degli errori avviando applicazioni grafiche, provare con il trusted forwarding:

$ ssh -Y -p port user@server-address

Sarà possibile avviare ora qualsiasi programma X sul server remoto, l'output sarà trasmesso alla sessione locale:

$ xclock

Se si ottiene l'errore "Cannot open display" provare i seguenti comandi come utente normale, non come root:

$ xhost +

Il precedente comando consentira a tutti i client di effettuare il forward delle applicazioni grafiche(X11). Per restringere l'accesso a determinati client:

$ xhost +nomemacchina

Dove nomemacchina è il nome della macchina a cui si vuole garantire l'accesso. Digitare "man xhost" per maggiori informazioni.

Alcune applicazioni verificano la presenza di altre istanze sulla macchina locale. Ad esempio Firefox. Sarà necessario quindi chiudere l'applicazione oppure usare la seguente opzione per avviare una sessione remota dalla macchina locale.

$ firefox -no-remote

Effettuare il Forwarding di altre porte

In aggiunta al supporto nativo per X11, SSH può essere usato per incanalare in un tunnel sicuro qualsiasi connessione TCP, usando il forwarding locale o remoto.

Il forwarding locale apre una porta sulla macchina locale, tutte le connessioni ad essa saranno inviate all'host remoto e da quindi ad una specifica destinazione. Molto spesso, la destinazione finale sarà la solita dell'host remoto, questo fornisce una shell sicura ed, ad esempio, una connessione VNC sicura, alla stessa macchina. Il forwarding locale viene specificato mediante l'uso dell'opzione -L e seguita dalle appropriate impostazioni per il forwarding in questa forma <porta tunnel>:<indirizzo destinazione>:<porta destinazione>.

Ad esempio:

$ ssh -L 1000:mail.google.com:25 192.168.0.100

utilizzerà SSH per effettuare il login ad una shell remota sul server 192.168.0.100, ed inoltre creerà un tunnel dalla porta 1000 TCP locale alla destinazione remota mail.google.com alla porta 25. Una volta stabilita la connessione, tutte le connessioni a localhost:1000 verranno indirizzate al servizio SMTP di Gmail. A Google, risulterà che ogni richiesta (ma non necessariamente i dati inviati dalla connessione) provenga da 192.168.0.100, inoltre questi dati saranno criptati nel transito dalla macchina locale al server 192.168.0.100, ma non oltre 192.168.0.100, a meno che non vengano presi provvedimenti al riguardo.

Similmente:

$ ssh -L 2000:192.168.0.100:6001 192.168.0.100

permetterà alle connessioni verso localhost:2000 di essere inviate all'host remoto alla porta 6001. Il precedente esempio è molto utile per le connessioni VNC, ad esempio, usando l'utility vncserver (parte delle applicazioni fornite dal pacchetto tightvnc, il quale non fornisce misure di sicurezza proprie.

Il remote forwarding permette alla macchina remota di connettersi ad un host tramite il tunnel SSH e la la macchina locale, fornendo una funzione inversa al forwarding locale, questo risulta utile, ad esempio, nel caso in cui l'host remoto ha una connettività limitata a causa di un firewall. Il remote forwarding viene specificato dall'opzione -R ed alle impostazioni del forwarding nella forma <porta tunnel>:<indirizzo destinazione>:<porta destinazione>.

Ad esempio:

$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200

aprirà una shell sul server 195.168.0.200, e le connessioni provenienti da 192.168.0.200 a se stesso sulla porta 3000(parlando in termini remoti localhost:3000) verranno inviate attraverso il tunnel verso la macchina locale e poi verso irc.freenode.net alla porta 6667, quindi, in questo esempio, permetterà l'uso dei programmi IRC sulla macchina remota anche se normalmente la porta 6667 sarebbe chiusa.

Entrambi i tipi di forwarding locale e remoto possono essere usati per creare un "gateway" sicuro permettendo agli altri computer di godere dei vantaggi di un tunnel SSH, senza dover eseguire un client SSH oppure un demone SSH fornendo un indirizzo di ascolto per definire l'inizio del tunnel come argomento del forwarding, nella forma: <indirizzo tunnel>:<porta tunnel>:<indirizzo destinazione>:<porta destinazione>.

<indirizzo tunnel> può essere un qualsiasi indirizzo sulla macchina all'inizio del tunnel, localhost, * (oppure lasciato in bianco), che rispettivamente, permettono connessioni tramite uno specifico indirizzo, tramite l'interfaccia di loopback, oppure tramite qualunque interfaccia. Come default, il forwarding è limitato alle connessioni provenienti dalla macchina all'inizio del tunnel, quindi <tunnel address> è impostato su localhost. Il forwarding locale non richiede configurazioni addizionali, mentre il forwarding remoto è condizionato dalle configurazioni del demone SSH sulla macchina remota. Per maggiori informazioni consultare le informazioni riguardo all'opzione GatewayPorts nella pagina di manuale sshd_config(5).

Velocizzare SSH

Sarà possibile che tutte le sessioni con lo stesso host utilizzino una singola connessione, il che velocizza notevolmente i login successivi, aggiungendo queste righe nell'host appropriato in /etc/ssh/ssh_config:

ControlMaster auto
ControlPath ~/.ssh/socket-%r@%h:%p

Modificando i valori usati da SSH per una minore richiesta di risorse cpu può aumentarne la velocità. Sotto questo aspetto, le scelte migliori ricadono su arcfour e blowfish-cbc. Non usare queste opzioni a meno che non si sappia ciò che si sta facendo; arcfour ha alcune vulnerabilità note. Per provarli, avviare SSH con il flag "c", in questo modo:

$ ssh -c arcfour,blowfish-cbc user@server-address

Per renderne l'utilizzo predefinito, aggiungere questa riga sotto il proper host in /etc/ssh/ssh_config:

Ciphers arcfour,blowfish-cbc

Un'altra opzione per aumentare la velocità è abilitare la compressione con il flag "C". Una soluzione permanente è aggiungere questa riga nell'host appropriato in /etc/ssh/ssh_config:

Compression yes

Il tempo di login può essere diminuito usando il flag "4", che bypassa IPv6 lookup. Ciò può essere reso permanente con l'aggiunta di questa riga nell'host appropriato in /etc/ssh/ssh_config:

AddressFamily inet

Un altro modo di fare queste modifiche è sempre quella di creare un alias in ~/.bashrc:

alias ssh='ssh -C4c arcfour,blowfish-cbc'

Risoluzione di problemi

Assicurarsi che la stringa DISPLAY punti sul server remoto:

ssh -X user@server-address
server$ echo $DISPLAY
localhost:10.0
server$ telnet localhost 6010
localhost/6010: lookup failure: Temporary failure in name resolution   

la soluzione possibile consiste nell'aggiungere localhost al file /etc/hosts.

Montaggio di un filesystem remoto con SSHFS

Installare il pacchetto sshfs

Caricare il modulo fuse

# modprobe fuse

Aggiungere fuse all'array MODULES nel file /etc/rc.conf per caricarlo ad ogni avvio del sistema.

Montare la cartella remota con sshfs

# mkdir ~/remote_folder
# sshfs USER@remote_server:/tmp ~/remote_folder

Il comando sopra farà sì che la cartella /tmp sul server remoto verrà montata come ~/remote_folder sulla macchina locale. La copia di qualsiasi file in questa cartella, comporterà una copia trasparente attraverso la rete utilizzando SFTP. Lo stesso si avrà per la modifica dei file, la copia e l'eliminazione.

Una volta terminato il lavoro con il file system remoto, si può smontare la cartella remota mediante il comando:

# fusermount -u ~/remote_folder

Avendo la necessità di lavorare su questa cartella quotidianamente, può risultare comodo aggiungerla alla tabella di montaggio di /etc/fstab. In questo modo la si può avere montata automaticamente all'avvio del sistema o da montare manualmente (se si sceglie l'opzione noauto), senza la necessità di specificare la posizione remota ogni volta. Ecco un esempio di voce aggiunta nella tabella:

sshfs#USER@remote_server:/tmp /full/path/to/directory fuse    defaults,auto,allow_other    0 0

Mantenere la sessione attiva

La sessione SSH effettuerà automaticamente un log out dopo un certo tempo di inattività. Per mantenere la connessione attiva aggiungere in ~/.ssh/config o in /etc/ssh/ssh_config del client, la seguente riga:

ServerAliveInterval 120

Questo invierà un segnale di "mantenimento di stato attivo" al server ogni 120 secondi.

Invece per mantenere le connessioni in entrata attive, si può impostare

ClientAliveInterval 120

(oppure un qualsiasi numero maggiore di 0) nel file /etc/ssh/sshd_config del server.

Salvare i dati di connessione in .ssh/config

Ogni volta che ci si connette ad un server SSH, è necessario digitare il suo indirizzo ed il nome utente. Per evitare di scrivere questi dati ogni volta per i server a cui siamo soliti connetterci, è possibile utilizzare il file $HOME/.ssh/config oppure il file di configurazione globale /etc/ssh/ssh_config come nel seguente esempio:

$HOME/.ssh/config
Host myserver
    HostName 123.123.123.123
    Port 12345
    User bob
Host other_server
    HostName test.something.org
    User alice
    CheckHostIP no
    Cipher blowfish

Adesso sarà possibile connettersi al server usando il nome che si è specificato:

$ ssh myserver

Per una lista completa delle opzioni che si posso utilizzare, consultare il manuale di ssh_config del proprio sistema oppure la documentazione di ssh_config sul sito ufficiale.

Cambiare la promt di accesso di SSH

Può essere utile distinguere la shell locale da quella remota, in particolare quando entrambe sono configurate allo stesso modo. Per fare ciò basterà semplicemente inserire questo nel proprio bashrc:

$HOME/.bashrc

if [ -n "$SSH_CLIENT" ]; then
        PS1='\[\e[0;33m\]\u@\h:\wSSH$\[\e[m\] '
else
        PS1='\[\e[0;32m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[1;32m\]\$\[\    e[m\] '
fi

Vedi Color Bash Promt per maggiori informazioni riguardo alla personalizzazione della variabile PS1.

Effettuare il logout automatico degli utenti ssh quando il server si spegne

Per chiudere automaticamente le connessioni degli utenti collegati via SSH quando il server viene spento o per un riavvio, aggiungere questa linea al file /etc/rc.local.shutdown del server SSH:

who | cut -d " " -f1 | uniq | xargs pkill -KILL -u

Questo evita che i terminali dei client restino bloccati per un lungo tempo, ed eventualmente terminino con il messaggio:

Write failed: Broken pipe

Risoluzione di problemi

Connection Refused

SSH è in esecuzione, ed in ascolto sulla porta?

# netstat -tnlp | grep ssh

Se il precedente comando non mostra alcun output, allora SSH non è in esecuzione. Controllare il file /var/log/messages per trovare i messaggi di errore.

Le regole del firewall stanno bloccando la connessione?

Fermare il firewall per assicurarsi che non sia esso a bloccare le connessioni in entrata:

# rc.d stop iptables

oppure

# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -F INPUT
# iptables -F OUTPUT

Il computer è raggiungibile dalle richieste?

Avviare un dump del traffico sul server che restituisce l'errore:

# tcpdump -lnn -i any port ssh and tcp-syn

Questo comando dovrebbe mostrare alcune informazioni di base, fino a che non si ottengo le informazioni relative al traffico(in questo caso al traffico di SSH). Se non si ottiene nessun risultato nel tentare la connessione, allora qualcosa al di fuori del computer blocca il traffico (es. firewall hardware, NAT, router ecc.).

Read from socket failed: Connection reset by peer

Le recenti versioni di OpenSSH a volte, falliscono segnalando il precedente messaggio di errore, a causa di un bug riguardante la crittografia ECDSA. In questo caso, modificare il file ~/.ssh/config o crearlo, se non esiste. Aggiungere la seguente linea:

~/.ssh/config
.....
HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
.....

Dalla versione 5.9 di OpenSSH, il fix precedente non funziona. Inserire invece le seguenti righe nel file ~/.ssh/config

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc 
MACs hmac-md5,hmac-sha1,hmac-ripemd160

Leggere anche la discussione sul forum dei bug di OpenSSH.

"[nome della shell in uso]: No such file or directory" / ssh_exchange_identification Problem

Una possibile causa di questo errore, è causata da alcuni client SSH che necessitano di un cammino assoluto (può essere ottenuto con il comando whereis -b [nome della shell in uso], ad esempio) nella variabile $SHELL, anche se l'eseguibile della shell si trova all'interno di uno dei percorsi specificati nella variabile $PATH. Un altra ragione può essere che l'utente non appartiene al gruppo network.

Altre risorse

Link e riferimenti