Schlüsselaustausch

In der Debian-Sicherheitsankündigung 1571, deckte das Debian-Sicherheitsteam eine Schwäche im Zufallszahlengenerator auf, der von OpenSSL in Debian und seinen Derivaten verwendet wird. Als ein Ergebnis dieser Schwäche sind bestimmte Verschlüsselungsschlüssel sehr viel einfacher, als sie sein sollten, so dass ein Angreifer den Schlüssel mittels einer Brute-Force-Attacke mit minimalem Wissen über das System erraten kann. Dies betrifft insbesondere die Verwendung von Verschlüsselungsschlüsseln in OpenSSH, OpenVPN und SSL-Zertifikaten.

Diese Seite dokumentiert, wie die Schlüssel für Pakete, deren Schlüssel durch die OpenSSL-Verwundbarkeit betroffen sind, ausgetauscht werden können.

Andere Software verwendet kryptographische Schlüssel, ist aber nicht verwundbar, da OpenSSL nicht verwendet wird, um deren Schlüssel zu erzeugen oder zu übermitteln.

Für Anleitungen zum Schlüsselaustausch für andere Software wird auf die von Benutzern zusammengetragenen Informationen unter https://wiki.debian.org/SSLkeys verwiesen.

OpenSSH

Ein aktualisiertes Paket wurde mit DSA-1576 herausgegeben, das die Schlüsseltransformation vereinfacht.

1. Installieren Sie die Sicherheitsaktualisierungen aus DSA-1576

Sobald die Aktualisierung eingespielt wurde, werden schwache Benutzerschlüssel, wenn möglich, automatisch zurückgewiesen (diese können aber nicht in allen Fällen erkannt werden). Falls Sie solche Schlüssel für die Benutzerauthentifizierung verwenden, werden sie ab sofort nicht mehr funktionieren und müssen ersetzt werden (siehe Schritt 3).

OpenSSH-Rechner-Schlüssel können automatisch neu erzeugt werden, wenn die OpenSSH-Sicherheitsaktualisierung eingespielt wurde. Die Aktualisierung wird nach Bestätigung fragen, bevor dieser Schritt durchgeführt wird.

2. Aktualisierung der OpenSSH-Dateien known_hosts

Die Neuerzeugung der Rechnerschlüssel wird eine Warnung ausgeben, wenn auf das System mit SSH zugegriffen wird, bis der Rechnerschlüssel in der Datei known_hosts auf dem Klient aktualisiert wurde. Die Warnung wird wie folgt aussehen:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Auf Deutsch lautet diese Meldung in etwa wie folgt: 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: IDENTIFIZIERUNG DES ENTFERNTES RECHNERS HAT SICH GEÄNDERT @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ES IST MÖGLICH, DASS JEMAND ETWAS BÖSES TUT!
Jemand könnte Sie zurzeit abhören (man-in-the-middle-(Mann in der Mitte)-Angriff)!
Es ist auch möglich, dass der RSA-Rechnerschlüssel vor kurzem geändert wurde.

In diesem Fall wurde der Rechnerschlüssel einfach geändert und Sie sollten die entsprechende Datei known_hosts, wie in der Meldung beschrieben, aktualisieren. Es wird empfohlen, dass Sie einen vertrauenswürdigen Kanal zum Austausch des Server-Schlüssels verwenden. Er befindet sich in der Datei /etc/ssh/ssh_host_rsa_key.pub auf dem Server; sein Fingerabdruck kann mit dem folgenden Kommando gedruckt werden:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Zusätzlich zu benutzerspezifischen known_hosts-Dateien, kann eine systemweite Datei /etc/ssh/ssh_known_hosts existieren. Diese Datei wird sowohl vom ssh-Klient als auch von sshd für die hosts.equiv-Funktionalität verwendet. Diese Datei muss auch aktualisiert werden.

3. Überprüfen aller OpenSSH-Benutzerschlüssel

Der sicherste Weg ist es, alle OpenSSH-Benutzerschlüssel neu zu erzeugen, es sei denn, es kann mit ausreichender Bestimmtheit sichergestellt werden, dass der Schlüssel auf einem nicht betroffenen System erstellt wurde.

Um zu testen, ob Ihr Schlüssel betroffen ist, können Sie ssh-vulnkey starten, was in der Sicherheitsaktualisierung enthalten ist. Standardmäßig wird ssh-vulnkey den Standardort für Benutzerschlüssel (~/.ssh/id_rsa, ~/.ssh/id_dsa und ~/.ssh/identity), Ihre Datei authorized_keys (~/.ssh/authorized_keys und ~/.ssh/authorized_keys2) und die Rechnerschlüssel des Systems (/etc/ssh/ssh_host_dsa_key und /etc/ssh/ssh_host_rsa_key) überprüfen.

Sie können alle Ihre eigenen Schlüssel wie folgt testen, unter der Voraussetzung, dass sie sich an den Standardorten (~/.ssh/id_rsa, ~/.ssh/id_dsa oder ~/.ssh/identity) befinden:

ssh-vulnkey

Um alle Schlüssel auf Ihrem System zu überprüfen:

sudo ssh-vulnkey -a

Um einen Schlüssel an einem nicht standardmäßigem Ort zu testen:

ssh-vulnkey /Pfad/zum/Schlüssel

Falls ssh-vulnkey die Meldung Unknown (no blacklist information) ausgibt, hat es keine Informationen darüber, ob der Schlüssel betroffen ist. Im Zweifelsfall sollte der Schlüssel zerstört und ein neuer erzeugt werden.

4. Neuerzeugen beliebiger betroffener Benutzerschlüssel

Für die Benutzerauthentifizierung verwendete OpenSSH-Schlüssel müssen manuell neu erzeugt werden, inklusive derjenigen, die nach der Erzeugung auf ein anderes System übertragen wurden.

Neue Schlüssel können mit ssh-keygen erzeugt werden, z.B.:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host

5. Aktualisierung der authorized_keys-Dateien (falls nötig)

Sobald die Benutzerschlüssel neu erzeugt wurden, müssen die relevanten öffentlichen Schlüssel in authorized_keys-Dateien (und eventuell authorized_keys2-Dateien) auf entfernten Systemen übertragen werden. Stellen Sie sicher, dass die betroffenen Schlüssel gelöscht werden.

OpenSSL: Allgemeine PEM-Schlüsselerzeugungsinstruktionen

Dies ist nur eine Erinnerung für jene, die PEM-kodierte Zertifikate (neu)erzeugen. Ihre Site hat wahrscheinlich andere Richtlinien dafür, wie Schlüssel verwaltet werden, denen Sie folgen sollten. Zusätzlich müssen Sie die Zertifikate eventuell erneut durch eine weitere Zertifikatsautorität signieren lassen, anstatt ein selbst zertifiziertes Zertifikat, wie im Folgenden gezeigt, verwenden: 

cd /etc/ssl/private
openssl genrsa 1024 > mysite.pem
cd /etc/ssl/certs
openssl req -new -key ../private/mysite.pem -x509 -days 9999 -out mysite.pem

Bincimap

Das Paket bincimap erstellt mittels des Openssl-Programms automatisch selbst-signierte Zertifikate für den Bincimap-ssl-Dienst und legt diese in /etc/ssl/certs/imapd.pem ab. Für die Neuerzeugung führen Sie Folgendes aus: 

rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap

Boxbackup

Boxbackup ist nicht in Debian Stable vorhanden, nur in Testing/Lenny.

Die Originalautoren haben eine erste Auswirkungsanalyse des mit unzureichend zufälligem PRNG erstellten Schlüsselmaterials erstellt. Sie können die Details hier nachlesen.

Falls der PRNG in Ihrer OpenSSL unzureichend zufällig war, müssen Sie:

Cryptsetup

Cryptsetup verwendet selbst nicht Openssl für die Verschlüsselung (dies trifft sowohl auf LUKS- als auch Dm-crypt-Geräte zu).

Falls Cryptsetup konfiguriert wurde, SSL-verschlüsselte Schlüsseldateien zu verwenden (eine nicht-Standard-Konfiguration, die vom Benutzer explizit konfiguriert worden sein muss) und eine defekte Version von Openssl wurde zur Erstellung der Schlüsseldatei verwandt, dann kann die Schlüsseldatei schwächer als erwartet sein (da das Salz nicht wirklich zufällig ist).

Die Lösung besteht entweder darin, die Schlüsseldatei erneut zu verschlüsseln (falls Sie sich halbwegs sicher sein können, dass der verschlüsselte Schlüssel nicht dritten Parteien bekannt geworden ist) oder die betroffene(n) Partition(en) zu überschreiben und mit einem neuen Schlüssel neu zu installieren.

Anweisungen zur Neuverschlüsselung einer Schlüsseldatei:

Führen Sie das Folgende für jede SSL-verschlüsselte Schlüsseldatei durch, wobei Sie <ssl_encrypted_key_path> durch den Pfad zur eigentlichen Schlüsseldatei ersetzen: 

tmpkey=$(tempfile)
openssl enc -aes-256-cbc -d -salt -in <ssl_encrypted_key_path> -out "$tmpkey"
shred -uz <ssl_encrypted_key_path>
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out <ssl_encrypted_key_path>
shred -uz "$tmpkey"

Dropbear

Falls Sie über /etc/ssh/*host*-Schlüssel verfügen, entfernen Sie diese entweder oder folgen Sie zuerst den Openssh-Anweisungen bevor Sie die Schlüssel von Dropbear aktualisieren.

Dropbears Postinst konvertiert existierende Openssh-Schlüssel in das Dropbear-Format, falls es nicht die Host-Schlüssel von Dropbear finden kann. 

rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear

Beachten Sie, dass die von Dropbear selbst generierten Schlüssel nicht verwundbar sind (es verwendet libtomcrypt statt OpenSSL).

Ekg

Benutzer des Programms Ekg oder Ekg2 (letzteres ist nur in Experimental), die die SIM-Verschlüsselungsfunktionalität verwenden und ihr Schlüsselpaar mittels des Befehls /key [-g|--generate] erstellt haben (der libssl zur Erledigung verwendet), sollten ihren Schlüssel neu erstellen, nachdem Sie das Upgrade von libssl eingespielt und das Programm neu gestartet haben.

Die Originalautoren haben einen Hinweis auf ihre Website gestellt: http://ekg.chmurka.net/index.php

Falls Sie weitere Hilfe benötigen, fragen Sie bitte auf ekg-users@lists.ziew.org oder auf ekg2-users@lists.ziew.org (beide auf Englisch und Polnisch).

Ftpd-ssl

rm -f /etc/ftpd-ssl/ftpd.pem /etc/ssl/certs/ftpd.pem
dpkg-reconfigure ftpd-ssl

behandelt die Standard-Installation. Falls der Administrator darüber hinaus weitere SSL-Infrastruktur eingerichtet hat, müssen diese Schlüssel ebenfalls neu erstellt werden.

Gforge

Das Paket gforge-web-apache2 in Sid und Lenny richtet die Website mit einem Pseudo-Zertifikat ein, falls kein existierendes Zertifikat gefunden wird. Die Benutzer werden dann ermutigt, es mit einem echten zu ersetzen. Das besagte Pseudo-Zertifikat ist zudem ein reines Quacksalber-Produkt, daher sollte es bereits als schwach bekannt sein (selbst ohne den SSL-Fehler), aber einige Benutzer könnten es ohne weiteres Nachdenken akzeptieren.

MIT-Kerberos (krb5)

Kein Teil von MIT-Kerberos in Debian 4.0 (Etch) verwendet OpenSSL, und daher ist Kerberos in Debian 4.0 in keinster Weise betroffen.

In Lenny verwendet das separate Binärpaket krb5-pkinit OpenSSL. MIT-Kerberos selbst generiert keine langlebigen Schlüsselpaare, selbst wenn die PKINIT-Erweiterung verwandt wird, daher müssten alle verwundbaren langlebigen Schlüsselpaare außerhalb der MIT-Kerberos-Software selbst erstellt worden sein. Die PKINIT-Erweiterung referenziert nur existierende Schlüsselpaare und ist nicht für die Schlüsselverwaltung verantwortlich.

Langlebige Schlüsselpaare, die mit PKINIT verwandt werden, könnten betroffen sein, falls sie auf einem betroffenen Debian-System erzeugt wurden, aber diese Erstellung liegt außerhalb von MIT-Kerberos.

Allerdings wird die random key-Funktion von OpenSSL für den DH-Austausch verwandt, wenn die PKINIT-Authentifizierung verwandt wird. Dies bedeutet, dass ein Angreifer in der Lage sein könnte, mit roher Gewalt Zugriff auf die Antwort des KDC auf eine PKINIT-Authentifizierung zu erlangen und folgerichtig Zugriff auf alle Sitzungen, die mit diesem Dienst-Ticket von dieser Authentifizierung erstellt wurden, zu erlangen.

Alle KDCs, die die PKINIT-Erweiterung aus Lenny einsetzen, sollten sofort ein Upgrade des libssl0.9.8-Pakets bekommen. Anschließend sollte der Kerberos-KDC wie folgt neu gestartet werden: 

/etc/init.d/krb5-kdc restart

Jedes Kerberos ticket-granting ticket (TGT) und alle verschlüsselten Sitzungen, die aus einer PKINIT-Authentifizierung mittels eines Kerberos KDC mit einer betroffenen libssl erfolgten, sollten als suspekt betrachtet werden. Es ist möglich, dass Angreifer, die Pakete abfangen können, diese Schlüssel und Sitzungen kompromittieren könnten.

Nessus

Das Post-Installations-Skript des Nessus-Serverpakets (nessusd) erstellt SSL-Schlüssel für die sichere Kommunikation zwischen einem Nessus-Server und -Client. Dieser Kommunikationskanal sollte als kompromittiert betrachtet werden, da ein böswilliger Benutzer in der Lage wäre, die zwischen dem Server und dem Client ausgetauschten Informationen (die Informationen über die Verwundbarkeiten des entfernten Systems enthalten) abzufangen und möglicherweise Befehle als der angemeldete Benutzer an den Server senden könnte.

Falls der Administrator zusätzlich entweder den Nessus-CA-Schlüssel oder ein Benutzer-Zertifikat (mit nessus-mkcert-client) für die entfernte Authentifizierung auf einem Server erstellt hat, auf dem die von diesem Sicherheitsproblem betroffene OpenSSL-Version installiert war, dann sollten diese Schlüssel als kompromittiert angesehen werden. Beachten Sie, dass entfernte Benutzer mit Zugriff auf den Nessus-Server von diesem Server aus Angriffe gegen Server fahren können, die sie angreifen dürfen und, falls in der lokalen Konfiguration aktiviert (standardmäßig bei Debian auf nein) Erweiterungen hochladen können, die vom Nessus-Server mit Root-Rechten ausgeführt werden würden.

Die Konfigurationsskripte des Betreuers werden das OpenSSL-Zertifikat (wenn konfiguriert) neu erstellen, falls sie es nicht finden können. Sie müssen die Zertifikate entfernen und dann neue erstellen lassen, indem Sie Folgendes ausführen:

rm -f /var/lib/nessus/CA/cacert.pem
rm -f /var/lib/nessus/CA/servercert.pem
rm -f /var/lib/nessus/private/CA/cakey.pem
rm -f /var/lib/nessus/private/CA/serverkey.pem
dpkg-reconfigure nessusd

Sobald dies erledigt ist, müssen Sie die alten Benutzerschlüssel unter /var/lib/nessus/users/USERNAME/auth entfernen und sie mit nessus-mkcert-client neu erstellen. Sobald der CA-Schlüssel entfernt wurde, werden alte Schlüssel ungültig.

Nachdem der CA-Schlüssel neu erstellt wurde, werden Sie auch den neuen CA-Schlüssel an Ihre Benutzer verteilen müssen und Ihre Benutzer müssen das neue Zertifikat von dem Nessus-Server nach dem Verbindungsaufbau akzeptieren. Die Zertifikatseinstellungen für den alten Server sollten automatisch entfernt werden, aber Sie können sie auch manuell entfernen, indem Sie .nessusrc.cert (falls Sie den Nessus-Client verwenden) oder .openvasrc.cert (falls Sie den OpenVAS-Client verwenden) bearbeiten.

OpenSWAN / StrongSWAN

rm /etc/ipsec.d/private/`hostname`Key.pem /etc/ipsec.d/certs/`hostname`Cert.pem
dpkg-reconfigure (open|strong)swan
/etc/init.d/ipsec restart

Vorsicht: Neustarten des Dienstes ipsec beendet alle aktuell offenen IPSec-Verbindungen. Diese müssen eventuell vom anderen Ende neu gestartet werden.

OpenVPN

Sichern Sie Ihre geheimen Dateien. Während Schlüsselnamen beliebig sein können, können sie mittels des Befehls 

grep secret /etc/openvpn/*.conf

erkannt werden.

Erstellen Sie sie erneut mittels 

openvpn --genkey --secret GEHEIMER_DATEINAME

Kopieren Sie dann den gemeinsamen geheimen Schlüssel auf den entfernten Rechner und starten Sie das VPN auf jedem Rechner mittels 

/etc/init.d/openvpn force-reload

neu.

Proftpd

Das Debian-Paket enthält keine Schlüsselerzeugung, daher sollten die folgenden Schritte nur notwendig sein, falls SSL-Schlüssel extern erstellt wurden.

Ein zukünftiger Upload von Proftpd nach Unstable wird eine tls.conf-Vorlage mit dem Kommentar unten enthalten.

Beachten Sie, dass die Erstellung selbst-signierter Zertifikate sich etwas vom allgemeinen Abschnitt von Openssl unterscheidet, um die Verwendung eines expliziten Passworts beim Starten des Daemons zu vermeiden.

Sie können das selbst-signierte Zertifikat mit einem Befehl der folgenden Art erstellen: 

 openssl req -x509 -newkey rsa:1024 -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt -nodes -days 365

Beide Dateien dürfen nur von Root lesbar sein. Die Pfade der Dateien können mit den folgenden Konfigurationsdirektiven überprüft/konfiguriert werden: 

TLSRSACertificateFile                   /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile                /etc/ssl/private/proftpd.key
TLSCACertificateFile                    /etc/ssl/certs/CA.pem
TLSOptions                              NoCertRequest

Puppet

Es gibt zwei Methoden, Puppet-Zertifikate zu handhaben. Die eine ist via capistrano, die zweite ist manuell.

Die Neuerstellung der SSL-Zertifikate von Puppet mittels capistrano ist hier beschrieben: http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL

Die manuellen Schritte sind wie folgt:

  1. Sie müssen die CA-Information löschen und neu generieren: 
    /etc/init.d/puppetmaster stop
rm -rf $vardir/ssl/*
/etc/init.d/puppetmaster start

    Falls Sie allerdings Mongrel betreiben statt Puppetmaster aus dem Init-Skript zu starten, müssen Sie erst am Web auf Anfragen wartende Oberflächen (Apache, Nginx, usw.) stoppen und dann das Folgende durchführen: 

    puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'

    Der obige Befehl ist notwendig, da aus irgend einem Grund Puppetmaster seine CA nicht neu erstellen wird, falls es unter Mongrel läuft.

  2. Löschen Sie alle Client-Zertifikate 
    /etc/init.d/puppet stop
rm $vardir/ssl/*
  3. Lassen Sie jeden Client ein neues Zertifikat erstellen 
    puppetd --onetime --debug --ignorecache --no-daemonize
  4. Sobald alle Anfragen eingetroffen sind, können Sie sie alle auf einmal signieren: 
    puppetca --sign --all
  5. Starten Sie Ihre Puppet-Clients: 
    /etc/init.d/puppet start

Sie könnten auch temporär das automatische Signieren aktivieren, falls Ihnen das zusagt.

Sendmail

Sendmail (sowohl in Etch als auch in Lenny) erstellt optional bei der Installation vorgegebene OpenSSL-Zertifikate.

Die Schlüsselaustauschprozedur ist trivial: 

/usr/share/sendmail/update_tls new

Falls Sie die Vorlagen in /etc/mail/tls angepasst haben, werden die Werte dort erneut zum Erstellen der neuen Zertifikate verwandt.

ssl-cert

Das Quacksalber-Zertifikat /etc/ssl/certs/ssl-cert-snakeoil.pem kann mittels folgendem Befehl neu erstellt werden: 

make-ssl-cert generate-default-snakeoil --force-overwrite

Telnetd-ssl

rm -f /etc/telnetd-ssl/telnetd.pem /etc/ssl/certs/telnetd.pem
dpkg-reconfigure telnetd-ssl

behandelt die Standard-Installation. Falls der Administrator darüber hinaus weitere SSL-Infrastruktur eingerichtet hat, müssen diese Schlüssel ebenfalls neu erstellt werden.

Tinc

Entfernen Sie alle verdächtigen öffentlichen und privaten Schlüsseldateien:

  1. Entfernen Sie rsa_key.priv.
  2. Bearbeiten Sie alle Dateien im Verzeichnis hosts/ und entfernen Sie die öffentlichen Schlüsselblöcke.

Erstellen Sie ein neues (öffentlich/privates) Schlüsselpaar: 

tincd -n <netname> -K

Tauschen Sie die Host-Konfigurationsdatei mit den neuen öffentlichen Schlüsseln mit anderen Mitgliedern Ihres VPN. Vergessen Sie nicht, den Tinc-Daemon neu zu starten.

tor

Tor ist nicht in Stable, aber in Lenny betroffen.

Clients mit Version 0.1.2.x sind nicht betroffen. Tor-Knoten oder versteckte Diensteanbieter, die eine beliebige Version verwenden, ebenso wie 0.2.0.x, sind betroffen.

Bitte lesen Sie die Verwundbarkeitsankündigung auf der Tor-Ankündigungs-Mailingliste.

Eine Aktualisierung zu 0.1.2.19-3 (verfügbar in Testing, Unstable, backports.org und dem üblichen noreply.org-Depot) oder 0.2.0.26-rc-1 (verfügbar in Experimental und dem üblichen noreply.org-Depots) wird empfohlen. Falls Sie einen Relay laufen haben, werden diese Versionen neue Server-Schlüssel (/var/lib/tor/keys/secret_*) erzeugen.

Sollten Sie einen Tor-Knoten ohne die Paketinfrastruktur (Benutzer debian-tor, /var/lib/tor als DataDirectory usw.) verwenden, müssen Sie betroffene Schlüssel manuell entfernen. Schauen Sie in den oben aufgeführten Ankündigungs-Link.

Falls Sie ein versteckter Diensteanbieter sind und Ihren Schlüssel im entsprechenden Zeitfenster mit einer unzureichenden libssl erstellt haben, löschen Sie bitte Ihren privaten Schlüssel des versteckten Dienstes. Dies wird den Rechnernamen Ihres versteckten Dienstes ändern und könnte eine Neukonfiguration Ihrer Server erfordern.

Falls Sie Version 0.2.0.x verwenden, wird eine Aktualisierung dringend empfohlen – 3 der 6 v3-Autoritäts-Server haben kompromittierte Schlüssel. Alte 0.2.0.x Versionen werden in ein oder zwei Wochen nicht mehr länger funktionieren.

xrdp

Xrdp verwendet generierte Schlüssel. Die meisten Clients überprüfen diese Schlüssel standardmäßig nicht, daher ist der Austausch schmerzlos. Sie müssen nur Folgendes ausführen: 

rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart

Xrdp ist nicht in Stable.