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.

Quando ci si connette tramite SSH e si avvia una sessione X11 remota, viene creato un cosiddetto cookie magico che viene salvato nel file .Xauthority della directory home dell'utente che ha avviato la connessione. Questo cookie è usato da xauth per autenticare l'utente durante la sessione X. Se si impersona un altro utente del sistema, ad esempio usando su o sudo, allora il cookie non è copiato automaticamente sull'utente impersonato e il server X si rifiuterà di avviare applicazioni grafiche nel contesto di quest'ultimo utente. Si deve copiare il cookie magico nella directory home di questo utente (tramite l'esportazione e la reimportazione del cookie con xauth) per permettergli di eseguire programmi grafici durante la sessione X.

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.