Die Authentifizierung mit öffentlichem Schlüssel schlägt NUR fehl, wenn sshd ein Dämon ist

33

Ich habe keine Ahnung, wie das passiert. Die Distribution ist Scientific Linux 6.1 und alles ist so eingerichtet, dass die Authentifizierung über den öffentlichen Schlüssel erfolgt. Wenn sshd jedoch als Daemon ausgeführt wird (Dienst sshd start), werden keine öffentlichen Schlüssel akzeptiert. (Um dieses Protokoll zu erhalten, habe ich das sshd-Skript geändert und die Option -ddd hinzugefügt.)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

Wenn sshd im Debug-Modus ausgeführt wird /usr/sbin/sshd -ddd, funktioniert die Authentifizierung wie ein Zauber:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

Irgendwelche Ideen?? Hat jemand so etwas gesehen?

Anmerkungen:

Dateiberechtigungen wurden doppelt geprüft:

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

Ich wurde gefragt, ob sshd im "Daemon-Modus" auf root-Dateien zugreifen kann. Die naheliegendste Antwort auf diese Frage lautet:

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

Wenn sshd als root ausgeführt wird, weiß ich nicht, wie es nicht möglich ist, auf seine eigenen Dateien zuzugreifen. Könnte SELinux die Ursache sein?

linux ssh authentication daemon keys user666412
quelle
1
Tut das sshd-Init-Skript etwas Interessantes? (Sollte /etc/init.d/sshd sein?), Dass Sie nicht in der Befehlszeile tun? Anstelle von 'service sshd start' versuchen Sie 'sh -x /etc/init.d/ssh start'.
PT

Antworten:

42

Ja, SELinux ist wahrscheinlich die Ursache. Das .sshVerzeichnis ist wahrscheinlich falsch beschriftet. Schau mal /var/log/audit/audit.log. Es sollte beschriftet sein ssh_home_t. Überprüfen Sie mit ls -laZ. Führen Sie, restorecon -r -vv /root/.sshwenn nötig.

Mark Wagner
quelle
1
Ja, SELinux war die Ursache: type = AVC msg = audit (1318597097.413: 5447): avc: denied {read} für pid = 19849 comm = "sshd" name = "authorized_keys" dev = dm-0 ino = 262398 scontext = unconfined_u : system_r: sshd_t: s0-s0: c0.c1023 tcontext = unconfined_u: object_r: admin_home_t: s0 tclass = file Funktioniert nach dem Ausführen von "restorecon -r -vv /root/.ssh". Vielen Dank.
user666412
1
danke DANKE DANKE für das selinux-Kommandozeilen-Update Ich habe seit langem versucht herauszufinden, warum ich ssh als root auf meinem redhat Enterprise 6.2-Server mithilfe der ssh-Schlüsselauthentifizierung verwenden konnte, aber ich konnte mich nicht als Nicht-Root-Benutzer einloggen ohne ein Passwort eingeben zu müssen. "ssh -v" zeigte überhaupt nichts Ungewöhnliches an. Ich hatte den Dateischutz in /home/example/.ssh überprüft und erneut überprüft. Erst als ich "/ usr / sbin / sshd -d" ausführte und aus irgendeinem Grund, der normal funktionierte, bemerkte ich, dass etwas anderes passierte, und versuchte eine andere Google-Suche und fand diese. Also, die Symptome waren, dass ich als ro ssh konnte
Paul M
1
Ich musste dies auf dem gesamten Dateisystem tun, dh restorecon -r /YMMV.
Irfy
1
Ich habe es versucht - aber immer noch nicht funktioniert. Im Audit-Protokoll habe ich type=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir- nicht sicher, was es bedeutet
Yehosef
1
Die Antwort war in der name="/"- ich musste die restorecon -r /als @Irfy vorgeschlagenen ausführen.
Yehosef
3

Ich hatte das gleiche Problem. In meinem Fall haben restorecon und chcon nicht funktioniert.

Ich wollte Selinux nicht deaktivieren. Nach vielen Recherchen habe ich schließlich herausgefunden, dass mein Home-Verzeichnis von einem anderen Ort bereitgestellt wurde (NFS). Ich habe diesen Fehlerbericht gefunden, der mir aufgefallen ist.

Ich rannte:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

um zu bestätigen, dass use_nfs_home_dirs ausgeschaltet war und dann:

sudo setsebool -P use_nfs_home_dirs 1

um es einzuschalten.

Jetzt kann ich mit meinem Schlüssel und ohne Eingabe eines Passworts auf meinen Computer sshen. Das Umschalten des Booleschen Werts use_home_nfs_dirs war das, was ich brauchte.

Gerard
quelle
1

Um Mark Wagners Antwort hinzuzufügen /home, müssen Sie sicherstellen, dass Sie den SELinux-Sicherheitskontext festgelegt haben, wenn Sie einen benutzerdefinierten Pfad für das Basisverzeichnis verwenden (dh nicht ). /myhomeFühren Sie dazu beispielsweise Folgendes aus, wenn Sie Benutzer-Ausgangsverzeichnisse haben :

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome
DavidArndt
quelle
Wenn Sie unter CentOS arbeiten, müssen Sie semanagesudo yum install policycoreutils-python
Folgendes
0

Es sieht so aus, als ob Sie beim Testen der Verbindungen unterschiedliche Schlüssel verwenden, 0x7f266e1a8840 vs 0x7f85527ef230. Versuchen Sie, mit 'ssh -v example.com' eine Verbindung zu sshd herzustellen, das als Daemon und im Debug-Modus ausgeführt wird, und suchen Sie nach den von ssh verwendeten Schlüsseln in der Zeichenfolge "Offering RSA public key".

Johan Nilsson
quelle
Ja, es gab id_rsa und id_dsa. Der DSA-Schlüssel ist weg und ich werde den Test wiederholen.
user666412
Der in angegebene Wert debug3: mm_answer_keyallowed: key 0xFFFFFFFFFFändert sich jedes Mal, wenn der sshd eine neue Verbindung erhält. Um dies zu bestätigen, suchen Sie einen Server, auf dem SSH funktioniert, drehen Sie den Schalter sshd LOGLEVEL auf debug3, starten Sie sshd neu, führen Sie ihn aus tail -f /var/log/secure |grep mm_answer_keyallowedund melden Sie sich dann einige Male an, wobei Sie zwischen den einzelnen Verbindungen einige Sekunden (oder Minuten) warten. Sie werden feststellen, dass sich der Wert jedes Mal ändert. Und tatsächlich sieht es für mich wie eine Gegendarstellung aus.
Stefan Lasiewski