Den som har den private nøkkelen, kan logge seg på den kontoen som er satt opp for det. Dette er grunnen til at tilgang til den private nøkkelen er beskyttet av en «adgangsfrase» («passphrase»). Noen som får en kopi av en privat nøkkelfil (for eksempel ~/.ssh/id_rsa), må fremdeles kjenne denne frasen for å kunne bruke den. Denne ekstra beskyttelse er imidlertid ikke uangripelig, og hvis du tror at denne filen har blitt kompromittert, er det best å deaktivere den nøkkelen på datamaskinene der den har blitt installert (ved å fjerne den fra authorized_keys filer), og erstatte den med en nylig generert nøkkel.

OpenSSL-biblioteket, som i utgangspunktet er tilgjengelig i Debian Etch, hadde et alvorlig problem i sin generator for tilfeldige tall (RNG). Faktisk hadde Debians vedlikeholder gjort en endring slik at programmer som bruker den, ikke lenger ville generere advarsler når den ble analysert av et testverktøy for minnet som valgrind. Dessverre, denne endringen betydde også at RNG-en bare anvender en entropi-kilde som korresponderer med prosessantallet (PID), der 32 000 mulige verdier ikke gir tilstrekkelig tilfeldighet.

Spesielt når OpenSSL ble brukt til å generere en nøkkel, produserte den alltid en nøkkel i løpet av et visst sett av hundretusener av nøkler (32 000 multiplisert med et lite antall nøkkellengder). Dette påvirket SSH-nøkler, SSL-nøkler og X.509-sertifikater som brukes av mange programmer, som OpenVPN. En inntrenger trengte bare å prøve alle nøklene for å få uautorisert tilgang. For å redusere virkningen av problemet ble SSH-bakgrunnsprosessen modifisert til å nekte problematiske nøkler som er oppført i openssh-blacklist- og openssh-blacklist-extra-pakkene. I tillegg tillater ssh-vulnkey-kommandoen identifisering av mulige kompromitterte nøkler i systemet.

En grundigere analyse av denne hendelsen bringer frem i lyset at det er et resultat av flere (små) problemer, både i OpenSSL-prosjektet og med Debian-pakkevedlikeholderen. Et mye brukt bibliotek som OpenSSL skal - uten endringer - ikke generere advarsler under testing av valgrind. Videre bør koden (spesielt de delene som er så følsomme som RNG) bli bedre kommentert for å forhindre slike feil. På Debians side, ønsket vedlikeholderen å validere modifikasjonene med OpenSSLs utviklere, men forklarte ganske enkelt endringene, uten å legge ut den korresponderende programfiksen til gjennomgang, og unnlot å nevne sin rolle i Debian. Endelig, vedlikeholdsvalgene var sub-optimale: Endringene i den opprinnelige koden ble ikke klart dokumentert; alle modifikasjoner ble effektivt lagret i et Subversjon-depot, men de endte opp med alt samlet i en enkelt programfiks under oppretting av kildepakken.

Det er vanskelig under slike forhold å finne de korrigerende tiltak for å hindre gjentakelse av slike hendelser. Denne leksen ga her den lærdommen at alle divergenser Debian introduserer i oppstrøms programvare, må begrunnes, dokumenteres, sendes til oppstrømsprosjektetet når det er mulig, og publiseres vidt. Det er ut fra dette perspektivet at det nye kildepakkeformatet («3.0 (quilt)») og webtjenesten for Debian-kilder ble utviklet.

Når en bruker kobler til via SSH og starter en X11-økt annensteds fra, vil en såkalt magisk kake opprettes og lagres i .Xauthority-fil i brukermappen til den som igangsatte tilkoblingen. Denne kaken brukes av xauth til å identitetsbekrefte brukeren i løpet av X-økten. Hvis brukeren later som om den er noen andre på systemet, for eksempel ved bruk av su eller sudo, blir kaken ikke kopiert automatisk til målbrukeren, og X-tjeneren vil nekte å starte grafiske programmer i målbrukerens kontekst. Du vil måtte kopiere den magiske kaken inn i målbrukerens hjemmemappe (før du eksporterer og reimporterer kaken via xauth) for å tillate en annen bruker å også starte grafiske programmer i løpet av X-økten.

Internettet, og de fleste lokalnett som er koblet til det, opererer i pakke-modus, og ikke i tilkoblet modus. Dette betyr at en pakke utstedt fra en datamaskin til en annen, kommer til å bli oppholdt på flere mellomliggende rutere for å finne veien til sin destinasjon. Du kan fortsatt simulere en tilkoblet operasjon der strømmen er innkapslet i normale IP-pakker. Disse pakkene følger sin vanlige rute, men strømmen blir rekonstruert uendret på bestemmelsesstedet. Vi kaller dette en «tunnel», tilsvarende en veitunnel der biler kjører direkte fra inngangen (inndata) til utgangen (utdata) uten å møte noen kryss, i motsetning til en bane på overflaten, som ville innebære kryss og skiftende retninger.

Du kan bruke denne muligheten til å legge kryptering til tunnelen: Strømmen som flommer igjennom er da ugjenkjennelig fra utsiden, men den blir levert dekryptert ved utgangen av tunnelen.