Permission Denied (PublicKey)

[strix]

Code: Alles auswählen

> ssh user2@domain.ch -i ~/.ssh/id_rsa -v
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to domain.ch [178.77.120.227] port 22.
debug1: Connection established.
debug1: identity file ~/.ssh/id_rsa type 1
debug1: identity file ~/.ssh/id_rs -cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 97:fa:18:9d:a5:b0:b1:c5:f4:31:ee:83:1a:1a:72:62
debug1: Host 'strixmaster.ch' is known and matches the RSA host key.
debug1: Found key in ~/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Aber folgendes: (Derselbe PrivateKey!)

Code: Alles auswählen

> ssh user1@domain.ch -i ~/.ssh/id_rsa -v
Welcome to my server!

Und die PublicKeys auf dem Server sind ebenfalls die selben. Muss ich dem User2 (der neu erstellt wurde) irgendwelche zusätzlichen Rechte geben oder woran könnte das liegen? In der sshd_config ist AuthorizedKeysFile auf %h/.ssh/authorized_keys gelegt, AllowUsers user1 user2 ebenfalls.

[Cae]

Und die PublicKeys auf dem Server sind ebenfalls die selben.

Verstehe ich das richtig, dass bei beiden Usern des entfernten Servers die Schluessel in der jeweiligen ~/.ssh/authorized_keys liegen? Stimmen die Berechtigungen auf .ssh und die Datei selbst?

Gruss Cae

[strix]

Und die PublicKeys auf dem Server sind ebenfalls die selben.

Verstehe ich das richtig, dass bei beiden Usern des entfernten Servers die Schluessel in der jeweiligen ~/.ssh/authorized_keys liegen?

Testweise, ja. Bei beiden Usern benutze ich im Beispiel oben dieselben Public- wie auch PrivateKeys.

Stimmen die Berechtigungen auf .ssh und die Datei selbst?

Code: Alles auswählen

> ls -l /home/user2
drwx------. 2 user2 user2 4096 26. Jan 16:57 .ssh

> ls -l .ssh/
-rwx------. 1 user2 user2 404 26. Jan 16:55 authorized_keys

[DeletedUserReAsG]

Nur zur Sicherheit: den sshd hast du nach dem Ändern der Config mal restarted? Ohne die neue Konfiguration zu laden, verhält sich sshd nämlich so, wie es bei dir gerade der Fall ist.

cu,
niemand

[Cae]

Hmm, ist ls jetzt ein alias auf ls -a oder ist das passend nachgebaut? Die authorized_keys ist ausfuehrbar, was ebenfalls nicht sein sollte. Vielleicht liegt's schon daran. Uebrigens sind da ACLs gesetzt, koennte eine weitere Fehlerquelle sein.

Gruss Cae

[strix]

@niemand: ja, SSHD wurde neu gestartet

@Cae: Seltsamerweise ist weder acl noch SELinux o.ä. installiert ??


Edit: Doch, selinux ist offensichtlich drauf. Muss ich ev da was anpassen?

[Cae]

Die authorized_keys ist ausfuehrbar, was ebenfalls nicht sein sollte.

Hattest du das geaendert und getestet?

SELinux hat damit wahrscheinlich nichts zu tun, wenn's nicht explizit konfiguriert wurde.

Gruss Cae

[DeletedUserReAsG]

So ohne weitere Infos ist‘s Rätzelraten. Was auf der Serverseite schiefläuft, sieht man ja nicht. In die Logs hast du mal geschaut und nichts gefunden, nehme ich an?

Dann wäre mein Vorschlag nun, auf der Maschine einen zweiten sshd auf einem anderen Port und im Debug-Modus (-d), ansonsten mit der gleichen Konfiguration, zu starten und mal zu schauen, ob sich da keine Erkenntnis gewinnen lässt. Aufpassen, wenn die Kiste woanders ist, um nicht aus Versehen plötzlich gar keinen sshd mehr zu haben.

cu,
niemand