Chi ha la chiave privata può effettuare il login sull'account così configurato. Per questo motivo l'accesso alla chiave privata viene protetto da una «passphrase». Chi viene in possesso di una copia di una chiave privata (ad esempio, ~/.ssh/id_rsa) deve comunque sapere questa frase per essere in grado di utilizzarla. Questa protezione aggiuntiva non è, tuttavia, inespugnabile, e se si pensa che questo file è stato compromesso, è meglio disabilitare la chiave sui computer in cui è stata installata (rimuovendola dal file authorized_keys) e sostituendola con una nuova chiave generata.

La libreria OpenSSL, come inizialmente fornita in Debian Etch, aveva un problema serio nel suo generatore di numeri casuali (RNG). Infatti, il manutentore Debian ha fatto un cambiamento in modo che le applicazioni che la usavano non generassero più avvertimenti quando erano analizzati con strumenti di test di memoria, come valgrind. Sfortunatamente, questo cambiamento comportava anche che la RNG impiegasse una sola fonte di entropia, corrispondente al numero di processo (PID) i cui possibili 32.000 valori non offrono abbastanza casualità.

Nello specifico, quando OpenSSL veniva impiegato per generare una chiave, produceva sempre una chiave all'interno di un insieme noto di centinaia di migliaia di chiavi (32.000 moltiplicato per un piccolo numero di lunghezze di chiave). Questo riguardava le chiavi SSH, le chiavi SSL ed i certificati X.509 utilizzati da numerose applicazioni, come ad esempio OpenVPN. Un cracker doveva quindi solo provare tutte le chiavi per ottenere un accesso non autorizzato. Per ridurre l'impatto del problema, il demone SSH è stato modificato in modo da rifiutare le chiavi problematiche che sono elencate nei pacchetti openssh-blacklist e openssh-blacklist-extra. Inoltre, il comando ssh-vulnkey consente l'identificazione delle chiavi eventualmente compromesse nel sistema.

Un'analisi più approfondita di questo incidente mette in luce che è il risultato di molteplici (piccoli) problemi, sia all'interno del progetto OpenSSL, che con il responsabile del paccheto Debian. Una libreria ampiamente utilizzata come OpenSSL non dovrebbe — senza modifiche — generare avvisi quando viene testata da valgrind. Inoltre, il codice (in particolare quelle parti tanto delicate come la RNG) dovrebbe essere commentate meglio per evitare questi errori. Da parte sua il reponsabile del pacchetto Debian, vuole confermare le sue modifiche dagli sviluppatori di OpenSSL, ma le ha semplicemente spiegate senza fornire loro la corrispondente patch da revisionare ed ha omesso di mesionare il suo ruolo all'interno di Debian. Infine, le scelte di manutenzioneerano sub-attimali: le modifiche fatte al codice originale non sono state chiaramente documentate; tutte le modifiche sono effettivamente memorizzate in un repository Subversion, ma sono finite tutte concentrate in una singola patch durante la creazione del pacchetto sorgente.

In queste condizioni è difficile trovare le misure correttive per evitare il ripetersi di questi incidenti. La lezione da trarre è che ogni divergenza che Debian introduce nel software originale deve essere giustificata, documentata, presentata nel progetto principale, quando possibile, e ampiamente pubblicizzata. È in base a questa prospettiva che sono stati sviluppati il nuovo formato dei pacchetti sorgente ("3.0 (quilt)") ed i servizi web dei sorgenti Debian.

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

Internet, e la maggior parte delle LAN che vi sono collegate, opera in modalità a pacchetto e non in modalità connessa, il che significa che un pacchetto emesso da un computer verso un altro verrà fermato in vari router intermedi per trovare la strada verso la destinazione. È ancora possibile simulare il funzionamento in collegamento in cui il flusso è racchiuso in pacchetti IP normali. Questi pacchetti seguono il loro percorso abituale, ma il flusso viene ricostruito invariato a destinazione. Questo viene chiamato «tunnel», analogo ad una galleria stradale in cui i veicoli viaggiano direttamente dall'ingresso (input) all'uscita (output) senza incontrare alcun incrocio, al contrario di un percorso sulla superficie che comporterebbe incroci e cambiamenti di direzione.

È possibile utilizzare questa opportunità per aggiungere la cifratura al tunnel: il flusso che scorre attraverso di esso è quindi irriconoscibile dall'esterno, ma viene riportato alla forma decifrata all'uscita del tunnel.