ssh schlüssel protokollieren

*Sheep

*Sheep

des Unterseepudels Kern
Es wird die pubkey. method benutzt um sich auf den Rechner via ssh anzumelden.
Ich möchte die Schlüssel protokollieren, die sich erfolgreich angemeldet haben.
Die sshd_config bietet mir den loglevel an. Ich habe das ,,Logging´´ von INFO auf VERBOSE gestellt. VREBOSE schreibt mir die das auth.log voll :\ INFO schreibt mir die keys nicht in logfile rein. :(
Hat jemand ne Idee wie ich den loglevel auf INFO zu lassen und trotzdem die keys zu loggen?


Ach ja, ich benutze root als login (bewußt).
 
Loool, wer root als Login benutzt, ist der Hilfe nicht wuerdig! :) *SCNR*

Du willst User-Login und sudo(1) verwenden.
 
WAS genau spricht dagen sich als root einzuloggen?

Wenn sshd keine Schwachstelle hat ist ein root login nichts schlimmes.
 
Die Administratoren sollen sich mit ihren Schlüsseln anmelden, um zu sehen wer sich wann angemeldet hat, ist eine Möglichkeit die Schlüssel zu protokollieren bei einem root-login.
 
Die Administratoren kriegen einen User-Account und koennten dann su(1) oder sudo(1) verwenden. Dann weiss man auch, welcher Account kompromittiert wurde, wenn es zu einem Einbruch kommt.

Stell dir vor, jmd. loggt sich von IP X als root ein. Dann hast du erstmal keine Ahnung, wer das wirklich ist.

Nochmal: root ist kein normaler Account. Man loggt sich damit nicht ein, man startet damit kein X. Man editiert noch nicht einmal die dotfiles unter /root, weil es eben ein unpersonalisierter Account ist. Fuer alle Sachen, fuer die man wirklich UID 0 braucht gibt es su/sudo. Wenn das deinen "Administratoren" zu umstaendlich ist, dann haben die von UNIX keine Ahnung und sollten lieber Windows administrieren.
 
Keine Ahnung wie und ob man das loggen kann, habe mir noch keine Gedanken darüber gemacht.
Evtl. wäre es besser wenn die Admins sich mit ihrem Namen via ssh (auch mit Schlüssel) anmelden würden. Danach kann dann ohne Probleme unterschieden werden wer wann sich angemeldet hat.
Dann kann man sudo einrichten und bestimmte Dinge freigeben.
root login via ssh würde ich komplett ausschalten, es reicht aus wenn die Leute, so sie auf dem Rechner sind, sudo nutzen oder zu root wechseln können (wenn es unbedingt sein muss).
Auch das mehrere User das Kennwort/Schlüssel von root kennen und sich darüber einloggen können würde ich unterbinden (es gibt 2 die das root-pw kennen, der Sysadmin und der Tresor, imho).
Möchte da jetzt aber keine Grundsatzdiskussion draus machen, nur sagen das man es anders, imho besser, regeln könnte.
 
*Sheep schrieb:
doch er wird übertragen..
Zum Vergrößern anklicken....
Der Server verschlüsselt mit dem PublicKey eine Zufallszahl, überträgt die an den Client, der entschlüsselt sie mit seinem PrivateKey und schickt das Ergebnis zurück. Sendet der Client die richtige Zahl hat er offensichtlich den richtigen PrivKey und erhält Zugang zum System.

Lies dir *dringend* nochmal durch wie PublicKey Authentication funktioniert.
 
Wenn man mehr als nur einen Rechner administriert, die nicht ,,vor Ort´´ sind, ist ssh die einzige Alternative. Der Umweg über sudo/su ist mir bekannt nur sehr (zeitaufwendig) die Benutzerkonten zu pflegen. Die publickey Authentifikation ist mir sehr wohl bekannt, ich benutze sie schlisslich auch. Das EINZIGE was ich wollte die RSA-Schlüssel zu protokollieren.
loglevel INFO logt sie nicht und VERBOSE log sie aber vielzu viel. Alle weiteren kommentare sind überflüssig.
 
hallo,

@Elessar: FULL ACK, er wird ein "challenge"uebertragen, nicht der pub key!

@sheep: kannst du den logeintrag mal zeigen, damit wir mal sehen wie er den key uebertraegt?!

gruss
 
Zuletzt bearbeitet:
Code: 
Aug 5 11:57:37 sshd[4237]: Found matching RSA key: b9:4f:c6:dc:4a:36:ce:0d:73:ca:26:42:b0:33:25:4d
Aug 5 11:57:37 sshd[4237]: Accepted publickey for root from 1.1.0.0 port 1377 ssh2

i.O, ich habe die Beiträge noch mal gelesen -- ich habe mich vieleicht etwas unglücklich ausgedrückt. Er protokolliert mit welchem Schlüssel sich eingelogt wurde.
 
das ist der key fingerprint nicht der pub key :)

aber wie das ohne "VERBOSE" gehen soll weiss gerad auch ned. BTW, so viel log is das auch ned. musst halt das was du brauchst raus grep'en. wenn du es so mach willst.

gruss
 
Zuletzt bearbeitet:
Hi,

@Sheep

ich habe die Diskussion jetzt erst gelesen. Wie schon geschrieben wurde, wird kein Schlüssel übertragen. Auch wenn du den Fingerprint des benutzen Schlüssels im Logfile sehen kannst, hilft dir das nicht weiter. Der Grund dafür ist ganz einfach. Bei PublicKey-Athentication bilden die Schlüssel ein Schlüsselpaar. Die Betonung liegt auf paar. Paar sollte eigentlich groß geschreiben werden, um zu verdeutlichen, das es genau zwei sind. Du müsstest dann schon den privaten Schlüssel an die Leute ausgeben, die sich als root einloggen sollen und damit kannst du sie nicht mehr unterscheiden. Das Verteilen der private-Keys ist eine genauso doofe Idee, wie das root-PW rauszugeben. Die Unterscheidung kannst du nur machen, wenn für jeden Nutzer ein Schlüsselpaar existiert und die Berechtigten dann einen su, sudo whatever machen.

Gruß c.
 
crotchmaster schrieb:
Auch wenn du den Fingerprint des benutzen Schlüssels im Logfile sehen kannst, hilft dir das nicht weiter. Der Grund dafür ist ganz einfach. Bei PublicKey-Athentication bilden die Schlüssel ein Schlüsselpaar. Die Betonung liegt auf paar. Paar sollte eigentlich groß geschreiben werden, um zu verdeutlichen, das es genau zwei sind. Du müsstest dann schon den privaten Schlüssel an die Leute ausgeben, die sich als root einloggen sollen und damit kannst du sie nicht mehr unterscheiden. Das Verteilen der private-Keys ist eine genauso doofe Idee, wie das root-PW rauszugeben. Die Unterscheidung kannst du nur machen, wenn für jeden Nutzer ein Schlüsselpaar existiert und die Berechtigten dann einen su, sudo whatever machen.
Zum Vergrößern anklicken....

Ich glaube, du bist etwas verwirrt, was die PKI von ssh anbelangt. Man kann sich mit beliebig vielen versch. Schluesseln auf einem Login einloggen. Das, was der OP da vor hat, ist durchaus machbar und logisch, wenn es sich dabei um einen beliebigen Account handeln wuerde.

Aber nicht, wenn es um UID 0 geht.
 
Zusammenfassung
- +20 Rechner sollen (remote) gewartet werden
- Gruppe von Admins soll dies möglich sein
- praktikable Benutzerverwaltung (zentral) ist nicht möglich
- Pflege der authorized_keys für Benutzer root (entsprechende FW Regeln & Authentifikation nur über keys)
- Aktivierung des Loglevels VERBOSE (Fingerprint des entsprechenden Schlüssels wird protokolliert)
- Anpassung des Logfileanalysetools
 
Um nochmal auf das eigentliche Problem zurückzukommen:
Du kannst das Loglevel auf VERBOSE setzen und dann syslog-ng benutzen, um die Keys in ein extra Logfile zu schreiben.
 
MrFixit schrieb:
Ich glaube, du bist etwas verwirrt, was die PKI von ssh anbelangt. Man kann sich mit beliebig vielen versch. Schluesseln auf einem Login einloggen. Das, was der OP da vor hat, ist durchaus machbar und logisch, wenn es sich dabei um einen beliebigen Account handeln wuerde.

Aber nicht, wenn es um UID 0 geht.
Zum Vergrößern anklicken....

Schande über mich. Ich hatte die die authorized_keys-Datei vergessen und bin bisher auch garnicht auf die Idee gekommen, für einen Account mehrere Schlüsselpaare zu generieren. Bisher hatte ich immer eine Kombination pro User.

Gruß c.
 
Edit: direkt vergessen, hab die Antworten auf Seite 2 übersehen....
:confused:

man ssh müsste dazu was hergeben:

Wie wärs mit einem loginscript, dass beim einloggen je nach verwendetem Key etwas entsprechendes irgendwohin loggt?

Syntax war bei OpenSSL etwa:
Code: 
forced_cmd=/usr/local/bin/myCoolLogin _PuBlIcKeY_here_

kommt IIRC in die ~/.ssh/.authorized_keys
(bin mir da aber nicht mehr ganz sicher)

Im SSH-Buch von O'Reilly stehen dazu tolle Sachen :)
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben