ssh ohne password: Permission denied (publickey)

[piccus]

Hallo Forum,

folgendes Ziel:
fynchy soll sich über ssh _ohne_ Passwordeingabe auf dem Server (10.88.88.89) einloggen.


Diese Befehlsfolge lassse ich auf dem Client durchlaufen, nachdem auf dem Server SSHd installiert wurde:


useradd -m fynchy
passwd fynchy
ssh 10.88.88.89 useradd -m fynchy
ssh 10.88.88.89 passwd fynchy
sudo -u fynchy ssh-keygen -t rsa
ssh fynchy@10.88.88.89 mkdir .ssh
sudo -u fynchy scp /home/fynchy/.ssh/id_rsa.pub fynchy@10.88.88.89:.ssh/id_rsh.pub.client
ssh fynchy@10.88.88.89 cat /home/fynchy/.ssh/id_rsh.pub.client >> /home/fynchy/.ssh/authorized_keys
echo "root-Zugriff verhindern:"
ssh 10.88.88.89 sed -i '"s/.*PermitRootLogin.*/PermitRootLogin no/g"' /etc/ssh/sshd_config
ssh 10.88.88.89 /etc/init.d/ssh restart
echo "der Server ist jetzt neugestartet!"


Bis hierhin klappt ein passwordbasierter Login.



echo "Anmeldung mit Passwort verhindern:"
ssh 10.88.88.89 sed -i '"s/.*PasswordAuthentication.*/PasswordAuthentication no/g"' /etc/ssh/sshd_config
echo "SSH-Server neustarten"
ssh 10.88.88.89 /etc/init.d/ssh restart


Jetzt geht nischt mehr:
Permission denied (publickey)

-piccus

[drcux]

was sagt ein

ls -al /home/fynchy/

?

[piccus]

was sagt ein

ls -al /home/fynchy/

?

auf dem Client:



debian:~# ls -la /home/fynchy/
insgesamt 24
drwxr-xr-x 3 fynchy fynchy 4096 2008-05-13 16:14 .
drwxr-xr-x 4 root root 4096 2008-05-13 16:13 ..
-rw-r--r-- 1 fynchy fynchy 220 2008-05-13 16:13 .bash_logout
-rw-r--r-- 1 fynchy fynchy 414 2008-05-13 16:13 .bash_profile
-rw-r--r-- 1 fynchy fynchy 2227 2008-05-13 16:13 .bashrc
drwx------ 2 fynchy fynchy 4096 2008-05-13 16:14 .ssh

und das auf dem Server:


debian:~# ssh 10.88.88.89 ls -la /home/fynchy/
insgesamt 24
drwxr-xr-x 3 fynchy fynchy 4096 2008-05-15 17:51 .
drwxr-xr-x 4 root root 4096 2008-05-15 17:50 ..
-rw-r--r-- 1 fynchy fynchy 220 2008-05-15 17:50 .bash_logout
-rw-r--r-- 1 fynchy fynchy 414 2008-05-15 17:50 .bash_profile
-rw-r--r-- 1 fynchy fynchy 2227 2008-05-15 17:50 .bashrc
drwx------ 2 fynchy fynchy 4096 2008-05-15 17:51 .ssh
debian:~#

[Roger Wilco]

sudo -u fynchy scp /home/fynchy/.ssh/id_rsa.pub fynchy@10.88.88.89:.ssh/id_rsh.pub.client
ssh fynchy@10.88.88.89 cat /home/fynchy/.ssh/id_rsh.pub.client >> /home/fynchy/.ssh/authorized_keys
`man ssh-copy-id` ;)


Jetzt geht nischt mehr:
Permission denied (publickey)
Ist die Datei ~/.ssh/authorized_keys auf dem Server nur für den Benutzer les- und schreibbar?
Ist der Private Key im Verzeichnis ~/.ssh/ auf dem Client vorhanden und nur für den Benutzer les- und schreibbar?
Welche Meldungen von sshd stehen bei einem Loginversuch im Syslog (müsste Facility auth sein)?
Was sagt der SSH-Client beim Login, wenn du ihn mit dem Parameter -v etwas gesprächiger machst?

[piccus]

`man ssh-copy-id` ;)

Hab ich gmacht. Ist schön komfortabel, aber immernoch PERMISSION DENIED



Ist die Datei ~/.ssh/authorized_keys auf dem Server nur für den Benutzer les- und schreibbar?

jipp


Ist der Private Key im Verzeichnis ~/.ssh/ auf dem Client vorhanden und nur für den Benutzer les- und schreibbar?

jipp


Was sagt der SSH-Client beim Login, wenn du ihn mit dem Parameter -v etwas gesprächiger machst?

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
debian:~#

[Roger Wilco]

Und die Logs auf der Serverseite?

Dein SSH-Client sagt ja eindeutig, dass der Server deinen Private Key nicht mag.

[marce]

poste mal die sshd_config des Servers und die Logeinträge in /var/log/messages, die dort bei erfolgloser Anmeldung auftauchen.

[piccus]

poste mal die sshd_config des Servers und die Logeinträge in /var/log/messages, die dort bei erfolgloser Anmeldung auftauchen.



# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 222
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

[Roger Wilco]

And again: Logs...

Und bitte benutze die CODE-Tags. Und UsePAM auf no setzen (warum, siehe `man 5 sshd_config`).

[piccus]

Ich kann nicht erkennen, dass die Befehle


cat /var/log/messages
cat /var/log/syslog

irgendeinen Output produzieren, wenn sich der client erfolglos anmelden will!?

Kann es an den verschiedenen Uhrzeiten liegen?



debian:~# ssh -v -p 222 10.88.88.89
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.88.88.89 [10.88.88.89] port 222.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9etch2
debug1: match: OpenSSH_4.3p2 Debian-9etch2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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: Host '10.88.88.89' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
debian:~#

Jetzt steht hier ja was von Trying private key: /root/.ssh/...
Das verestehe ich nicht. Ich habe ja extra einen eigenen User lokal angelegt diesen dann auch den Key in seinem Home erzeugen lassen ... Root sollte da eigentlich außen vor bleiben...

[marce]

dann solltest Du den ssh-login auch als dieser User versuchen - und nicht als root (lt. Prompt)

[MiGo]

Das verestehe ich nicht. Ich habe ja extra einen eigenen User lokal angelegt diesen dann auch den Key in seinem Home erzeugen lassen ... Root sollte da eigentlich außen vor bleiben...
ssh ohne expliziten User nimmt immer den, der es ausführt (# ssh server == ssh root@server)
also:
ssh fynchy@10.88.88.89
und die Sache sollte passen.

[piccus]

ssh fynchy@10.88.88.89
und die Sache sollte passen.



debian:~# ssh -v -p 222 fynchy@10.88.88.89
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.88.88.89 [10.88.88.89] port 222.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9etch2
debug1: match: OpenSSH_4.3p2 Debian-9etch2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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: Host '10.88.88.89' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
debian:~#


:-(

[Sidolin]

Logs vom Server wären interessant. Sonst mal versuchen die Keys nochmal richtig zu kopieren, mit ssh-copy-id geht das einfach und ist dann auch richtig.

[Roger Wilco]

1. Logs vom SSH-Server. Sonst kann dir niemand helfen. Im Zweifel greppe über das gesamte /var/log nach "sshd" oder "ssh".
2. Fällt dir wirklich nicht auf, dass dein SSH-Client immer die Keys aus dem ~/.ssh Verzeichnis des aktuell eingeloggten Benutzers heranzieht? Probier es als der richtige Benutzer oder gib die Schlüsseldateien explizit mit "-o IdentityFile /path/to/home/.ssh/id_rsa" an oder editiere ~/.ssh/config entsprechend...

[marce]

ssh ohne expliziten User nimmt immer den, der es ausführt (# ssh server == ssh root@server)
also:
ssh fynchy@10.88.88.89
und die Sache sollte passen.
vermutlich nicht - da er auch dann den Key von root nimmt - und er sollte ja wohl den des Users nehmen. Vermutlich. Man weiß es ja nicht...

[piccus]

Problem gelöst: Weil die Alt-Gr-Taste in der VM nicht geht, habe ich mein Skript oben als root unter Putty laufen lassen. Daher wohl das Problem, dass ssh

ssh -v SSH-Server
ständig bei Root nach dem Schlüssel suchen wollte:

...
identity file /root/.ssh/id_rsa
...
owohl der bei fynchy liegt...

Dank an alle:-)

[piccus]

Ich habe den Fehler womöglich gefunden.

Weil die Alt-Gr-Taste in meiner VM nicht geht, habe ich die Befehle alle über putty durchgeführt. Damit hängt es wohl zusammen , dass

ssh -v server-IP
den Schlüssel immer in /root/.ssh/ gesucht und nicht gefunden hat:


debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).


Ohne den Putty-Umweg klappt das.
Dank an alle.

[Sidolin]

2. Fällt dir wirklich nicht auf, dass dein SSH-Client immer die Keys aus dem ~/.ssh Verzeichnis des aktuell eingeloggten Benutzers heranzieht? Probier es als der richtige Benutzer oder gib die Schlüsseldateien explizit mit "-o IdentityFile /path/to/home/.ssh/id_rsa" an oder editiere ~/.ssh/config entsprechend...

*hust* :D zehnzeichen