Puis-je utiliser l'authentification par clé SSH pour me connecter à un système distant avec un nom d'utilisateur différent?

Supposons que j'ai un système distant nommé "remotesystem" et un compte d'utilisateur "foouser" sur ce système.

Je sais que sur mon système local, je peux générer une paire de clés SSH en tant qu'utilisateur local "foouser", mettre la clé publique dans le fichier "/home/foouser/.ssh/authorized_keys" sur "remotesystem". Lorsque je SSH en tant que "foouser" de mon système local vers "remotesystem", SSH utilise la paire de clés pour m'authentifier.

Mais que se passe-t-il si mon nom d'utilisateur local n'est pas le même que le nom d'utilisateur sur le système distant? Autrement dit, que faire si je veux SSH en tant qu'utilisateur local "baruser" à "remotesystem"? Évidemment, je devrai générer une paire de clés pour "baruser" et ajouter la clé publique à "/home/foouser/.ssh/authorized_keys". Ensuite, je devrais pouvoir "ssh foouser @ remotesystem" tout en étant connecté en tant que "baruser" localement, et SSH utilisera la paire de clés pour s'authentifier, non?

Je demande parce que j'essaie de faire fonctionner l'authentification par clé dans ce scénario, sans succès. Je ne sais pas si c'est en raison de la non-concordance du nom d'utilisateur ou d'un problème de configuration avec le serveur SSH sur le système distant.

Oui, vous pouvez le faire, comme vous l'avez décrit.

baruser @ here ~ $ ssh-add -l
4096 10: b3: fd: 29: 08: 86: 24: a6: da: 0a: dd: c6: 1e: b0: 66: 6a id_rsa (RSA)
baruser @ here ~ $ ssh foouser @ remotesystem
message motd, etc.
foouser @ remotesystem ~ $

C'est un peu à part, mais .....

Si vous utilisez toujours le même nom d'utilisateur pour un serveur distant, vous pouvez également trouver utile d'ajouter un hôte dans votre configuration ssh:

Host remotesystem
    User baruser

De cette façon, vous n'avez pas besoin de vous souvenir de spécifier le nom d'utilisateur lors de la connexion, et vous l'excluez lorsque vous rencontrez des problèmes avec les clés à l'avenir.

Votre nom d'utilisateur local n'a pas vraiment d'importance (à part la clé privée devant résider dans le répertoire personnel de votre utilisateur local). Copiez simplement la clé dans la authorized_keyssection de l'utilisateur distant et cela fonctionnera.

Avec tout problème lié à ssh, la première chose à faire est d'augmenter la verbosité du client:

ssh user @ machine -vvv

Si cela ne vous donne aucune idée de ce qui ne va pas, vous devez modifier le niveau de journalisation sur le serveur et redémarrer le démon.

LogLevel DEBUG3

Vous devriez trouver la sortie de débogage dans /var/log/auth.log (ou là où ssh est configuré pour se connecter). Une fois que vous avez trouvé le problème, n'oubliez pas de le ramener à la façon dont vous l'avez trouvé.

Les autorisations sur les répertoires .ssh sur les deux machines sont très correctes. Généralement, cela signifie 700 sur le répertoire .ssh et au plus 755 sur le répertoire personnel. En plus de 600 sur tous les fichiers des répertoires .ssh.

Si l'utilisateur sur le système distant est root, assurez-vous que root peut ssh. (PermitRootLogin dans sshd_config) et que la clé publique (PubkeyAuthentication) et si nécessaire RSA (RSAAuthentication) sont activées.

Si SE Linux est activé, vous devrez également procéder comme suit.

Ajoutez le label SELinux à authorized_keysafin qu'il soit accessible par sshd.

semanage fcontext -a -t sshd_key_t ~foo/.ssh/authorized_keys
restorecon -Rv ~user/.ssh

On dirait que vous faites les choses correctement, mais assurez-vous que les autorisations sont correctes sur les touches autorisées. Ils doivent être définis sur 600.