Solución 1:
Sí, puedes hacer esto, tal como lo describiste.
[email protected] ~$ ssh-add -l 4096 10:b3:fd:29:08:86:24:a6:da:0a:dd:c6:1e:b0:66:6a id_rsa (RSA) [email protected] ~$ ssh [email protected] motd message, etc. [email protected] ~$
Solución 2:
Es un poco aparte, pero...
Si siempre usa el mismo nombre de usuario para un servidor remoto, también puede resultarle útil agregar un host a su configuración ssh:
Host remotesystem
User baruser
De esa manera, no necesita recordar especificar el nombre de usuario al iniciar sesión, y lo descarta cuando tenga problemas con las claves en el futuro.
Solución 3:
Su nombre de usuario local realmente no importa (aparte de que la clave privada debe residir dentro del directorio de inicio de su usuario local). Simplemente copie la clave en el authorized_keys del usuario remoto. sección y funcionará.
Solución 4:
Con cualquier problema relacionado con ssh, lo primero que debe hacer es aumentar la verbosidad del cliente:
ssh [email protected] -vvv
Si esto no le da ninguna idea de lo que está mal, debe cambiar el nivel de registro en el servidor y reiniciar el daemon.
LogLevel DEBUG3
Debería encontrar la salida de depuración en /var/log/auth.log (o donde sea que ssh esté configurado para iniciar sesión). Una vez que haya encontrado el problema, recuerde volver a configurarlo como lo encontró.
Solución 5:
Los permisos en los directorios .ssh en ambas máquinas deben ser correctos. Generalmente, eso significa 700 en el directorio .ssh y como máximo 755 en el directorio de inicio. Además de 600 en todos los archivos de los directorios .ssh.
Si el usuario en el sistema remoto es root, asegúrese de que root pueda usar ssh. (PermitRootLogin en sshd_config) y esa clave pública (PubkeyAuthentication) y, si es necesario, RSA (RSAAuthentication) están habilitadas.