SSH Key - Logging

[rep]

Hallo Leute,

man kann ja eine Anmeldung an einem SSHd mittels Key machen. Das habe ich nun erfolgreich auf einigen Systemen gemacht. Ich würde nun aber gerne mitloggen wer sich eingeloggt hat. Da meine Kollegen auch den Key beim User Root hinterlegt haben, loggen sich alle als root ein. (Ich weiß es geht auch per User und su)

Nun stell ich mir die Frage, ob ich in eine Logdatei schreiben kann wer sich angemeldet hat, bzw. welcher Schlüssel. Kann ich das "auslesen" wie ich mich eingeloggt habe?

gruß

[Aqualung]

Kannst Du z.B. so


cat /var/log/messages | grep ssh

sehen.

Gruß Aqualung

[rep]

da steht nix... auch bei syslog (da debian) steht nix...
in auth steht aber was... nur nicht genug :-)



Feb 20 21:53:31 server02 sshd[11681]: Accepted publickey for root from x.x.x.x port 1113 ssh2
Feb 20 21:53:32 server02 sshd[11683]: (pam_unix) session opened for user root by root(uid=0)

[marce]

was reicht Dir daran nicht?

Evtl. reicht es ja, den Loglevel auf Info, Debug oder sonstwas hochzudrehen...

[rep]

ich habe mehrere User mit unterschiedlichen publickey, ich will unterscheiden können wer es war...

Geht das, so die Frage?

[marce]

ok, und die IP-Adresse des Clients reicht Dir nicht?

Würde es wie gesagt mal mit dem LogLevel probieren...

[rep]

Nein, die IP ist eine von einem Internetanschluss, mit Dynamischer oder Festerip, die Feste hat dann aber alle User hinter sich, also auch uninteressant, ich check mal das Loglevel, und meld mich...

[Aqualung]

falls Du das nicht deaktiviert hast, kannst Du mit


last

sehen, wer sich eingeloggt hat.

Gruß Aqualung

[marce]

... und er erhält dann Login + IP - genau das, was er jetzt auch schon hat.

[rep]

Unter Etch, in /etc/ssh/sshd_config "LogLevel INFO zu LogLevel VERBOSE" ändern, debug ist ne Nummer zu hart...



Feb 21 11:22:13 server02 sshd[15138]: Found matching RSA key: f8:77:d8:64:c9:05:c7:b2:85:43:bf:3d:06:b1:f6:bd
Feb 21 11:22:20 server02 sshd[15138]: Found matching RSA key: f8:77:d8:64:c9:05:c7:b2:85:43:bf:3d:06:b1:f6:bd
Fe


scheint also zu klappen... muss ich mir nur den Fingerprint notieren, oder kann man den anhand der infos aus dem "/root/.ssh/authorized_keys" berechnen? Dann brauch ich nix nachträglich machen..

würde nämlcih das gerne in eine Logdatei schreiben und dnan dne realen User loggen. Dazu brauch ich eine Übersetzung des Namens in den Fingerprint...

danke für eure Hilfe...

Gruß

[marce]

Der Fingerabdruck eines öffentlichen Schlüssels (englisch: Public Key Fingerprint) oder die Fingerprint ID ist der Hashwert einer, auf einem öffentlichen Schlüssel angewendeten, Hash-Funktion, d. h. eine kurze Zahlenfolge, mit der man den bedeutend längeren Schlüssel eindeutig und zugleich schnell identifizieren kann. Durch den Abgleich des Fingerabdrucks lässt sich ein zuvor elektronisch ausgetauschter Schlüssel am Telefon oder bei einer persönlichen Begegnung verifizieren (siehe Web of Trust).
Sofern Du den Hash-Algorythmus kennst - sollte das gehen...

[Aqualung]

Das kannst Du z.B. ähnlich so lösen:


for i in /home/*; do ssh-keygen -l -f "$i/.ssh/id_dsa.pub" ; done | grep "key"


Gruß Aqualung

[marce]

insgesamt "eleganter" wäre allerdings die Version mit User-Login und nachfolgenden su oder sudo...

[rep]

Mensch danke leute, das ging zu schnell als das ich selbst heute Nachmittag schauen könnte, bin im RZ und wollte heute Mittag weiter machen, da ich gerade nur kurz zwischendurch Zeit habe ;-)

Aber perfekte Antworten, special thanks.


Und ja, ich sagte ja, per user und su ist es eleganter und vielleicht auch sicherer, aber leider bin ich nicht der einzige der das entscheidet, und praktischer ist es oft... Hierrüber lohnt aber nicht zu diskutieren grundsätzlich bin ich aiuch der Meinung. :-) Danke trotzdem

[FLOST]

Leg doch für jeden User noch einen Adminaccount an. In der passwd dann die UID auf "0" ändern, dann hat er root-Rechte, wird aber in allen Logdateien mit seinem Namen geloggt. Somit hast du immer eine Zuordnung, wer was gemacht hat. Wenn alle mit dem normalen root-acc arbeiten, kannst du das nicht unterscheiden.

[rep]

Ich muss noch mal, es hat alles geklapt, den Hinweis mit Sudo und das elegantere würde ich auch gerne noch mal checken. Ich kann mir aber nun gerade nicht vorstellen wir Ihr das meint....

Wobei auch die Erleichterung an der Sache wäre, das wir nicht für alle einen Benutzer anlegen müssten. Die Sudo variante würde dann den User auch komplett alles als Root machen lassen? oder meintest Du nur Teile darf er dann explizit über Sudo ausführen?

gruß

[403]

man kann auch remote root login wrappen, so dass der user bevor rootshell erhaelt , seinen Namen eintippen muss/auswaehlen muss aus menu usw.
(das ganze dann evtl. noch per mail anstossen.)

das wuerde die ganzen anderen roots sparen ;)

Gruss
403

[rep]

Gibt es da irgendwo eine Referenz oder HowTo, ich kann das gerade nicht so ganz nachvollziehen. Denke das würde diesen Thread auch für andere als Referenz erleichten. :-)

[403]

vielleicht kann ich eins schreiben ;)

du brauchst ein shellscript in den authorized_keys von root. such mal nach ssh und forced-commands.

Gruss
403

[THEReapMan]

schon der sicherheit willen würde ich einfach in der sshd_config den root-login zunageln "permit_rootlogin no" oder so ähnlich. dann sind sie gezwungen sich als user anzumelden und per su zu arbeiten.
Und bei dem Gedanken von mehreren usern mit ID 0 bzw. generell der gleichen Id stelln sich mir die nackenhaare auf.

[403]

@THEReapMan

Dass sich mehrere admins remote root einloggen ist gaengige Praxis. Um das voellig sicher zu machen geht natuerlich auch OpenSSH mit OneTImePads. Ansonsten sieht es so aus:

admin perspektive

PermitRootLogin without_password oder
PermitRootLogin forced-commands-only

(optional noch das Einloggen auf bestimmte Hosts einschraenken)

Nachteil: Clients kompromitierbar, das Howto mit dem wrapper in authorized_keys spaeter


security perspektive

PermitRootLogin No
und sudo config

Nachteil: Jeder Admin muss mehr tippen ;) Durch falsch konfiguriertes sudo hat man dann effektiv
ohnehin wieder remote root login


Gruss
403

[403]

also der urspruengliche Plan war ja per user auszuwerten. da aber dabei jeder jeden be*******en kann,
braucht es wohl etwas administrative mithilfe. (das gilt uebrigens auch
fuer die fingerprints, es braucht eine Methode um den Client eindeutig identifizieren zu
koennen, nur selbst wenn, die Clients koennen diese Methode jederzeit untereinander austauschen)

1. Test sshd aufsetzen
2. Test Schluessel erzeugen
3. Schluessel fuer die User raussuchen und command in authorized_keys eintragen:



command="/bin/echo Hello" ssh-dss AAAAB3NzaC1kc3MAAACRhlDm13nSPZehp [..]
yI8sobYQ= 403@


4. Wenn das Prinzip klar ist, Testlogin versuchen, Ausgabe sollte etwa sein:



ssh -p 12121 403@linuxbox.de
Hello
Connection closed by remote host


5. Wrapper erstellen: (diese einfache Variante waere um Commands abzusetzen,
das Ding ist schon ein bissl angestaubt ;)




#!/bin/sh -
LOG=(/var/log/ssh-original-cmd.log)
COM=$(echo "$SSH_ORIGINAL_COMMAND"|awk '{ print $1 }')
IP=$(echo $SSH_CONNECTION|awk '{ print $1 }')

# LOG everything first
echo "`date` | $SSH_ORIGINAL_COMMAND|Exit Status: $? |IP: $IP'" >> "$LOG"

case "$SSH_ORIGINAL_COMMAND" in

test*)
echo "${COM}" ${COM}
;;
ls*)
/bin/ls
;;
*)
/bin/echo "not allowed"${COM}
;;
esac



Alternativ kann man jetzt aber auch case fingerprint machen:
(Nachteil ist das Pflegen der Fingerprints, und wenn alle alle Fingerprints tauschen)


admin gibt ein:


% ssh-add -l
8192 85:b0:e9:bd:d3:ff:b6:d9:1e:7e:10:80:f7:f1:0e:18 .ssh/rsa (RSA)
% export Fingerprint='85:b0:e9:bd:d3:ff:b6:d9:1e:7e:10:80:f 7:f1:0e:18'
% ssh host $Fingerprint


Auf dem Host laueft dann /tmp/wrap das im authorized_key von root
spezifiziert wird:



case "$SSH_ORIGINAL_COMMAND" in

'85:b0:e9:bd:d3:ff:b6:d9:1e:7e:10:80:f7:f1:0e:18')
echo "`date` | $SSH_ORIGINAL_COMMAND|Exit Status: $? |IP: $IP'" >> "$LOG"& /bin/bash -i
;;
'85:b0:e9:bd:d3:ff:b6:d9:1e:7e:10:80:f7:f1:0e:11')
echo "`date` | $SSH_ORIGINAL_COMMAND|Exit Status: $? |IP:a $IP'" >> "$LOG"& echo 'sorry, expired'; exit
;;
*)
/bin/echo "not a valid fp... disconnecting"; exit
;;
esac




Beim Debuggen mit ssh sollte sowas kommen:



debug2: we sent a publickey packet, wait for reply
debug1: Remote: Forced command: /tmp/wrap
[..]
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.


debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd ext data 35
bash: no job control in this shell
debug2: channel 0: written 35 to efd 6
debug2: channel 0: rcvd ext data 16
[t@vs160xxx ~]$ debug2: channel 0: written 16 to efd 6

debug2: channel 0: rcvd ext data 16
[t@vs160xxx~]$ debug2: channel 0: written 16 to efd 6
ls -la
total 44
drwx------ 3 t t 4096 Sep 13 04:07 .
drwxr-xr-x 11 root root 4096 Sep 12 05:26 ..
-rw------- 1 t t 2210 Sep 13 04:17 .bash_history
-rw-r--r-- 1 t t 302 Sep 12 05:26 .bash_logout
-rw-r--r-- 1 t t 191 Sep 12 05:26 .bash_profile
-rw-r--r-- 1 t t 124 Sep 12 05:26 .bashrc
-rw------- 1 t t 42 Sep 13 04:06 .lesshst
-rw-r--r-- 1 t t 134 Sep 12 05:26 .rcrc
drwx------ 2 t t 4096 Sep 13 04:07 .ssh
-rw------- 1 t t 1074 Sep 13 04:07 .viminfo
-rw-r--r-- 1 t t 658 Sep 12 05:26 .zshrc




Anzumerken ist, dass die bash in diesem Beispiel je nach Grad des Vetrauens fuer
den jeweiligen Admin durch einen anderen Befehl zu ersetzen ist. :rolleyes:

Fuer Deine Ansprueche denke ich dass eine Strichliste fuer den jeweiligen Admin und wann er sich eingeloggt hat genuegen sollte.
Ein Programm bei dem der User immer einen Grund vorher angeben muss, habe ich mir mal geschrieben, aber natuerlich lassen
sich hier auch nun wieder beliebige Dinge eintragen.

Gruss
403

[rep]

sehr schöne Sachen, muss ich mir dann mal in Ruhe ansehen, danke an alle...