El diálogo de contraseña aparece cuando los permisos de clave privada SSH se establecen en 0600

Instalé mi clave privada SSH ~/.ssh/id_rsay configuré sus permisos en 0600. Cuando me conecto a un servidor SSH que usa mi clave privada en Terminal.app vía ssh, aparece un cuadro de diálogo y me pide que ingrese mi contraseña para acceder al id_rsaarchivo:

Veo el mismo cuadro de diálogo cuando me conecto a un servidor FTP con el cliente Interarchy GUI.

Actualización: veo este cuadro de diálogo cada vez que me conecto, independientemente de si marco "Recordar contraseña en mi llavero". Aparece dos veces más si se hace clic en el botón Aceptar, independientemente de lo que se ingrese en el campo de contraseña.

Cuando relajo estos permisos para, por ejemplo, 0640ya no veo un cuadro de diálogo que me pide mi contraseña, pero sshaborta con el siguiente error:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@
@ ADVERTENCIA: ¡ARCHIVO DE CLAVE PRIVADO NO PROTEGIDO! @ @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@
Los permisos 0640 para '/Users/myusername/.ssh/id_rsa' están demasiado abiertos.
Se recomienda que otras personas no puedan acceder a sus archivos de clave privada.
Esta clave privada será ignorada.
permisos incorrectos: ignorar clave: /Users/myusername/.ssh/id_rsa

El diálogo de contraseña me parece extremadamente molesto y estoy seguro de que debe haber alguna forma de evitar tener que descartar este diálogo. SSH necesita acceder al id_rsaarchivo.

Nota: estoy ejecutando Mac OS X 10.6.8.

Asegúrese de tener un correspondiente id_rsa.pubo id_dsa.puben su ~/.sshdirectorio.

Cuando tenía un id_rsapero no un correspondiente id_rsa.pub, Mac OS X seguía apareciendo el cuadro de diálogo y recuerdo que la contraseña en mi llavero no hizo nada.

cd ~/.ssh
ssh-keygen -y -f id_rsa > id_rsa.pub

generó el archivo de clave pública apropiado para mí.

Si ya tenía su archivo público allí (cámbiele el nombre a otro nombre) y genere la clave pública nuevamente usando el comando anterior, notará que el generado y el antiguo no son iguales. De alguna manera, las versiones anteriores de Mac OS X generaron una clave pública que Lion ya no le gusta, y al generarla nuevamente se corrige eso.

Para los curiosos, la clave es exactamente la misma, la parte que cambia es que ya no hay una sección de "comentarios" después de la clave en el archivo.

Primero, ejecute ssh-add -Ky verifique si esto soluciona su problema.

Si no:

• Se eliminó el archivo rsa_id.pub y se volvió a generar uno nuevo (debe estar en ~ / .ssh /):

  ssh-keygen -y -f id_rsa > id_rsa.pub

• Los permisos garantizados se establecieron en 600 para id_rsa e id_rsa.pub (deben estar en ~ / .ssh /):

  chmod 600 id_rsa*

• Ejecutó el siguiente comando:

  ssh-add -K

Después de hacer esto, ya no se me solicitó dar mi contraseña de clave privada. Esto parece poner realmente la contraseña de la clave privada en la ubicación correcta del llavero para que OS X la use.

En mi caso ssh-add -Kno funcionó, tuve que especificar la clave:

ssh-add ~/.ssh/id_rsa

Para macOS 10.12, Sierra ssh-add -Kdebe ejecutarse después de cada reinicio. Para evitar esto, cree ~/.ssh/configcon este contenido.

Host *
   AddKeysToAgent yes
   UseKeychain yes
   IdentityFile ~/.ssh/id_rsa

Apple ha agregado Technote 2449 que explica lo que sucedió.

Antes de macOS Sierra, ssh presentaría un cuadro de diálogo pidiendo su frase de contraseña y ofrecería la opción de almacenarla en el llavero. Esta IU quedó en desuso hace algún tiempo y se ha eliminado.

Editar: aparentemente no es necesario especificar un host y una clave. Solo agregar esto es suficiente.

AddKeysToAgent yes
UseKeychain yes

Debe ingresar la frase de contraseña para la clave privada en algún lugar, y OS X usa ssh-agent por defecto.

Si desea usar ssh-agent pero quiere evitar el cuadro de diálogo de la interfaz gráfica de usuario, puede usar ssh-add para agregar la frase de contraseña al agente y luego ssh como de costumbre.

Si no desea utilizar ssh-agent y, en su lugar, tiene ssh prompt para la frase de contraseña, desactive la variable de entorno SSH_AUTH_SOCK.

Cuando relaja los permisos, se ignora la clave. No ganarás nada haciendo esto.

Si desea utilizar una clave sin tener que ingresar una contraseña cada vez, tiene dos opciones.

Si marca la casilla "Recordar contraseña en mi llavero", no tendrá que escribir la contraseña cada vez: se almacenará en el llavero con todas sus otras contraseñas. Esta es la opción recomendada.

Puede crear un archivo de clave privada sin contraseña. Puede cambiar su archivo de clave privada existente para que no esté protegido por contraseña (cambiar la contraseña solo afecta al archivo de clave, no a la clave en sí). Desde la línea de comando, ejecute ssh -p, ingrese la frase de contraseña existente y luego deje la nueva frase en blanco. Existe un riesgo de seguridad al tener una frase de contraseña vacía: cualquiera que pueda acceder a su archivo de clave privada (por ejemplo, accediendo a sus copias de seguridad) puede usarlo instantáneamente.

si ha agregado su clave privada al directorio fuente ~ / .ssh, y ha ingresado ssh-add -K para agregarla al llavero, y tiene los contenidos de su clave pública copiados en .ssh / Authorized_keys (para la correcta cuenta) en el servidor de destino, el cuadro de diálogo desaparece.

Es una combinación complicada de archivos, permisos, ubicaciones y comandos, por lo que puede llevar tiempo. No me apresuraría a llegar a una conclusión sobre los errores.

Tengo exactamente el mismo problema en Lion (Mac OS X 10.7). Creo que es un error ... Si la autenticación ssh es contraseña, el cliente pasa primero por la clave pública, lo cual es normal. Sin embargo, aunque elija guardar la frase de contraseña en el llavero (que no es necesario para la autenticación de contraseña) la próxima vez que se establezca una nueva conexión ssh, se le pedirá nuevamente la frase de contraseña ...

No debería haber necesidad de regenerar sus claves públicas. Simplemente puede hacer estos dos comandos:

chmod 0600 ~/.ssh/id_rsa.pub
ssh-add ~/.ssh/id_rsa

Básicamente, debe ajustar los permisos en el archivo de clave pública, y debe agregar su clave al agente de autenticación OSX.

En la última versión de macOS (10.12.2 - Sierra) esta es una solución fácil. Simplemente edite su ~ / .ssh / config y habilite la opción UseKeychain:

Host *
UseKeychain yes

Guardar y resuelto.

Este problema ocurrió en mi sistema OS X 10.7.4 cuando ssh-agent murió. Un reinicio solucionó el problema. (Puede intentar reiniciar ssh-agent, pero no sé si Keychain es lo suficientemente inteligente como para elegir el nuevo socket de ssh-agent).

1. Asegúrese de que ~ / .ssh / es chmod 700.

2. Asegúrese de que los archivos ~ / .ssh / id * sean chmod 600.

3. Ejecute / Aplicaciones / Utilidades / Keychain Access.app y repare el llavero.

4. Cerrar sesión. (Reiniciar no sería una idea terrible)

5. Iniciar sesión

6. Si el problema persiste, mueva sus archivos ~ / .ssh / id * existentes a su Escritorio e intente generar nuevas claves usando ssh-keygen -t dsa -f ~/.ssh/id_dsa -C you@youremail.tldy vea si las nuevas claves funcionan mejor.

Estoy en Lion, pero IIRC Snow Leopard funcionó de la misma manera.

ps: cualquier persona que sugiera el uso de una frase de contraseña ssh en blanco debe verse obligado a usar un letrero para que otras personas sepan que no deben seguir sus consejos.

Regenerar la clave pública no parece funcionar para mí (10.8), ni generar una nueva clave SSH. Si, por ejemplo, ejecuto git pull después de bloquear el llavero de inicio de sesión, aparece un cuadro de diálogo para exigir la contraseña de la clave en lugar de intentar primero recuperar la contraseña del llavero de inicio de sesión.

Sin embargo, si primero mato a ssh-agent, se me solicita la contraseña de inicio de sesión del llavero que luego recupera la contraseña de la clave SSH.

Otro hallazgo interesante es que si copia y pega el contenido del archivo PEM, es posible que al final le falte el guión. Así que solo recuerda agregar la línea final como,

-----END RSA PRIVATE KEY-----

Tuve que hacer los siguientes pasos para que funcione.

# Change working directory
cd ~/.ssh
# Remove the old public key
rm id_rsa.pub
# Create a new public key
ssh-keygen -y -f id_rsa > id_rsa.pub
# Change permission
chmod 600 id_rsa*
# Add the key to ssh
ssh-add id_rsa
# Then finally test it (I used github)
ssh -i id_rsa.pub git@github.com

El comando final debería generar algo como: Hi <user>! You've successfully authenticated, but GitHub does not provide shell access.

Yo tuve el mismo problema. Parece que lo solucioné haciendo esto.

1) Realice una copia de seguridad cambiando el nombre a los archivos id_dsa e id_dsa.pub.

2) Ejecutó un nuevo keygen con una frase de contraseña en blanco.

Funciona con el trabajo del período launchctl monitoreando un servidor remoto, así como iniciando sesión desde ssh en una terminal.

Tengo una función rápida authme en mi terminal ya que tengo lo siguiente en mi .bash_profile

#~/.bash_profile    
function authme {
ssh $1 'cat >>.ssh/authorized_keys' <~/.ssh/id_dsa.pub
}

Entonces, un authme rápido remoteserver.com copiará la nueva clave remota.

Creo que el error tiene algo que ver con que la frase de contraseña no se haya convertido (mi viejo Leopardo de las Nieves no tenía ninguna).

Intenta eso y mira si ayuda.

No tardó más de 10 minutos en hacerlo. Pasé googleando para siempre para ver si había alguna otra mención de esto. ¡Este sitio era el único!

Owain

Tuve un problema similar. Resultó que la clave privada que estaba usando estaba en un formato incorrecto. Utilicé PuTTY Key Generator en mi máquina Win y ssh en OS X espera un formato diferente: formato SSH abierto.

Resultó que la herramienta que utilicé para generar esta clave (PuTTY Key Generator) tenía una opción para convertir mi clave privada al formato requerido por Open SSH.

Simple como:

1. Open PuTTY Key Gen
2. Cargue su clave privada
3. Seleccione Conversiones> Exportar clave OpenSSH.

El archivo que guardará contiene su clave privada original en el formato adecuado (OpenSSH).

Por favor asegúrese de que:

1. Estás utilizando el formato pem para tu clave privada. Esto se debe a que Mac usa el cliente openssh que funciona con pem. ppk es el formato propietario de putty y no es compatible con openssh. Puede convertir fácilmente ppk a pem usando putty keygen, en caso de que solo tenga ppk.
2. Los permisos en su archivo pem son 600. Las claves privadas solo deben ser accesibles para su propietario. Por lo tanto, si los permisos dan acceso de lectura a alguien más, se considerará una amenaza para la seguridad.

Con suerte, esto debería resolver el problema.

Use la clave .pem en lugar de la clave .ppk.