Hace unos meses configuré una pequeña máquina de Linux y configuré el inicio de sesión ssh sin contraseña tanto para mi ID de usuario personal como para mi ID de cuenta de servicio. Eso funciona bien para ambos. Guardé los archivos de clave pública/privada para la cuenta de servicio en el mismo lugar donde almacené las claves de mi ID de usuario personal, en el cuadro del cliente.
Estoy usando lo siguiente para mi guía básica:http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/.
Hoy configuré un segundo cuadro, con la intención de configurarlo de la misma manera. No tuve problemas para que funcionara con mi ID de usuario personal. Sin embargo, todavía no funciona para la cuenta de servicio, pero no entiendo por qué. Cuando intento realizar el ssh con la cuenta de servicio en el segundo cuadro, me solicita la contraseña y luego me deja entrar.
Verifiqué que la clave pública de la cuenta de servicio esté insertada en el archivo ~/.ssh/authorized_keys en ambos cuadros y que el valor de la clave sea el mismo en ambos cuadros.
Verifiqué que ~/.ssh tiene permisos de 700 y que ~/.ssh/authorized_keys tiene permisos de 600 (también probé con 640, que es lo que leí como el valor recomendado). Verifiqué esto en ambos cuadros, en el directorio de inicio de la cuenta de servicio.
Tenga en cuenta que el ID de usuario numérico de la cuenta de servicio es diferente en los dos cuadros. No creo que eso haga ninguna diferencia.
También observo que después de enviar por ssh a cualquiera de los cuadros con la cuenta de servicio, si intento ingresar por ssh al OTRO cuadro desde ese, usando la cuenta de servicio, me solicita una contraseña.
¿Necesito hacer algo con "known_hosts" o algo más?
Actualizar:
Como se recomendó, intenté ejecutar ssh con "-v" e inspeccionar el resultado del intento de ssh.
Este es el resultado, con algunas elisiones:
% ssh -v [email protected]
OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /home/myuserid/.ssh/config
debug1: /home/myuserid/.ssh/config line 2: Applying options for *
debug1: Connecting to targethost.com [...] port 22.
debug1: Connection established.
debug1: identity file /home/myuserid/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to targethost.com:22 as 'serviceaccountid'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:...
debug1: Host 'targethost.com' is known and matches the ECDSA host key.
debug1: Found key in /home/myuserid/.ssh/known_hosts:18
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuserid/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/myuserid/.ssh/id_dsa
debug1: Trying private key: /home/myuserid/.ssh/id_ecdsa
debug1: Trying private key: /home/myuserid/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password:
Me parece curioso que en las últimas líneas, después de "Siguiente método de autenticación: clave pública", las referencias a la ruta del archivo sean "/home/myuserid", no "/home/serviceaccountid". Eso parece una gran pista.
Respuesta1
No puedo agregar comentarios con mi cuenta, pero solo soy yo tratando de obtener más información para ayudar a solucionar el problema.
Parece que tienes tres computadoras, una local y dos remotas. ¿Y cada uno de ellos tiene dos cuentas con las que estás trabajando?
Si tiene una cuenta personal y de servicio en la máquina local y ejecuta ssh service@remote-2desde la cuenta personal en su máquina local, entonces solo encontrará claves ssh para su cuenta personal local, no la cuenta de servicio. Esto no debería importar si Hemos agregado la clave pública personal local al archivo de claves autorizadas de la cuenta de servicio remoto.
Me parece curioso que en las últimas líneas, después de "Siguiente método de autenticación: clave pública", las referencias a la ruta del archivo sean "/home/myuserid", no "/home/serviceaccountid". Eso parece una gran pista.
Eso es ssh buscando claves en la cuenta local. Debería ser el directorio de inicio de cualquier cuenta desde la que esté llamando a ssh. Si espera que esa ruta sea el hogar de una cuenta de servicio, entonces debe iniciar sesión en la cuenta de servicio yentoncesejecuta ssh.