49372
Goto Top

Permission denied (publickey,password,keyboard-interactive)

Ich erhalte mit dem ssh befehl folgenden error wenn ich auf eine andere Linux Maschine zugreifen möchte, welches im selben Netzwerk ist:

Permission denied (publickey,password,keyboard-interactive)

/etc/ssh/sshd_config:

#       $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 22
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
LogLevel VERBOSE

# Authentication:

#LoginGraceTime 120
PermitRootLogin no
StrictModes no

RSAAuthentication no
PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys
AuthorizedKeysFile      /home/vmware/.ssh/authorized_keys

# rhosts authentication should not be used
#RhostsAuthentication no
# 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/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for 
# RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication no

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

#AFSTokenPassing no
# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# Set this to 'yes' to enable PAM keyboard-interactive authentication 
# Warning: enabling this may bypass the setting of 'PasswordAuthentication' 
#PAMAuthenticationViaKbdInt no

#X11Forwarding no

X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes

#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no
#ShowPatchLevel no

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server
Ciphers aes256-cbc,aes128-cbc

ich bin nun seit gut 4 Stunden an dem Problem und habe noch keine Lösung gefunden, fand zwar im Internet einige Beträge, jedoch nicht für mein Problem, welches gelöst hätte.

RSA Schlüssel wurde generiert und wie auf 1 konfiguriert.

Content-Key: 115910

Url: https://administrator.de/contentid/115910

Printed on: April 23, 2024 at 12:04 o'clock

Member: theton
theton May 12, 2009 at 16:12:01 (UTC)
Goto Top
Nutzt du ein Passwort oder einen Keyfile für den Login? Wenn ein Key verwendet wird... Ist der Public Key in /home/vmware/.ssh/authorized_keys eingetragen? Gehört dem Benutzer, mit dem du dich einloggst, die /home/vmware/.ssh/authorized_keys und ist nur für ihn les- und schreibbar? Was sagen die Logs des SSH-Servers beim Login-Versuch? Und wie ist der Verbose-Output des Clients?
Mitglied: 49372
49372 May 12, 2009 at 18:04:44 (UTC)
Goto Top
ein keyfile welches ich mit ssh-keygen -t rsa erstellt habe ohne zusätzliches passwort.
Der Public Key ist vom anderen Linux Computer in die authorized_keys hineingeschrieben worden.

ja ist les und schreibbar und auch nur für den benutzer selbst

was ist ein verbose output?
Member: theton
theton May 12, 2009 at 18:09:56 (UTC)
Goto Top
Den Verbose-Output bekommst du, wenn du ssh den Parameter '-v' übergibst. Ausserdem solltest du natürlich mal einen Blick in die syslogs des Servers werfen, wo sicherlich auch aufgezeichnet ist warum der Login schief ging.
Member: dog
dog May 12, 2009 at 21:09:48 (UTC)
Goto Top
Ändere doch mal die Konfiguration folgendermaßen:

AuthorizedKeysFile      %h/.ssh/authorized_keys

usePAM no

Und immer dran denken: Danach sshd neustarten.

Grüße

Max
Mitglied: 49372
49372 May 13, 2009 at 06:26:14 (UTC)
Goto Top
Es hat nichts genützt, komischerweise erhalte ich nun seit heute morgen folgenden error wenn ich mich mit ssh 192.168.0.10 verbinden möchte:

Host Key verification failed.

Mit dem Befehl ssh -v 192.168.0.10 erhalte ich folgende Ausgabe:

 OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to 192.168.0.10 [192.168.0.10] port 22.
debug1: Connection established.
debug1: identity file /home/admin/.ssh/id_rsa type 1
debug1: identity file /home/admin/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes256-cbc hmac-md5 none
debug1: kex: client->server aes256-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST 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
Host key verification failed.
debug1: Calling cleanup 0x8062d60(0x0)
 

Ich bin am ende meines wissens über ssh
auffalend ist, das keine know_host datei angelegt wurde im .ssh verzeichnis
Member: theton
theton May 13, 2009 at 10:14:23 (UTC)
Goto Top
Solange du nur die Hälfte der Rückfragen beantwortest, wird die Fehlersuche nur noch mühsamer. Was ist mit den Server-Logs?