Berechtigung für Datei "authorized_key" verweigert


8

Auf Fedora 16 habe
ich meinen öffentlichen Schlüssel in die Datei /home/user/.ssh/authorized_keys kopiert. Der Benutzer stammt von ldap.

Konnte sich aber nicht über ssh ohne Passwort für diesen Benutzer authentifizieren.

Es funktioniert für root.

strace auf sshd

[pid 24834] setgroups(1, [1100])        = 0
[pid 24834] getgroups(0, NULL)          = 1
[pid 24834] getgroups(1, [1100])        = 1
[pid 24834] setgroups(1, [1100])        = 0
[pid 24834] setresgid(-1, 1100, -1)     = 0
[pid 24834] setresuid(-1, 1040, -1)     = 0
[pid 24834] open("/home/user/.ssh/authorized_keys", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission denied)
  • Ich habe versucht, mit dem Benutzerkonto auf die Datei zuzugreifen: kein Problem.
  • Ich habe es mit einem winzigen C-Programm mit den gleichen Optionen wie oben versucht: kein Problem.
  • Ich habe es mit 777 richtig versucht: kein Problem.

ls -l in der Datei "authorized_keys":

-rw-r--r--. 1 user user  784 19 nov.  16:24 authorized_keys
  • Ich habe versucht, StrictMode zu deaktivieren (und sshd neu zu starten)

Ich habe mit einem anderen Fedora 16 verglichen:

  • gleiches Betriebssystem
  • gleiche sshd_config-Datei
  • gleiche Berechtigungen für ~/, ~/.ssh/und~/.ssh/authorized_keys

Und jetzt weiß ich nicht, was ich versuchen soll, um das Problem zu beheben.


Gibt es nichts anderes an der Maschine? Apparmor? Vernetztes Home-Verzeichnis? Usw?
Mattias Åslund

Antworten:


9

Es könnte SE Linux sein. Wenn der Kontext der Datei nicht korrekt ist, führen Sie dies wie beschrieben aus root.

restorecon -Rv /home/user/.ssh

Überprüfen Sie auch, ob die Berechtigungen für /home/user/.sshnicht weit offen sind. SSHD ist diesbezüglich ganz besonders.

chmod 0700 /home/user/.ssh

2

Ihre authorized_keysDatei sollte Berechtigungen haben rw-------. Lauf:

chmod 600 ~/.ssh/authorized_keys

Und nur als Hinweis sollte Ihr privater Schlüssel (normalerweise id_rsa) auf dem Client die gleichen Berechtigungen haben.


Nein, funktioniert nicht besser :(
Trax

2
@trax gibt es dir immer noch den gleichen Fehler? Entweder in straceoder in ssh -vvvoder so?
Terdon

2

Ich hatte ein ähnliches Problem, und in meinem Fall war die Ursache ein falscher Besitz des .ssh-Verzeichnisses und der .ssh / autorisierten_keys-Datei. Um dies zu beheben, in / home / user als root:

chown user:user .ssh
chown user:user .ssh/authorized_keys

0

Nach Freddens Antwort (ich habe nicht genug Ruf, um einen Kommentar abzugeben) hatte ich ein ähnliches Problem mit RHEL 7, nachdem LogLevel DEBUG3ich sshd_config eingestellt (und den sshd-Dienst neu gestartet) hatte, bekam ich Folgendes in / var / log / Secure:

datetime servername sshd[11180]: debug1: Could not open authorized keys '/authorized_keys/authorized_keys': Permission denied

Obwohl der Ordner und die Datei die richtigen Berechtigungen haben (700 bzw. 600).

Wenn Sie den Verdacht haben, dass es sich um SElinux handelt (was sich als meins herausgestellt hat), können Sie dies überprüfen, indem Sie in /var/log/audit/audit.log nach dem Dateinamen suchen (in diesem Fall autorisierte_Tasten). Wenn dies der Schuldige ist, finden Sie einen Verweigerungseintrag mit dem Typ = AVC.

Ich habe SELinux nur in den zulässigen Modus versetzt, was wahrscheinlich nicht der beste Ansatz ist, aber wenig Zeit hat und es behoben hat. Ich habe das erst danach ausprobiert, restorecon -Rv /home/user/.sshweil ich nicht wusste, dass dies das Relevante ist (ich wusste zunächst nicht, dass SELinux das Problem verursacht).

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.