L'authentification par clé publique a échoué
J'utilise Ubuntu 13.10 et le serveur tourne sous Ubuntu 12.04. J'avais généré des clés privées et publiques à l'aide de ssh-keygen, puis mis id_rsa.pub côté serveur et ajouté à authorzied_keys conformément à la méthode trouvée sur Internet. Mais, je dois encore entrer le mot de passe pendant que je tente de me connecter. J'ai défini le répertoire home sur 700, le répertoire .ssh sur 700, le fichier authorzied_keys sur 600 et j’ai checke le fichier sshd_config, et rien ne s’est produit.
Les informations de débogage (avec l'option -vvv) et sshd_config sont comme suit et rien n'est répertorié dans le fichier auth.log du serveur.
J'ai même mis à jour openssh-server openssh-client à la fois côté client et côté serveur.
Y a-t-il autre chose que je dois faire? Merci pour toute 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:
et le 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
On dirait que nous avons utilisé votre clé privée pour tenter une connexion cryptographique. Nous avons ensuite dû en essayer d'autres car cela n'a pas été accepté:
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
Le problème le plus simple pourrait être lié à la copie de la clé publique, car je reçois la même réponse en essayant de m'authentifier avec une clé que l'autre extrémité n'a pas ici.
Plutôt que de copier manuellement l'id, pourquoi ne pas essayer ssh-copy-id - entrez votre mot de passe et il mettra à jour authorized_keys. Cela devrait (a) choisir définitivement la même clé que ssh devrait sélectionner, (b) vous assurer que vous n'avez pas accidentellement ajouté d'erreurs de formatage.
Si cela vous convient, comparez la ligne ajoutée à authorized_keys par ssh-copy-id et si tout va bien vous comprendrez ce qui ne va pas.
Par chance, lors de la création du fichier authorized_keys, avez-vous mal orthographié votre nom de fichier (puisque vous l'avez orthographié comme suit: authorzied_keys dans la question (i et z échangés), il est possible que vous ayez nommé le fichier de la même manière) dans le fichier de configuration ssh , le nom du fichier est spécifiquement mentionné comme
AuthorizedKeysFile %h/.ssh/authorized_keys
Par conséquent, vous devez préciser que le nom du fichier est le même. Il suffit donc de vérifier le nom du fichier.
Les autorisations peuvent être un autre type de problème provoquant des échecs d'authentification publique: vérifiez que vos répertoires ~ et ~/.ssh ne sont pas lisibles par quiconque, à l'exception de votre utilisateur (chmod 700 ~ && chmod 700 ~/.ssh pourrait résoudre ce problème).
EDIT: les autorisations 750 pour ~ devraient également convenir.
Parfois, vous devez fournir explicitement la clé privée avec -i
Exemple: ssh -i /root/.ssh/id_rsa2 user@remote