Die Authentifizierung mit öffentlichem Schlüssel ist fehlgeschlagen

9

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
leetom@xxx.101.15.62'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

ssh authentication

— Leetom
quelle

12

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 .

— Greg
quelle

Es funktioniert, vielen Dank! Es stellt sich heraus, dass ich einen Tippfehler mit dem authorized_keysDateinamen hatte. Ich hatte jede Methode ausprobiert und den Dateinamen viele Male überprüft (ich habe etwas über Dateinamen-Tippfehler gelesen), aber ... Die Augen funktionieren nicht gut, solange ich

— müde

Verwenden ssh-copy-idmachte den Trick für mich

— Asaf

Dies funktioniert perfekt ... es sei denn, Sie haben einen Mac. :)

— Fixee

@ Fixe, brew install ssh-copy-idwenn Sie Homebrew verwenden

— Greg

1

Diese genauen Symptome können sich auch manifestieren, wenn Sie SELinux aktiviert und falsch konfiguriert haben, sodass sshd die Datei authorized_keys nicht lesen kann (nicht immer offensichtlich, ohne das SELinux-Überwachungsprotokoll zu betrachten, da SELinux so detailliert ist, dass Sie leicht darauf zugreifen können ein Zustand, in dem manuelles Lesen als Benutzer oder durch sudo erfolgreich sein kann)

— mtraceur

5

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.

— AntonioK
quelle

Ist das wirklich wahr? Die Berechtigungen von ~/sollten keine Rolle spielen, der Standard in Ubuntu ist normalerweise 755 in Home-Verzeichnissen und es funktioniert für mich.

— UlfR

Ich habe das wirklich mit CentOS 7 (sowohl auf dem Remote-Host) als auch mit OpenSSH_6.4 und OpenSSH_6.6.1 konfrontiert. chmod 700 ~Ich habe gerade mein Problem gelöst.

— AntonioK

Schön für dich! Aber: Demnach: askubuntu.com/a/69867/31749 Es können keine Gruppenschreibberechtigungen für das Home-Verzeichnis vorhanden sein, aber das Lesen von Gruppen sollte in Ordnung sein.

— UlfR

Okay, ich sollte überprüfen, ob 750 in meinem Fall auf diesem System funktioniert.

— AntonioK

2

Habe es gerade überprüft. chmod 750 ~funktioniert gut.

— AntonioK

3

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.

— Divya
quelle

3

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

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

— Yassin
quelle

1

Dies scheint hier nicht das Problem zu sein, aber trotzdem ein guter Punkt.

— LittleByBlue