Difference between revisions of "Secure Shell (Italiano)"

From ArchWiki
Jump to: navigation, search
m (updated)
m (velocizzare SSH: updated)
Line 356: Line 356:
 
  ControlPath ~/.ssh/socket-%r@%h:%p
 
  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. Per provarli, avviare SSH con il flag {{Codeline|"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. '''Non usare queste opzioni a meno che non si sappia ciò che si sta facendo; arcfour ha alcune vulnerabilià note.'''  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 {{Filename|/etc/ssh/ssh_config}}:
 
Per renderne l'utilizzo predefinito, aggiungere questa riga sotto il proper host in {{Filename|/etc/ssh/ssh_config}}:

Revision as of 18:13, 15 September 2011

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی


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.

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

# pacman -S openssh

Configurazione di SSH

Client

Il file di configurazione del client SSH può essere trovato e modificato in Template:Filename.

Un esempio di configurazione:

Template:File

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 Template:Filename.

Un esempio di configurazione:

Template:File


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

Template:File

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

Si potrebbe anche rimuovere l'opzione BANNER e modificare il file Template:Filename 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.

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

Gestione demone SSHD

Aggiungere sshd alla stringa "DAEMONS" del file Template:Filename:

DAEMONS=(... ... sshd ... ...)

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

Suggerimenti

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 Template:Codeline è il nome utente del server SSH in esecuzione sull' Template:Codeline. Verrà richiesta la password, e la connessione sarà stabilita! Il flag Template:Codeline disabilita il prompt interattivo, il flag Template:Codeline 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 Template:Filename come segue:

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

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

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 Template:Codeline nella barra dell'indirizzo di Firefox.
  1. cercare la chiave Template:Codeline
  1. impostare il valore a Template:Codeline-
  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 Template:Filename:
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 xorg-xauth sul server:

# pacman -S xorg-xauth

Inoltre sarà necessario:

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 "Template:Codeline" 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

Forwarding Other Ports

In addition to SSH's built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.


Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the Template:Codeline switch and it's accompanying forwarding specification in the form of Template:Codeline.

Thus:

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

will use SSH to login to and open a shell on 192.168.0.100, and will also create a tunnel from the local machine's TCP port 1000 to mail.google.com on port 25. Once established, connections to localhost:1000 will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from 192.168.0.100, and such data will be secure as between the local machine and 192.168.0.100, but not between 192.168.0.100, unless other measures are taken.

Similarly:

$ ssh -L 2000:192.168.0.100:6001 192.168.0.100

will allow connections to localhost:2000 which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility--part of the tightvnc package--which, though very useful, is explicit about its lack of security.

Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the Template:Codeline switch and a forwarding specification in the form of Template:Codeline.

Thus:

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

will bring up a shell on 192.168.0.200, and connections from 192.168.0.200 to itself on port 3000 (remotely speaking, localhost:3000) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.

Both local and remote forwarding can be used to provide a secure "gateway," allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g. Template:Codeline. The Template:Codeline can be any address on the machine at the start of the tunnel, Template:Codeline, Template:Codeline (or blank), which, respectively, allow connections via the given address, via the loopback interface, or via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the Template:Codeline is set to Template:Codeline. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the Template:Codeline option in Template:Codeline for more information.

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 Template:Filename:

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 vulnerabilià note. Per provarli, avviare SSH con il flag Template:Codeline, in questo modo:

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

Per renderne l'utilizzo predefinito, aggiungere questa riga sotto il proper host in Template:Filename:

Ciphers arcfour,blowfish-cbc

Un'altra opzione per aumentare la velocità è abilitare la compressione con il flag Template:Codeline. Una soluzione permanente è aggiungere questa riga nell'host appropriato in Template:Filename:

Compression yes

Il tempo di login può essere diminuito usando il flag Template:Codeline, che bypassa IPv6 lookup. Ciò può essere reso permanente con l'aggiunta di questa riga nell'host appropriato in Template:Filename:

AddressFamily inet

Un altro modo di fare queste modifiche è sempre quella di creare un alias in Template:Filename:

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

Risoluzione dei 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 è aggiungendo localhost a Template:Filename.

Montaggio di un filesystem remoto con SSHFS

Installare sshfs

# pacman -S sshfs

Caricare il modulo fuse

# modprobe fuse

Aggiungere fuse alla stringa modules in Template:Filename 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 Template:Filename. In questo modo la si può avere montata automaticamente all'avvio del sistema o da montare manualmente (se si sceglie l'opzione Template:Codeline), 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 Template:Filename o in Template:Filename 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 Template:Filename 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 Template:Filename oppure il file di configurazione globale Template:Filename come nel seguente esempio:

Template:File

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:

Template:File

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

Risoluzione dei 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 Template:Filename 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 precedendte messaggio di errore, a causa di un bug riguradante la crittografia ECDSA. In questo caso, modificare il file Template:Filename o crearlo, se non esiste. Aggiungere la seguente linea:

Template:File

Dalla versione 5.9 di openssh, il fix precedente non funziona. Inserire invece le seguenti righe nel file Template:Filename

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.

Ulteriori informazioni

Link e Riferimenti