Die Authentifizierung mit öffentlichem Schlüssel ist fehlgeschlagen

Ich verwende Ubuntu 13.10 und auf dem Server wird Ubuntu 12.04 ausgeführt. Ich hatte private und öffentliche Schlüssel mit ssh-keygen generiert, id_rsa.pub auf die Serverseite gestellt und es authorzied_keysgemäß der im Internet gefundenen Methode hinzugefügt . Ich muss jedoch noch ein Passwort eingeben, während ich mich anmelden möchte. Ich habe das Ausgangsverzeichnis auf 700, das SSH-Verzeichnis auf 700, die Datei authorzied_keys auf 600 und die Datei checke sshd_config festgelegt, und es ist nichts passiert.

Die Debug-Informationen (mit der Option -vvv) und sshd_config lauten wie folgt und nichts ist in der auth.log-Datei des Servers aufgeführt.

Ich habe sogar openssh-server openssh-client sowohl auf der Client- als auch auf der Serverseite aktualisiert.

Muss ich noch etwas tun? Vielen Dank für jede Information.

debug3: load_hostkeys: loading entries for host "[xxx.101.15.62]:2222" from file "/home/leetom/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/leetom/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "[xxx.101.15.62]:2222" from file "/home/leetom/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/leetom/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host '[xxx.101.15.62]:2222' is known and matches the ECDSA host key.
debug1: Found key in /home/leetom/.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/leetom/.ssh/id_rsa ((nil)),
debug2: key: /home/leetom/.ssh/id_dsa ((nil)),
debug2: key: /home/leetom/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/leetom/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA 68:51:b6:ed:cc:c2:54:f4:xx:15:41:d7:f5:4a:0e:da
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/leetom/.ssh/id_dsa
debug3: no such identity: /home/leetom/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/leetom/.ssh/id_ecdsa
debug3: no such identity: /home/leetom/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password: 

und die sshd_config

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# 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
HostKey /etc/ssh/ssh_host_ecdsa_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 yes
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 yes

# 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

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Dieses Bit sieht so aus, als hätten wir Ihren privaten Schlüssel verwendet, um eine kryptografische Anmeldung zu versuchen. Dann mussten wir andere versuchen, da dies nicht akzeptiert wurde:

debug1: Trying private key: /home/leetom/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA 68:51:b6:ed:cc:c2:54:f4:xx:15:41:d7:f5:4a:0e:da
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password

Das einfachste Problem könnte darin bestehen, dass Sie den öffentlichen Schlüssel kopieren, da ich dieselbe Antwort erhalte, wenn ich versuche, mich mit einem Schlüssel zu authentifizieren, von dem ich weiß, dass das andere Ende hier nicht vorhanden ist.

Anstatt die ID manuell zu kopieren, versuchen Sie es doch einmal ssh-copy-id- geben Sie Ihr Passwort ein und es wird aktualisiert authorized_keys. Das sollte (a) definitiv den gleichen Schlüssel auswählen, der ausgewählt sshwerden soll, (b) sicherstellen, dass Sie nicht versehentlich Formatierungsfehler hinzugefügt haben.

Wenn das funktioniert für Sie, vergleichen Sie die Zeile hinzugefügt , um authorized_keysdurch ssh-copy-idund hoffentlich werden Sie verstehen , was schief gelaufen ist .

Berechtigungen können eine andere Art von Problem sein, das zu Fehlern bei der Authentifizierung mit öffentlichen Schlüsseln führt: Überprüfen Sie, ob Ihre ~und ~/.sshVerzeichnisse von niemandem außer Ihrem Benutzer gelesen werden können (dies chmod 700 ~ && chmod 700 ~/.sshkönnte behoben werden).

EDIT: Berechtigungen 750 für ~sollten auch in Ordnung sein.

authorized_keysHaben Sie beim Erstellen der Datei zufällig Ihren Dateinamen falsch geschrieben (da Sie ihn wie authorzied_keysin der Frage geschrieben haben (i und z ausgetauscht), besteht die Möglichkeit, dass Sie die Datei auf die gleiche Weise benannt haben) Der Name der Datei wird ausdrücklich als erwähnt

AuthorizedKeysFile %h/.ssh/authorized_keys

Daher müssen Sie besonders darauf achten, dass der Dateiname identisch ist. Überprüfen Sie einfach den Dateinamen.

Manchmal müssen Sie den privaten Schlüssel explizit mit -i angeben

Beispiel: ssh -i /root/.ssh/id_rsa2 user@remote