SSH - Connexion par clés inopérante

[7ohm]

Bonjour à tous,
Pour me connecter à un serveur en SSH, j'ai généré une paire de clés d'identification avec ssh-keygen et copié la clé publique sur le serveur avec ssh-copy-id mais quand je cherche à me connecter, le serveur me réclame toujours le mot de passe de connexion, comme si les clés n'étaient pas prises en compte.
En cherchant un peu, j'ai lu que l'on pouvait modifier le fichier /etc/ssh/sshd_config pour désactiver la connexion par mot de passe en passant le paramètre PasswordAuthentication à no ce que j'ai fait et voilà le message que j'obtiens :

Code : Tout sélectionner

usr@server: Permission denied (publickey)

Quelqu'un aurait-il une idée d'où vient le problème?

[7ohm]

Merci Cyrille de te pencher sur ma question.
Ce que tu expliques dans ton pense-bête, je l'ai déjà fait (mise à part la partie concernant fail2ban).
De quels fichiers de conf parles-tu exactement ?
Petite question : la clé publique sur le serveur doit être dans /root/.ssh/ ou usr/.ssh/ ?

[7ohm]

Voici le fichier /etc/ssh/sshd_config côté serveur :

Code : Tout sélectionner

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

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

# 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 override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

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

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

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

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication 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 KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

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

# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

D'ailleurs à ce sujet me vient une question : la modification de /etc/ssh/sshd_config pour la désactivation de l'identification par mot de passe, c'est côté client ou côté serveur qu'il faut la faire ?

[7ohm]

Merci pour tes conseils.
Je tente ça dès que je peux.
Bonne soirée.

[7ohm]

J'ai effacé les anciennes clés, en ai généré de nouvelles et les envoyées sur le serveur.
Puis, alors que j'étais en root, j'ai tenté une connexion et là les clés ont fonctionné immédiatement.
Depuis un compte utilisateur non privilégié, cela marche également (avec un sudo bien sûr)
Je pense qu'il l'y avait dû y avoir un problème au moment de génération des clés la première fois.
Merci beaucoup, Cyrille, pour le temps passé à se pencher sur mon problème.

[7ohm]

Ce n'est pas que je voulais l'utliser en root mais, quand j'ai retenté la connexion, j'étais en root à ce moment-là.
Mais si c'est plus sûr depuis un compte non privilégié, je le ferai naturellement comme ça puisque ça marche maintenant.
Encore merci pour les conseils.

[7ohm]

Quand j'avais généré les clés, je n'avais pas spécifié de répertoire et il les avait placées dans /root/.ssh/, répertoire par défaut je suppose. Or, j'ai constaté qu'il n'y avait aucune clé dans /home/user/.ssh/
J'ai donc essayé de placer une copie des clés depuis /root/.ssh/ dans /home/user/.ssh/, j'ai changé le propriétaire des fichiers des clés pour user et j'ai tenté de me reconnecter et là, ça a fonctionné.
Plus besoin de faire un sudo pour se connecter en ssh depuis user.
Mon problème venait de là depuis le début.
Je comprends vite mais il faut m'expliquer longtemps...