SSH Login erlauben - lokalen Login Verbieten

Genau, denn das Passwort des entsprechenden Benutzers ist somit komplett deaktiviert - auch ein Benutzerwechsel mittels su <USERNAME> in diesen Account ist fortan nicht mehr möglich.

Man kann das Passwort natürlich jederzeit reaktivieren mittels

-u, --unlock

Benutzerzugang entsperren

Was passiert bei den Befehlen?

Beim sperren wird in der /etc/shadow, in der die gehashten Passwörter zu den einzelnen Benutzern gespeichert sind, vor dem jeweiligen Passworthash ein Ausrufezeichen gesetzt. So ist das Passwort deaktiviert.

Beim Unlock wird das Ausrufezeichen einfach wieder entfernt und das alte Passwort ist wieder aktiviert.

Warum werden beim SSH-Login die Benutzerdaten im _klartext_ übermittelt? Grad das ist doch der SINN von SSH das dies eben nicht passiert...

Die Key-Anmeldung ist natürlich generell besser, aber auch nur dann wenn
a) nicht jeder User denselben Key verwendet
b) wirklich _alle_ User dieselben Rechte haben sollen (eigentlich wäre es da eher sinnvoll mit Benutzernamen zu arbeiten)

Wenn man dagegen nen Key-Anmeldung macht und den Private-Key fröhlich über alle Rechner verteilt bringt es wenig -> und wenn man wirklich Userkeys für nen generellen Account nimmt gibts halt ne Menge zusätzlicher Verwaltung... (inkl. Benutzern die nicht wissen wie der Key erstellt wird).

Beim Passwort-Login werden die Passwörter immer im Klartext an den Server übertragen! Anders geht es auch überhaupt nicht, da das eingegebene Passwort ja nur auf dem Server abgeglichen werden kann (denn es existiert nur dort).

Eben genau deswegen nutzt man ja auch den Login mittels RSA-Key, damit Man-in-the-Middle da keine Chance hat.

Ähm - nein? Die übertragung funktioniert bei SSH bereits verschlüsselt. Siehe (erster google-treffer): https://www.venafi.com/de/blog/how-secure-shell-ssh-keys-work

Und warum muss der Server ein Passwort _kennen_ damit es abgeglichen werden kann? Selbst bei was simplen wie MD5 brauchst du das schon nicht mehr. Solange auf beiden Seiten dieselbe Berechnung für ne "prüfsumme" verwendet wird kannst du auch einfach den übertragenen Wert nehmen, neu berechnen und die Prüfsumme vergleichen. Damit brauchst du das reale Passwort nicht zu speichern... DAS is nu wirklich keine neue Technik...

Und wenn man hier davon ausgeht das jemand wirklich die SSH-Verschlüsselung aufgebrochen hat -> was sollte den daran hindern deinen RSA-Key mitzuschreiben? Der muss ja genauso übertragen werden. Selbst wenn du den lokal mittels Passwort geschützt hast muss ja dein private key irgendwann eben durch die Leitung um gegenüber mit dem public key verglichen zu werden. Was sollte also bei einer - deiner Meinung nach - unverschlüsselten Leitung den Angreifer daran hindern den eben mitzuschneiden und zu speichern?

Also -> nein, auch bei Passwort-Login werden die Passwörter nicht einfach so durch die Leitung geblasen, genau DAFÜR hat SSH bereits die Verschlüsselung implementiert (genauer gesagt mehrere Verfahren).

Blödsinn. Der Session Key wird vor der Authentisierung ausgehandelt.

Das ist praktisch kaum von Bedeutung solange man keine PKI zur Validierung der Server-Schlüssel einsetzt. Niemand setzt den Webserver der internen Lohnbuchhaltung mit einem selbstsignierten Zertifikat auf und vertraut dann den Anwendern, die Ausnahmeregel im Browser nur ein einziges Mal zu akzeptieren. Bei SSH ist das der Standard.


Dann wäre der Hash nur ein Surrogat des Passworts. Client-seitiges Hashing ist extrem kompliziert und zahlt sich kaum aus, wird deshalb auch von SSH nicht gemacht.

Das Passwort wird im Klartext in einem verschlüsselten Tunnel an jeden Server übermittelt, den der Anwender anhand des Fingerprints zu kennen glaubt, und kann dadurch abgegriffen werden. Die asymmetische Authentifizierung ist unter den gleichen Bedingungen hingegen sicher (d.h. der Angreifer kann sich nicht neu authentifizieren).

Grüße
Richard

Durch einen verschlüsselten Tunnel, was dir bei Man-in-the-Middle überhaupt nichts bringt, wenn der verschlüsselte Tunnel zum Angreifer führt.
Zu dem Unfug hat @c.r.s. ja schon alles geschrieben, nimm ich halt die Prüfsumme um mich bei dem Server anzumelden, wo wäre da der Unterschied?

Nein eben nicht, der RSA-Key wird niemals übertragen!
Bei Anmeldung mit RSA-Key wird lediglich eine random-generierte Nachricht mit dem Public-Key verschlüsselt, anschließend vom Client mit dem Private-Key entschlüsselt und dann vom Server abgegelichen. Da was abzugreifen bringt nichts, weil beim nächsten Loginversuch wieder eine vollkommen neue Nachricht generiert wird.

In dem Kontext ist deine Aussage Blödsinn.

Ja, es werden zwar Session-Keys ausgehandelt - soweit richtig - nur birngen diese dir bei Man-in-the-Middle Angriff genau: 0,garnichts.

Der Angreifer erstellt hier 2 separate Sessions, eine zum Client und eine zum Server. Der Client handelt somit den Session Key mit dem Angreifer aus.

Man kann es drehen und wenden wie man will, bei Passwortauthentifizierung gelangt der Angreifer mit Man-in-the-Middle immer an die Zugangsdaten.

Ok - nehmen wir mal an das ist so... dann reden wir hier von einem Angriffsszenario was ja in einer Schule mehr als wahrscheinlich ist. Bei einem Server der neben dem Root noch genau EINEM anderen Account hat. Denn dafür MUSS man ja erstmal den Man in the middle machen -> was schon erfordert das ich einiges an Aufwand reinstecke.

Aber ganz ehrlich -> von mir aus baut eure Server auch immer mal direkt in die Berge rein - könnte ja sein das nen Atomschlag sonst das RZ zerlegt. Ich würde halt ab und an die Kirche mal einfach im Dorf lassen und überlegen was die Randbedingungen sind. Wenn es ein wirklich relevanter Rechner ist würde sich m.E. ein Login per "direkt SSH" eh verbieten, dann nur per VPN (aber ich weiss, ggf. hängt der Angreifer ja auch da schon drin...). Und wenns nach euch geht vermutlich auch nur MINDESTENS wenn man selbst im örtlichem Polizeirevier sitzt (könnte ja sonst sein das jemand ganz klassisch die Knarre an den Kopf hält -> da hilft auch nen SSH-Key dann nich wirklich).

Und ja - natürlich könnte man bei SSH den Host-Key auch einfach permanent akzeptieren und "mir egal, is schon ok" nutzen. Dann hilft dir der RSA-Key aber eben auch nich wenn der Anwender den aus Bequemlichkeit z.B. auf seinem Webserver hinterlegt um den bequem an jedem Rechner mittels http runterladen zu können... und den natürlich auch überall gespeichert lässt... Es gibt IMMER den Menschlichen Faktor der in der Regel der grösste Angriffspunkt ist. Oder man überlegt eben mal welcher Schutz für ein System nötig ist - und lebt mit einem gewissen Rest-Risiko... (denn: Auch ein VPN schützt nicht wenn die Person davor es ausnutzt - vgl.: https://www.zeit.de/digital/internet/2013-01/outsourcing-china-verizon?u ..). Ganz ohne komplexes Man in the Middle, ganz simpel...

Also eine theoretische Gefahr ist keine Gefahr, alles offen lassen.

Ähm, ok, dann erklär mir einen anderen Weg, eine lokale Anmeldung zu verhindern und nur die Anmeldung per SSH zu erlauben, denn genau das waren die Rahmenbedingungen des TE, der ebenfalls schon zu dem Schluss gekommen ist, dass dies wohl nur über RSA-Keys umsetzbar ist.