• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

OpenSSH: client bug CVE-2016-0777

Athaba

Libellenliebhaber
#3
Und noch besser wäre es wohl den Code einfach zu updaten, wenn möglich. Patch gab's ja gleich :)

Eine kleine Info noch für alle die sich jetzt sorgen machen, dass ihre Keys kompromittiert sind. Es kann zwar nicht schaden immer mal wieder einen Neuen zu machen, aber wenn man keine bei der Verwendung von OpenSSH kein "[connection suspended, press return to resume]" bekommen hat, dann ist wahrscheinlich alles in Ordnung.
 

foxit

Well-Known Member
#4
Zum Glück habe ich ja erst vorgestern alle Server auf den aktuellen Stand gebracht :grumble:

Danke für die Info.

@double-p
Besser so?
Code:
echo 'UseRoaming no' | tee -a /etc/ssh/ssh_config
:)
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#5
Eine kleine Info noch für alle die sich jetzt sorgen machen, dass ihre Keys kompromittiert sind. Es kann zwar nicht schaden immer mal wieder einen Neuen zu machen, aber wenn man keine bei der Verwendung von OpenSSH kein "[connection suspended, press return to resume]" bekommen hat, dann ist wahrscheinlich alles in Ordnung.
Ich sage ja: SSH CAs und die Keys möglichst oft tauschen. Gern wöchentlich.
 

s-tlk

Lion King Fan
#6
Sonderlich praktikabel ist das aber nicht. Zumindest nicht mit dem Rechnerzoo hier.
In den wenigsten Faellen wird die Luecke aber kritisch sein, da man sich ja ueberwiegend auf Server des eigenen Vertrauens anmeldet.
 
#8
Wöchentlich?! Liebe Güte alleine im Privatumfeld wäre ich da ja mehr mit Schlüsselverteilen/-ersetzen als mit irgendwas anderem beschäftigt.
SSH-CA ist eigentlich eine sehr gute Lösung für Unternehmen mit mehr als zwei SSH Zugriffen im Monat. Für Privat etwas overhead.
Das schöne an der CA ist, das die SSH-Certs ein Ablaufdatum haben, und man keine PublicKeys mehr auf die Server kot.en muss.
Das erhöht auch die Sicherheit der Zugriffsverwaltung, weil PrivateKeys der (L)User auch mal verloren gehen, geshared werden oder auf Github/Local Repos landen :-)
 

-Nuke-

Well-Known Member
#9
Naja, im Privatumfeld ist das auch alles nicht sonderlich kritisch. Wenn man sich über einen Schlüssel einloggt auf einem Non-Standard Port, dann verliert das Botnet-Skript eh schon schnell das Interesse bzw. findet einen gar nicht.

Für Brute-Force Angriffe reicht nach meiner Erfahrung schon eine Verlegung des SSH Ports.
 

Athaba

Libellenliebhaber
#10
Naja, dann am Besten kritische Dinge ein wenig automatisieren. Ist einfacher als man denkt. Nur keinen Lockout produzieren (man kann ja entsprechend testen, ob alles passt bevor den nächsten Schritt tut. Einmal in ein Skript gepackt ist das ein Command, auch privat. :)