SSH-Authentifizierung mit Keys - ich stehe auf der Leitung

[Acid-Beatz]

Guten Abend zusammen,
ich habe mich mal etwas mit SSH-Authentifizierung über Keys auseinandergesetzt und werde in der Praxis irgendwie nicht so ganz schlau, es funktioniert so halb halb - ich schildere einfach mal bisschen meine Gedanken:

Ich erstelle auf Computer A mit ssh-keygen unter einem Benutzer Test zwei Schlüssel, den öffentlichen und den privaten, Passwort wird erst mal keins vergeben.

Den öffentlichen Schlüssel von Test transferiere ich dann per scp/Brieftaube auf Computer B, dort trage ich ihn unter dem Benutzer root in authorized_keys ein (bewusst nicht mit ssh-copy-id gemacht, weil ich den Prozess verstehen will und da gerade meine Probleme habe :wink: ).

Gedanke: Letztlich sagt ja der Eintrag in authorized_keys aus, dass ich für diesen Benutzer berechtigt bin, den Eintrag vorzunehmen und somit das lokale User- oder Root-Passwort kenne.

Hier passt alles und ich kann mich von Computer A als root ohne Passwort Computer B anmelden (ssh root@B)

Nachfolgend der Teil, der mich nun verwirrt und nicht funktioniert:
Trage ich den gleichen, öffentlichen Key von Computer A/Test auf Computer B unter dem Benutzer xyz ein, dann kann ich mich NICHT ohne Passwort authentifizieren, wie es beim ersten Fall möglich war.

Habe ich hier irgendwelche sehr groben Denkfehler oder sollte es mir eigentlich doch möglich sein, dass ich mich nun an Computer B/xyz ohne Passwort anmelden können sollte :conf2:

Über Anregungen/Tips wäre ich sehr dankbar!

[myMind]

Ich erstelle auf Computer A mit ssh-keygen unter einem Benutzer Test zwei Schlüssel, den öffentlichen und den privaten, Passwort wird erst mal keins vergeben.
Keine gute Idee. Kommt der Schlüssel irgendwie in fremde Hände, sind alle deine Zugänge ohne weiteren Aufwand seitens des Schlüssel"finders" kompromitiert.
Habe ich hier irgendwelche sehr groben Denkfehler oder sollte es mir eigentlich doch möglich sein, dass ich mich nun an Computer B/xyz ohne Passwort anmelden können sollte :conf2:
Sollte funktionieren, wenn korrekt konfiguriert.

ssh -v <zielaccount>@<zielmaschine>

sollte dir den Grund des Verbindungsproblems anzeigen.

[Acid-Beatz]

Erst mal Danke für die Antwort:

Keine gute Idee. Kommt der Schlüssel irgendwie in fremde Hände, sind alle deine Zugänge ohne weiteren Aufwand seitens des Schlüssel"finders" kompromitiert.
Dem bin ich mir bewusst, zeitweise lassen sich so aber Türen für Skripte öffnen oder gäbe es da sinnvollere Möglichkeiten, als das Passwort herauszugeben?


Sollte funktionieren, wenn korrekt konfiguriert.

ssh -v <zielaccount>@<zielmaschine>

sollte dir den Grund des Verbindungsproblems anzeigen.

Heute keine Lust, morgen aber gerne :)
(was ich nicht geschrieben habe - der remote Computer verlangt dann das Passwort, also einen direkten Error vermute ich an dieser Stelle nicht ... )

[Milchkanne]

Liegt vielleicht an den Dateiberechtigungen von ~/.ssh/ oder den Dateien da drin. Die dürfen auf keinen Fall "other writable" sein. Ich meine .ssh muss sogar 700 sein und alle private keys auch 600
Ansonsten mal mit "ssh -v user@host" probieren und gucken, was der Output so sagt (geht über -vv bis -vvv).

[PHuV]

Ich meine .ssh muss sogar 700 sein und alle private keys auch 600
Ansonsten mal mit "ssh -v user@host" probieren und gucken, was der Output so sagt (geht über -vv bis -vvv).
Du meinst richtig.

Ansonsten ist es ganz einfach: pub-key in die authorized_keys auf den Rechner, wo man ran will, rsa_id bleibt auf dem Host. Dann noch die known-hosts erweitern, und das wars.

Beim root-User muß eventuell in der /etc/ssh(d)/sshd_config
PermitRootLogin no
auf yes gesetzt werden. Hier gibt es noch ein paar weitere Einstellungen, die bei Unterschieden von Quell- und Zielrechner Probleme machen können (IgnoreUserKnownHosts uwm.), hier einfach mal die Einstellungen vergleichen.

Also, am besten die sshd-Einstellungen auf Computer B überprüfen.

Übrigens, bei mir war es das letzte mal ein Übertragungsfehler des Pub-Keys. ;) Das "ssh-rsa ASC39SCXSD" am Anfang des Keys hat gefehlt, und ich hab mehrere Stunden gesucht.

[Der Eulenträger von Athen]

Jetzt mal unabhängig von der Thematik, ist es empfehlenswert, als sich als root per ssh einzuloggen oder sollte man das aus Sicherheitsgründen unterbinden (für Server außerhalb des LAN)?

[Arcanoxer]

Jetzt mal unabhängig von der Thematik, ist es empfehlenswert, als sich als root per ssh einzuloggen oder sollte man das aus Sicherheitsgründen unterbinden (für Server außerhalb des LAN)?Ich habe das zur Fernadministration immer gemacht, geht ja meistens nicht ohne root.

[Acid-Beatz]

Hallo noch mal,
heute noch mal ausprobiert und auf Anhieb hat alles geklappt, keine Ahnung wo meine Gedanken gestern waren :rolleyes: .

Vielen Dank an alle! Grüße

[Der Eulenträger von Athen]

Ich habe das zur Fernadministration immer gemacht, geht ja meistens nicht ohne root.
Nun, man könnte auch einen zweiten normalen Benutzer für SSH freischalten und dann mit su zu root wechseln.

[Arcanoxer]

Nun, man könnte auch einen zweiten normalen Benutzer für SSH freischalten und dann mit su zu root wechseln.
Ach so meinst du das.
Das ist natürlich der richtige sichere Weg.

[lumines]

Jetzt mal unabhängig von der Thematik, ist es empfehlenswert, als sich als root per ssh einzuloggen oder sollte man das aus Sicherheitsgründen unterbinden (für Server außerhalb des LAN)?

Wenn man sich nicht als Root einloggen kann, sondern als normaler User, hat man den Vorteil, dass es ein Username ist, den ein Angreifer gar nicht kennt. Der versucht sich dann als Root einzuloggen, aber das wird nicht gehen. Und alle möglichen, gängigen Usernamen durchzuprobieren, ist auch sehr mühselig, weil er dabei sowieso kein Feedback bekommt, ob es den User gibt.

Und wenn du einmal etwas in SSHd falsch konfiguriert haben solltest und sich jemand mit Passphrasen direkt anmelden kann, dann wird er das nur als User können. D.h. bei eventuellen Fehlkonfigurationen (soll vorkommen), ist das noch immer besser als direkt per Root einen Login anzubieten.

Der Aufwand ist mit sudo ja auch sehr gering, deshalb würde ich das immer so bevorzugen. Sudo kann auch auch alles, was man mit einer „normalen“ Root-Shell machen kann. Auch einen persistenten Login, aber das würde ich nicht empfehlen, auch wenn das geht.

[Der Eulenträger von Athen]

Und wenn du einmal etwas in SSHd falsch konfiguriert haben solltest und sich jemand mit Passphrasen direkt anmelden kann, dann wird er das nur als User können. D.h. bei eventuellen Fehlkonfigurationen (soll vorkommen), ist das noch immer besser als direkt per Root einen Login anzubieten.
Das meinte ich: einen single point of impact vermeiden und die Angriffspunkte verteilen. Hat ein Angreifer meinen root login (I accidently posted it in an IRC channel :ulol:), kommt er trotzdem nicht ran. Mit dem SSH User, dessen Namen und Passwort er erstmal herausfinden muss, kann er nichts anrichten.

Und zum Thema PKI: das Ziel ist es, SSH-Zugriff nur von Systemen, die den private key haben, zuzulassen, oder? Anmeldung ohne Passwort ist nur ein angenehmer Nebeneffekt?

[Acid-Beatz]

Und wenn du einmal etwas in SSHd falsch konfiguriert haben solltest und sich jemand mit Passphrasen direkt anmelden kann, dann wird er das nur als User können. D.h. bei eventuellen Fehlkonfigurationen (soll vorkommen), ist das noch immer besser als direkt per Root einen Login anzubieten.
Hier muss ich noch mal kurz nachhaken: Welche speziellen Fehler schweben dir bei bei einer sshd Konfiguration durch den Kopf - anmelden ohne Passwort ist das einzige, was mir gerade einfällt :|
Ich meine, selbst wenn ich einen Schlüssel für Root ohne Passphrase hinterlegt habe, dann müsste der Angreifer doch meinen dazugehörigen privaten Schlüssel haben, damit er sich einloggen kann?

Wenn man sich nicht als Root einloggen kann, sondern als normaler User, hat man den Vorteil, dass es ein Username ist, den ein Angreifer gar nicht kennt.
Kann ich auch bestätigen - 95% der Angriffe gehen auf root, daneben relativ wahrscheinliche Accounts wie db-admin, sql-user, test UND Frauennamen :freak:


Und zum Thema PKI: das Ziel ist es, SSH-Zugriff nur von Systemen, die den private key haben, zuzulassen, oder? Anmeldung ohne Passwort ist nur ein angenehmer Nebeneffekt?
Im konkreten Fall geht um die Hinterlegung eines Schlüssels, damit ein Skript Software installieren kann.
Da im Idealfall aber auf allen Systemen verschiedene Passwörter für root gültig sind, steht man eben vor der Wahl, wie man einem solchen Skript Zugang gewährt - Schlüssel hinterlegen erschien die bessere Wahl, als alle Passwörter weiterzugeben und hinterher zu ändern.

I accidently posted it in an IRC channel
W00T, gab es da ernsthaft mal einen Fall:cop:

[Lokadamus]

Das meinte ich: einen single point of impact vermeiden und die Angriffspunkte verteilen. Hat ein Angreifer meinen root login (I accidently posted it in an IRC channel :ulol:), kommt er trotzdem nicht ran. Mit dem SSH User, dessen Namen und Passwort er erstmal herausfinden muss, kann er nichts anrichten.Naja, durch Bruteforce soll sowas schon klappen und ein Botnetz kann einige Sicherheitsmaßnahmen wie "IP nach x Versuchen sperren" ignorieren. ;(
Dürfte für die meisten Firmen uninteressant sein, aber wenn möglich würde ich ssh nicht im Internet anbieten. ;)
Hier muss ich noch mal kurz nachhaken: Welche speziellen Fehler schweben dir bei bei einer sshd Konfiguration durch den Kopf - anmelden ohne Passwort ist das einzige, was mir gerade einfällt :|
Ich meine, selbst wenn ich einen Schlüssel für Root ohne Passphrase hinterlegt habe, dann müsste der Angreifer doch meinen dazugehörigen privaten Schlüssel haben, damit er sich einloggen kann?Ein Trojaner könnte dir den Schlüssel mopsen, aber das selbe Problem wäre bei einem Keylogger ebenfalls vorhanden.

Gibt ein paar Parameter, worüber man sich streiten kann.
PermitRootLogin, Kennwortabfrage ...Im konkreten Fall geht um die Hinterlegung eines Schlüssels, damit ein Skript Software installieren kann.
Da im Idealfall aber auf allen Systemen verschiedene Passwörter für root gültig sind, steht man eben vor der Wahl, wie man einem solchen Skript Zugang gewährt - Schlüssel hinterlegen erschien die bessere Wahl, als alle Passwörter weiterzugeben und hinterher zu ändern.Und klappt es jetzt?

[Acid-Beatz]

Ein Trojaner könnte dir den Schlüssel mopsen, aber das selbe Problem wäre bei einem Keylogger ebenfalls vorhanden.
Genau den Gedanken hatte ich auch - gehüpft wie gesprungen.

Gibt ein paar Parameter, worüber man sich streiten kann.
PermitRootLogin, Kennwortabfrage ...
Joa, den root Login decken wir ja gerade mit der "weiteren" Diskussion ab und die Kennwortabfrage habe ich ja bereits aufgezählt.
Wovor ich ja immer Angst habe, sind einfach Löcher, die man unwissend aufreissen kann - mir fällt zwar gerade kein konkretes Beispiel ein, Ihr wisst aber vermutlich, was ich meine.

Und klappt es jetzt?
Ich habe ja erst mal nur zum Verständnis für mich selbst getestet, dort hat es heute morgen dann genau so geklappt, wie ich das erwartet habe - vermutlich waren es gestern "nur" irgendwelche Flüchtigkeitsfehler :sneak:

Der Test in der Realität kommt dann diese oder nächste Woche, der Key war nur ein sehr kleiner Teil des Gesamtpakets, man darf also gespannt sein :wink:


Ansonsten kann die Diskussion aber gerne auch noch weitergehen, man erfährt ja immer wieder interessante Sachen, die man aus dem eigenen Standpunkt anders eingeschätzt hat.


Greez

[fezie]

Beim root-User muß eventuell in der /etc/ssh(d)/sshd_config
PermitRootLogin no
auf yes gesetzt werden.

Also ich persönlich nutze immer PermitRootLogin without-password
So groß ist der Unterschied dann auch nicht mehr, root Login ganz zu verbieten.
Wenn jemand Zugriff auf den ssh key hat, dann vielleicht auch auf die .bash_history wo der Benutzername drin steht, den man anstatt root nutzt.

Bei einem öffentlich erreichbarem SSH Server mit Passwort Authentifizierung bei root, kann man halt in der Standard Konfiguration soviel Bruteforce machen wie man will.
Wenn man ein sehr sicheres Passwort hat und einem die Log Einträge nicht stören, dann ist das etwa vergleichbar von der Sicherheit.