Ubuntu-fr

cethomme

SSH - Clés d'identification inopérantes [RESOLU]

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. J'ai aussi modifié le paramètre PubkeyAuthentication  en le mettant à yes car ça me semblait pertinent mais je peux me tromper. Voilà le message que j'obtiens :

usr@server: Permission denied (publickey)

Je joins le contenu du fichier /etc/ssh/sshd_config :

# 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

J'ai aussi deux questions :

• la clé publique sur le serveur doit être dans /root/.ssh/ ou usr/.ssh/ ?

• 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 ?

Quelqu'un aurait-il une idée de l'origine de mon problème?

Dernière modification par cethomme (Le 22/06/2024, à 14:36)

ylag

Re : SSH - Clés d'identification inopérantes [RESOLU]

Bonjour,

As-tu consulté la doc SSH du forum, en particulier la section   3. Authentification :

https://doc.ubuntu-fr.org/ssh#authentification

A+

Dernière modification par ylag (Le 16/06/2024, à 16:48)

cethomme

Re : SSH - Clés d'identification inopérantes [RESOLU]

Merci Ylag pour ta réponse.
Je vais éplucher cette doc et voir si j'y trouve une piste.

Dernière modification par cethomme (Le 16/06/2024, à 17:41)

jplemoine

Re : SSH - Clés d'identification inopérantes [RESOLU]

Sinon, si tu peux te connecter via la console, il faut ajouter le mode verbose.

ssh -v user@machine

ou

ssh -vv user@machine

ou

ssh -vvv user@machine

1 v : peu de détail à 3v tout est décrit.

Dernière modification par jplemoine (Le 16/06/2024, à 21:53)

---

Membre de l'ALDIL (Association Lyonnaise pour le Développement de l'Informatique Libre)
- En pro, après 20 ans de développement, administrateur Linux / Unix depuis Avril 2019.
- En privé, sous Ubuntu-Xubuntu depuis 2009.
Déconnecté jusqu’à nouvel ordre

cethomme

Re : SSH - Clés d'identification inopérantes [RESOLU]

Après avoir lu la doc, j'ai effacé les anciennes clés, en ai générées 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 maintenant (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.
Je ne connaissais pas le -vv et le -vvv pour ssh. J'ai encore appris un truc.
Merci beaucoup, Ylag et Jplemoine, pour le temps passé à se pencher sur mon problème.

Dernière modification par cethomme (Le 19/06/2024, à 09:06)

cethomme

Re : SSH - Clés d'identification inopérantes [RESOLU]

Quelqu'un saurait-il par hasard comment modifier le titre d'une discussion pour indiquer que le problème est résolu ?
Je n'arrive pas à trouver comment le faire.

O_20_100_O

Re : SSH - Clés d'identification inopérantes [RESOLU]

Bonjour,

Depuis un compte utilisateur non privilégié, cela marche également maintenant (avec un sudo bien sûr)

Pourquoi "bien sûr" ? Pas certain que tout soit bien réglé.

Dernière modification par O_20_100_O (Le 19/06/2024, à 10:30)

cethomme

Re : SSH - Clés d'identification inopérantes [RESOLU]

Bonjour,
Parce que sans sudo, le serveur me demande toujours un mot de passe et n'utilise pas les clés.
Si je comprends bien ce qu tu sous-entends, on doit pouvoir se connecter au serveur avec les clés sans passer par un sudo ?

Dernière modification par cethomme (Le 19/06/2024, à 12:33)

cethomme

Re : SSH - Clés d'identification inopérantes [RESOLU]

Suite à ta remarque O_20_100_O, j'ai placé une copie des clés depuis /root/.ssh/ dans /home/user/.ssh/ (car elles n'y étaient pas). 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é.
Mais est-ce prudent de faire ce que j'ai fait ?

Dernière modification par cethomme (Le 19/06/2024, à 13:19)

O_20_100_O

Re : SSH - Clés d'identification inopérantes [RESOLU]

Ah, tu avais placé la clé dans les répertoires de root.

dans /home/user/.ssh/

Oui, c'est bien, surtout si c'est ta session.
https://doc.ubuntu-fr.org/ssh#authentif … iqueprivee

Dernière modification par O_20_100_O (Le 19/06/2024, à 13:21)

cethomme

Re : SSH - Clés d'identification inopérantes [RESOLU]

Quand j'ai 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.
Tout roule maintenant et c'est plus clair dans ma tête.
Merci pour tes remarques, elles m'ont bien aidé.