Con 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.

Con il programma ssh, potete stabilire un collegamento ad un sistema remoto e lavorarci interattivamente. Questo programma sostituisce quindi sia telnet che rlogin. A causa della sua affinità con rlogin, il nome simbolico slogin punta anche su ssh. Per fare un esempio: con il comando ssh , si può accedere al sistema , che vi chiederà la vostra password.

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

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 e viene creata una directory con il nome tmp. L'output del programma avviene sul terminale locale del sistema .

ssh  "uptime; mkdir tmp"
tux@password_di_:
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 .

Per mezzo di scp potete copiare dei file su un host remoto. scp è il sostituto cifrato e sicuro di rcp. Per esempio, scp lamialettera.tex : copia il file lamialettera.tex dal sistema sul sistema . Se i nomi di utente su e sono diversi, usate con scp la sintassi nomeutente@nomehost. Non esiste un'opzione -l. 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 incrementa 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 offre, oltre alla copia di singoli file, anche un procedimento ricorsivo per la trasmissione di complete directory: scp  -r src/ :backup/ copia l'intero contenuto della directory src/ sottodirectory inclusi su e lì nella sottodirectory backup/ che viene generata automaticamente se ancora non dovesse esistere.

Per mezzo dell'opzione -p, scp conserva 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 carico di sistema più elevato.

Alternativamente, si può usare sftp per una trasmissione dei dati più sicura. Una sessione sftp offre molti dei comandi noti di ftp. Rispetto a scp si rivela vantaggioso soprattutto quando si trasmettono dati di cui non si conoscono i nomi di file.

Affinché possano venire utilizzati ssh e scp, i programmi client del pacchetto SSH, devono girare in background il demone di SSH in ascolto sulla porta 22 TCP/IP.

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 il procedimento come procedimento basato su chiave pubblica. Per garantire una comunicazione sicura tramite SSH, solo l'amministratore deve poter visualizzare dei file delle chiavi private. A questo scopo, i permessi dei file vengono impostati (preimpostati) in modo molto restrittivo. Le chiavi private sono necessarie solo localmente al demone SSH e non possono venir trasmesse a nessun altro. Le chiavi pubbliche (riconoscibili dall'estensione .pub), invece, possono essere trasmesse al proprio interlocutore e sono di conseguenza 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 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 host key pubblica ed una server key che viene generata dal demone ad intervalli regolari di una ora. Per mezzo delle due chiavi cifrate, il client SSH crea una chiave di sessione, (ingl.session key) da lui liberamente scelta e la invia al server SSH: inoltre comunica al server il metodo di cifratura utilizzato (ingl. cipher) usato. Il protocollo SSH versione 2 non prevede l'uso della server key. Al suo posto viene utilizzato l'algoritmo secondo Diffie-Hellman per lo scambio delle chiavi.

Le chiavi private host e server, 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 (cfr. man /usr/share/doc/packages/openssh/RFC.nroff). Questa fase iniziale del collegamento, può essere ricostruita facilmente tramite l'opzione -v, per la ricerca degli errori, del programma client di SSH. Di default viene utilizzato il protocollo SSH versione 2; con il parametro -1 potete forzare l'uso del protocollo SSH versione 1. Se il client archivia tutte le host key pubbliche in ~/.ssh/known_hosts in tal modo è possibile respingere attacchi del tipo man-in-the-middle. I server SSH che cercano di simulare il nome ed indirizzo IP di un altro, vengono smascherati con un chiaro avviso a causa di una chiave host divergente da ~/.ssh/known_hosts oppure per non sono in grado di decifrare la chiave convenuta della sessione, dal momento che non dispongono della 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'avvertimento poco rassicurante. 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 così 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 la chiave:

Enter file in which to save the key (/home//.ssh/id_rsa):

Confermate il valore di default e stabilite una 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 memorizzate, ovvero, nel nostro esempio, nei file id_rsa e id_rsa.pub.

Enter same passphrase again: 
Your identification has been saved in /home/bspuser/.ssh/id_rsa 
Your public key has been saved in /home/bspuser/.ssh/id_rsa.pub. 
The key fingerprint is: 
79:c1:79:b2:e1:c8:20:c1:89:0f:99:94:a8:4e:da:e8 @

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 come ~/.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, X viene avviato per intero come processo figlio di ssh-agents. Potete realizzare ciò semplicemente impostando la variabile usessh - che si trova 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, 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. tramite un blocco dello schermo protetto da 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 visualizzate sul sistema locale.

Tramite l'opzione -A, viene adottato il meccanismo di autenticazione ssh-agent dal prossimo sistema. In tal modo è così 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 qualsiasi collegamento TCP/IP. Come esempio riportiamo l'inoltro della porta SMTP e POP3:

ssh -L 25::25 

Ad ogni collegamento indirizzato alla porta 25, SMTP viene reindirizzato alla porta SMTP di 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 mail possono in tal maniera venir inviate da una postazione qualsiasi con un collegamento di rete per essere consegnate dal server di posta proprio. In modo analogo con il seguente comando le richieste POP3 (porta 110) indirizzate al possono venir reindirizzate sulla porta POP3 di

  ssh -L 110::110 
  

Questi comandi vanno eseguiti come utente root, poiché vengono indirizzate porte locali privileggiate. Con un collegamento SSH esistente, la posta viene spedita e ritirata come 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.