Con SUSE Linux viene installato di default il pacchetto OpenSSH. Avrete a vostra disposizione i programmi ssh, scp e sftp, come alternativa a telnet, rlogin, rsh, rcp e ftp. Nella configurazione di default, si potrà accedere ad un sistema SUSE Linux solo tramite utility OpenSSH e solo se il firewall consente l'accesso.

Con il programma ssh, potete stabilire un collegamento ad un sistema remoto e lavorarci interattivamente. Questo programma sostituisce quindi sia telnet che rlogin. Il programma slogin è solo un link simbolico che rimanda a ssh. Per fare un esempio: con il comando ssh  sun, si può accedere al sistema sun che vi chiederà la vostra password.

Dopo l'autenticazione, potrete lavorare sia dalla riga di comando che interattivamente, p.es. con YaST. Se il nome utente locale e quello sul sistema remoto differiscono, potete indicare un nome differente p.es. ssh -l augusto sun o ssh augusto@sun.

Inoltre, ssh offre la possibilità, già nota in rsh, di eseguire dei comandi su un altro sistema. Nel seguente esempio, viene eseguito il comando uptime su sun e creata una directory con il nome tmp. L'output del programma viene visualizzato sul terminale locale del sistema earth.

ssh  altropianeta "uptime; mkdir tmp"
tux@password_di_altropianeta:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

Le virgolette servono qui per riunire le due istruzioni in un comando; solo così verrà eseguito anche il secondo comando sul sistema sun.

Per mezzo di scp potete copiare dei file su un host remoto. scp è il sostituto cifrato e sicuro di rcp. Per esempio, scp miotesto.tex sun: copia il file miotesto.tex dal sistema earth sul sistema sun. Se il nome utente su earth differisce da quello su sun, potete impostare quest'ultimo con nomeutente@nomehost. Non esiste un'opzione -l per questo comando.

Dopo aver immesso la password, scp inizia con la trasmissione dei dati e ne indica lo stato di avanzamento con una barra formata da asterischi che cresce da sinistra a destra. Inoltre, sul margine destro viene mostrato il tempo rimanente (stimato) per la trasmissione (ingl. estimated time of arrival). Ogni output può venire soppresso con l'opzione -q.

scp consente non solo di copiare singoli file ma offre anche una funzionalità di copiatura ricorsiva per poter copiare intere directory: scp -r src/ sun:backup/ copia l'intero contenuto della directory src/ sottodirectory incluse su sun e lì nella sottodirectory backup/. Se questa sottodirectory non dovesse ancora esistere, viene generata automaticamente.

Per mezzo dell'opzione -p, scp non modifica la datazione dei file. -C provvede ad una trasmissione compressa. In questo modo, viene ridotto al minimo il volume dei dati da trasmettere, anche se questo processo comporta un considerevole carico di lavoro per il processore.

Al posto di scp si può usare sftp. Una sessione sftp offre molti dei comandi noti di ftp. Rispetto a scp si rivela vantaggioso soprattutto quando si trasmettono dati di cui si ignorano i nomi dei file.

Affinché possano venire utilizzati i programmi client del pacchetto SSH, ossia ssh e scp, un server, in questo caso il demone di SSH, deve girare in sottofondo, e mettersi in ascolto su TCP/IP port 22. Durante il primo avvio, il demone genera tre paia di chiavi composte da una parte privata e da una pubblica. Per questo si usa definire questo approccio come procedimento basato su chiave pubblica. Per garantire una comunicazione sicura tramite SSH, solo l'amministratore deve poter accedere ai file delle chiavi private. A questo scopo, i permessi dei file vengono impostati (preimpostati) in modo molto restrittivo durante l'installazione di default. Le chiavi private sono richiese localmente solo dal demone SSH e non devono venir trasmesse a nessun altro. Le chiavi pubbliche (riconoscibili dall'estensione .pub), invece, vengono trasmesse al client che chiede di collegarsi e sono quindi leggibili per tutti gli utenti.

Il client SSH cerca di stabilire una connessione. Il demone SSH in attesa e il client SSH richiedente scambiamo i dati di identificazione per confrontare la versione di protocollo e di software ed escludere la connessione ad una porta errata. Dato che è un processo figlio del demone SSH a replicare, sono possibili una serie di connessioni SSH contemporanee.

OpenSSH supporta ai fini della comunicazione tra server SSH e client SSH il protocollo SSH nella versione 1 e 2. Se eseguite una nuova installazione di SUSE Linux verrà installato automaticamente la versione 2 del protocollo. Se dopo un aggiornamento volete continuare ad utilizzare SSH 1, seguite le istruzioni riportate in /usr/share/doc/packages/openssh/README.SuSE. Lì viene anche descritto come convertire in pochi passaggi un ambiente SSH 1 in un ambiente SSH 2.

Con il protocollo SSH versione 1, il server inivia la sua chiave host (ingl. host key) pubblica ed una chiave server (ingl. server key) che viene rigenerata dal demone di SSH ogni ora. Per mezzo delle due chiavi, il client SSH crea una chiave di sessione (ingl.session key) cifrata e la invia al server SSH. Il client ssh comunica inoltre al server quale metodo di cifratura utilizzare (ingl. cipher).

Il protocollo SSH versione 2 non prevede l'uso della chiave server, ricorre invece all'algoritmo secondo Diffie-Hellman per lo scambio delle chiavi.

Le chiavi host e server private, assolutamente necessarie per decifrare la chiave di sessione, non possono venire dedotte dalle chiavi pubbliche. In questo modo, solo il demone SSH contattato è in grado di decifrare la chiave di sessione grazie alla sua chiave privata (si veda man /usr/share/doc/packages/openssh/RFC.nroff). Questa fase iniziale del collegamento si lascia seguire da vicino ricorrendo all'opzione -v preposta alla ricerca di errori (debugging).

Di default viene utilizzato il protocollo SSH versione 2; con il parametro -1 potete tuttavia forzare l'uso della versione 1 del protocollo SSH. Il client archivia tutte le chiavi host pubbliche in ~/.ssh/known_hosts dopo la prima presa di contatto con l'host remoto. In tal modo è possibile respingere tentativi di attacchi del tipo man-in-the-middle con server SSH che utilizzano nomi ed indirizzi IP contraffatti. Questi tentativi verranno smascherati a causa di una chiave host non inclusa in ~/.ssh/known_hosts oppure vista l'impossibilità del server di decifrare la chiave di sessione dal momento che manca la controparte privata.

É consigliabile archiviare su di un supporto esterno ed in un luogo sicuro le chiavi private e pubbliche di /etc/ssh/. In questo modo, accertate eventuali manipolazione delle chiavi, potrete ripristinare le vecchie chiavi reinstallandole. Così risparmiate agli utenti l'avvertimenti pochi rassicuranti. Una volta accertato che, nonostante l'avviso, si tratta del server SSH giusto, eliminate la registrazione relativa a questo sistema da ~/.ssh/known_hosts.

Ora segue l'autenticazione vera e propria, che, nella variante più semplice prevede l'immissione di una password, così come negli esempi sopra citati. Con SSH si è voluto introdurre un software sicuro e al contempo facile da usare, con un metodo di autenticazione semplice come quello dei programmi che intende sostituire (rsh e rlogin). Con SSH vi è un ulteriore paio di chiavi generato dall'utente. A questo scopo il pacchetto SSH contiene il tool ssh-keygen. Immettendo ssh-keygen  -t rsa o ssh-keygen  -t dsa viene generato il paio di chiavi e vi verrà chiesto il nome del file nel quale archiviare le chiavi:

Confermate il valore di default e indicate la passphrase. Anche se il software vi consiglia di non indicare una passphrase, consigliamo di inserire comunque una stringa lunga da 10 a 30 caratteri. Non utilizzate parole o frasi semplici o brevi. Il programma vi chiederà di inserire la frase una seconda volta. Infine, vi mostrerà dove le chiavi pubbliche e private siano state archiviate, ovvero, nel nostro esempio, nei file id_rsa e id_rsa.pub.

Usate ssh-keygen -p -t rsa o rispettivamente ssh-keygen -p -t dsa per modificare la vostra passphrase. Copiate la parte pubblica della chiave (nel nostro esempio id_rsa.pub) sul sistema remoto, dove la salvate sotto ~/.ssh/authorized_keys. Ogni volta che vi connetterete, vi verrà chiesta la passphrase. In caso contrario, verificate la locazione ed il contenuto dei file summenzionati.

A lungo andare, questo procedimento è più laborioso dell'inserimento di una password. Quindi, il pacchetto SSH fornisce un altro tool: ssh-agent che tiene pronte le chiavi private per la durata di una X session; a questo scopo, l'intera X session viene avviata come processo figlio di ssh-agent. Potete realizzare ciò semplicemente impostando la variabile usessh all'inizio del file .xsession su yes, ed eseguire il login tramite un display manager (p.es.KDM o XDM). Alternativamente potete usare ssh-agent  startx.

Ora potete utilizzare ssh o scp. Se avete distribuito la vostra chiave pubblica come descritto sopra, non dovreste più ricevere la richiesta d'inserimento della password. Quando uscite dal vostro sistema, fate attenzione a terminare la vostra X session o a non permettere a nessuno di accedervi ad es. impostando una applicazione per bloccare lo schermo protetta da una password, p.es. xlock.

Tutte le principali modifiche con l'introduzione della seconda versione del protocollo SSH, sono riportate nel file /usr/share/doc/packages/openssh/README.SuSE.

Oltre ai miglioramenti in termini di sicurezza finora descritti, ssh facilita anche l'uso di applicazioni X remote. Se inserite ssh con l'opzione -X, sul sistema remoto viene automaticamente impostata la variabile DISPLAY e tutte le emissioni di X vengono reindirizzate, tramite il collegamento ssh, sul sistema di partenza. Questa comoda funzione previene contemporaneamente la possibilità d'intercettazione esistente finora nelle applicazioni X lanciate su un sistema remoto e con visualizzazione sul sistema locale.

Tramite l'opzione -A, viene il meccanismo di autenticazione di ssh-agent viene passato al prossimo sistema. In tal modo è possibile passare da un sistema all'altro senza dover inserire una password; questo però solo se prima sono state distribuite e archiviate correttamente le chiavi pubbliche sui sistema meta interessati.

Per precauzione, entrambi i meccanismi non sono attivi di default. Per attivarli permanentemente, andate nel file di configurazione del sistema, /etc/ssh/ssh_config o in quello dell'utente ~/.ssh/config.

Potete utilizzare ssh anche per reindirizzare un collegamento TCP/IP. Come esempio riportiamo l'inoltro della porta SMTP e POP3:

ssh -L 25:sun:25 earth

Con questo comando ogni collegamento indirizzato a earth port 25 (SMTP) viene reindirizzato alla porta SMTP di sun tramite un canale cifrato. Ciò è utile specialmente per gli utenti di server SMTP senza supporto per le funzionalità SMTP-AUTH o POP-before-SMTP. Le e-mail possono in tal maniera venir inviate da una postazione qualsiasi con un collegamento di rete per essere consegnate al proprio server di posta (ingl.«home» mail server). In modo analogo con il seguente comando le richieste POP3 (porta 110) di earth possono essere inoltrate alla porta POP3 di sun.

  ssh -L 110:sun:110 earth

Questi comandi vanno eseguiti come utente root, poiché vengono indirizzate porte locali privilegiate. Con un collegamento SSH esistente, la posta viene spedita e ritirata da utente normale. L'host SMTP e l'host POP3 deve venire configurato su localhost. Per ulteriori informazioni consultate le pagine di manuale dei singoli programmi e dei file sotto /usr/share/doc/packages/openssh.