openssh: Update deaktiviert ssh-dss (DSA)

[The Ripper]

Hallo,
Ich habe heute das neue Update von openssh installiert und unglücklicherweise nicht die changelogs durchgesehen vorher: http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html
Tja, jetzt kann ich mich nicht mehr einloggen.
Die Frage ist jetzt was ich mache, wenn ich keinen lokalen Zugriff auf das Gerät habe. Ich vermute, dass hier nichts zu machen ist.

Darüber hinaus würde ich gerne wissen, wie ich das Problem am geschicktesten löse, sollte ich wieder Zugriff haben; ohne ssh-dss wieder zu aktiveren (-> RSA verwenden?).

Ich hoffe ihr könnt mir dabei helfen.

 

[Feststelltaste]

Was für ein Server ist es denn? Etwa eine VM in einer Cloud? Kannst du dich mit dem Tool des Anbieters anmelden?

 

[The Ripper]

Es ist ein eigener Server mit Arch Linux, der aber gerade ziemlich weit weg ist.

 

[Feststelltaste]

Hast du einen SSH Key verwendet?

 

[The Ripper]

Ehrlich gesagt bin ich mir nicht zu 100% bewusst, wie genau ein SSH-Key definiert ist.

Ich habe SSH eigentlich nie wirklich angefasst, sondern einfach nur mit Putty benutzt, mich mit dem Server verbunden, gegebenenfalls Fingerprint bestätigt und dann im Terminal Benutzername und Passwort eingegeben.

 

[The Ripper]

Push...
Also unter den ganzen Linuxbenutzern müssten sich doch wenigstens ein paar finden, die sich über ein essentielles Bestandteil der meisten Linuxsysteme halbwegs auskennen...

 

[M@C]

Also du hast openSSH geupdated, den Dienst neu gestartet und nun funktioniert dein DSS SSH Key nicht mehr?
Da sollte man nichts machen koennen ohne lokalen Zugriff. Ausser wenns dein Server ein Recoverysystem hat, dann kannst du dieses booten, dein Filesystem mounten und den Public Key eines neu generierten zB. RSA SSH Keys in authorized_keys ablegen.

Kannst aber gerne mal mit dem ssh verbose flag (frag mich jetzt nicht wie man das in Putty einstellt, benutze ich persoenlich nicht) schauen ob dein Key auch wirklich ein DSS Key ist. Muesste sowas

debug1: Offering RSA public key: keyfile
debug1: Server accepts key: pkalg ssh-rsa blen 279

irgendwo auftauchen.

Wer ein Archlinux benutzt (und sogar als Server!) der sollte wirklich die Arch Announce Mailingliste abonniert haben und lesen. Jetzt musst du das Lehrgeld wohl bezahlen.

 

[mensch183]

Der Ssh-Server kommt gar nicht hoch, weil er keinen RSA-Hostkey hat? Du bekommst also nicht mal einen TCP-Connect zum Server, richtig? Teste das nochmal, um sicher zu gehen ... telnet server:22 ... meldet sich da der Server oder nicht?

Ich glaube nicht so recht, dass der alte Server _NUR_ DSS unerstützt hat und deshalb gar kein RSA-Schlüsselpaar erzeugt hatte.

Versuchst du dich evtl. als Nutzer "root" via Passwort anzumelden? Dann wirds wohl eher an dieser Änderung scheitern:
* The default for the sshd_config(5) PermitRootLogin option has
changed from "yes" to "prohibit-password".
... falls ja ... melde dich als normaler Nutzer an, werde per su root und ändere ggf. deine Konfiguration.

Also unter den ganzen Linuxbenutzern müssten sich doch wenigstens ein paar finden, die sich über ein essentielles Bestandteil der meisten Linuxsysteme halbwegs auskennen...

Da deine Fehlerbeschreibung kaum über "geht nicht" hinausgeht, ist zielsichere Hilfe schwer. _DU_ musst lernen Probleme näher zu untersuchen. Eine Debug-Output des gescheiterten Verbindungsversuches wäre das mindeste.

 

[M@C]

Arch überschreibt bei einem Update aber eigentlich keine Configdateien.

 

[mensch183]

... was nichts hilft, wenn sich eine Voreinstellung ändert, die man nicht explizit in der Konfig gesetzt hatte.

Beim SSH-Update hiflt vor allem eins: Die alte Verbindung nicht trennen, solange der neue Server nicht nachweisbar funktioniert.

 

[M@C]

Stimmt, nicht bedacht.

Root über SSH solltest du, falls es wieder läuft auch verbieten.

 

[mensch183]

Root über SSH solltest du, falls es wieder läuft auch verbieten.

Märchen. Die neue Voreinstellung ist genau was man auch haben will bzw. haben wollen sollte.

 

[M@C]

Schön, das du gleich noch Argumente dafür bringst.

Ich lasse mich aber gern überzeugen, wieso es denn ein root Login sein muss.

Bei einem User mit sudo muss ein potenzieller Angreifer auch noch deinen Benutzernamen bruteforcen (zugegeben, schwaches Argument). Dazu kommt aber, dass bei den meisten Distributionen entweder ein sudo Setup empfohlen oder bereits standardmässig aktiv ist. Ich gehöre zu den Linuxbenutzern, die dies unterstützen und damit bin ich wohl nicht der einzige.

 

[Sug82]

Es ist fast wieder so aehnlich wie eine Glaubensfrage, die jeder fuer sich selbst entscheiden muss und keine muessen andere belehren oder ueberzeugen.

Ich finde die Option PermitRootLogin without-password oder prohibited-password ist gleichberechtigt und so sicher wie mit sudo.

Die meisten sudo Passwoerter auf den remote Systemen, die ich in meinem Umfeld gesehen habe, haben gleiches Passwort wie auf dem lokalen System, oder aus einem LDAP. Damit ist das Passwort an sich die Schwachstelle. Mit einem Key, muss man explizit den privaten Key aus meinem Rechner zunaechst besorgen.

Ich verwende selbst PermitRootLogin without-password, weil es auch leider Skripte gibt, die von remote so automatisiert laufen und nicht irgendwo wieder das Passwort anhand expect oder aehnliches im Klartext steht. Bevor ich irgendwo das Paswort im Klartext habe, verwende ich lieber einen SSH Key. Bei einer Serveranzahl von weniger als 3 Stueck, kann ich sudo noch dulden, wenn man aber viel mehr als 3 hat, ueberlegt man meistens schon anders.

 

[mensch183]

Schön, das du gleich noch Argumente dafür bringst.

A = dein gerade genutzer Account auf dem lokalen Rechner vor deiner Nase
B = Rootaccount auf einem Zielserver mit sshd
Aufgabe ist, von A aus B zu erreichen, um auf dem Server als root irgendwas zu erledigen.

Um von A nach B zu gelangen, hast du die Wahl zwischen dem direkten Weg A-->B und verschiedenen, denkbaren Umwegen der Form A-->Zwischenschritt(e)-->B. Jetzt summierst du für alle Varianten alle Möglicheiten der Kompromittierung und vergleichst die ermittelten Summen. Die kleinste Summe gewinnt. Welche ist das?

Denke insb. an die Möglichkeit, dass der unprivilegierte Zwischenaccount auf dem Zielrechner, den du so gern als Umweg zum sudo'n nutzen möchtest, schon übernommen sein könnte, was beim direkten A-->B vollkommen egal ist. Dabei gibts 2 Untervarianten: Useraccount gefallen + Angreifer kennt User-PW (damit ist dank üblicher sudo-Konfig sowieso alles vorbei) und Useraccount gefallen + Angreifer kennt User-PW nicht. Im zweiten Fall ist _noch_ nicht alles vorbei, aber du wirst dem Angreifer wenige Sekunden später das User-PW schenken, indem du es an ein Programm verfütterst, was du für sudo hältst, was aber nur ein lokal nachinstallierter Fake ist, der dem Angreifer das User-PW liefert, womit wir sofort bei der ersten Untervariante sind, also dem Totalverlust des Servers.

Der Umweg über den unprilegierten Zwischenaccount vergrößert schlicht die Angriffsfläche. Damit kann nichts besser werden. Jeder zusätzliche Umweg macht es schwerer, einen sicheren Kanal von A nach B aufzubauen. Du schießt dir damit selbst ins Knie und bekommst was dafür? Dass dein Server ggf. gefallen ist, ohne dass jemand dazu das Root-PW herausbekommen musste. Gratulation dazu!

Also lieber direkt nach root@server via ssh verbinden und via public key authentifizieren. Via Passwort statt key _wäre_ nicht schlechter, _wenn_ man ein dem Key entsprechend komplexes Passwort wählen und nirgends wiederverwenden würde, was in der Praxis ziemlich schwer ist. Deshalb ist die neue Openssh-Voreinstellung 'PermitRootLogin=without-password' in der Regel genau das richtige.

Nichts gegen sudo. Sudo ist sinnvoll. Sudo ist genau dann sinnvoll, wenn man auf dem unprivilegierten Account, von dem aus man es nutzt, sowieso schon drauf hockt, z.B. weil man lokal damit am Rechner arbeitet. Aber sudo ist nicht sinnvoll, um darüber remote via ssh von einem unprivilegierten Zwischenaccount aus Root-Arbeit zu erledigen.


... aber wir kommen vom Thema ab. Was ich in #8 schrieb, sollte "The Ripper" mal testen, also ob der Ssh-Server vielleicht doch läuft.

 

[M@C]

Die Kostenminimierung ist etwas einfach gestrickt, nach dieser Hypothese minimiert 300 km/h auch die Fahrzeitsumme, erhoeht aber schlichtweg das Unfallrisiko. Ich verstehe das auch ohne ein Beispiel, dass fuer einen Grundschueler geschrieben ist, danke.

Aber ich verstehe deine Argumente und gebe dir Recht.
Es haengt zwar ein bisschen davon ab wie einfach es ist, dem User ein gefaktes sudo vorzulegen, mit einem simplen Alias sollte das aber doch gehen...
Habe ich so gar noch nicht durchgedacht, Danke fuer den Input, speziell fuer die Darlegung des Fall 2.

Ein nicht root User hilft vielleicht noch etwas gegen die zahllosen Bruteforce Logins aus China und Russland, wobei auch hier bei einem langen Passwort oder PublicKey Crypto eigentlich keine hoehere Gefahr zustande kommt.

 

[The Ripper]

Danke für eure Antworten!

* The default for the sshd_config(5) PermitRootLogin option has
changed from "yes" to "prohibit-password".
... falls ja ... melde dich als normaler Nutzer an, werde per su root und ändere ggf. deine Konfiguration.

Da ich über Telnet connecten kann, könnte es durchaus sein, dass es eher daran liegt. Sehr warscheinlich sogar, da ich mich immer über root verbinde und mir atm kein andere Benutzer einfällt, über den ich mich verbinden könnte.
Hat Google mich anscheinend eher auf den falschen Trip gebracht...

Da deine Fehlerbeschreibung kaum über "geht nicht" hinausgeht, ist zielsichere Hilfe schwer. _DU_ musst lernen Probleme näher zu untersuchen. Eine Debug-Output des gescheiterten Verbindungsversuches wäre das mindeste.

Event Log: Sent password
Incoming packet #0x5, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
00000000 00 00 00 12 70 75 62 6c 69 63 6b 65 79 2c 70 61 ....publickey,pa
00000010 73 73 77 6f 72 64 00 ssword.
Event Log: Password authentication failed

Das hat mir leider nicht sonderlich weitergeholfen und so viele Anhaltspunkte hatte ich leider auch nicht. Zugegeben im Nachhinein hätte ich auch drauf kommen können, aber hab mich einfach zu früh festgenagelt.

Wer ein Archlinux benutzt (und sogar als Server!) der sollte wirklich die Arch Announce Mailingliste abonniert haben und lesen. Jetzt musst du das Lehrgeld wohl bezahlen.

Danke für den Hinweis. Ich habe mich gleich einmal eingetragen.
Alles halb so schlimm, ist nur für Privatgebrauch

PS: Eigentlich könnte ich mir doch noch eine Alternative zu SSH einrichten um vorzubeugen, dass mir ähnliches nochmal passiert. Klar, werde ich jetzt mehr aufpassen, aber man weiß ja nie.

 

[The Ripper]

OK, es war die Änderung an PermitRootLogin, danke für alle Antworten.
Problem solved.