El diálogo de contraseña aparece cuando los permisos de la clave privada SSH están configurados en 0600

Asegúrese de tener un id_rsa.pub o id_dsa.pub correspondiente en su directorio ~/.ssh .

Cuando tenía un id_rsa pero no un id_rsa.pub correspondiente, Mac OS X seguía apareciendo en el diálogo y recuerda que la contraseña de 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ías tu archivo público allí (cambia su nombre a otro nombre) y generas la clave pública nuevamente con el comando anterior, notarás que el generado y el anterior no son iguales. De alguna manera, las versiones anteriores de Mac OS X generaron una clave pública que a Lion ya no le gusta, generándola de nuevo lo arregla.

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, ejecuta ssh-add -K y verifica si esto soluciona tu problema.

Si no:

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

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

• Los permisos asegurados se establecieron en 600 tanto para id_rsa como para 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 me pidieron que proporcione la contraseña de mi clave privada. Esto parece colocar realmente la contraseña de la clave privada en la ubicación correcta del llavero para que la use OS X.

En mi caso ssh-add -K no hizo el truco, tuve que especificar la clave:

ssh-add ~/.ssh/id_rsa

Para macOS 10.12, Sierra ssh-add -K debe ejecutarse después de cada reinicio. Para evitar esto, cree ~/.ssh/config con 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 solicitando su contraseña y le ofrecería la opción de almacenarla en el llavero. Esta interfaz de usuario fue obsoleta hace algún tiempo y se ha eliminado.

Editar: Aparentemente, no es necesario especificar un host y una clave. Solo agregando 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 de manera predeterminada.

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, solicite el ssh para la frase de contraseña, desactive la variable de entorno SSH_AUTH_SOCK.

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

Si desea usar 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 todas las veces: 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 una 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 en blanco la nueva frase de contraseña. Existe un riesgo de seguridad al tener una frase de contraseña vacía: cualquier persona que pueda acceder a su archivo de clave privada (por ejemplo, accediendo a sus copias de seguridad) puede usarlo al instante.

si ha agregado su clave privada al directorio de origen ~ / .ssh, y ha ingresado a ssh-add -K para agregarla al llavero, y ha copiado los contenidos de su clave pública a .ssh / authorized_keys ( para la cuenta correcta) 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 acerca de 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 una contraseña, el cliente primero pasa 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 con 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. Solo edita tu ~ / .ssh / config y habilita la opción UseKeychain:

Host *
UseKeychain yes

Guarda y resuelve.

Este problema ocurrió en mi sistema OS X 10.7.4 cuando murió ssh-agent. Un reinicio solucionado el problema. (Podría intentar reiniciar ssh-agent, pero no sé si el Llavero es lo suficientemente inteligente como para tomar el nuevo zócalo de ssh-agent).

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

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

3. Ejecutar / Aplicaciones / Utilidades / Keychain Access.app y reparar llavero.

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

5. Login

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 [email protected] y vea si las nuevas claves funcionan mejor.

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

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

La regeneración de la clave pública no parece funcionar para mí (10.8), ni tampoco genera una nueva clave SSH. Si, por ejemplo, ejecuto git pull después de bloquear el llavero de inicio de sesión, aparecerá un cuadro de diálogo para solicitar la contraseña de la clave en lugar de intentar 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 del llavero de inicio de sesión que luego recupera la contraseña de la clave SSH.

Otro hallazgo interesante es si copia & pegue el contenido del archivo PEM, puede que al final le falte el guión. Así que recuerde 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 [email protected]

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

Tuve el mismo problema. Parece que lo he arreglado al hacer esto.

1) Copia de seguridad cambiando el nombre a los archivos id_dsa e id_dsa.pub antiguos.

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

Funciona con el trabajo del período launchctl que supervisa un servidor remoto, así como el inicio de sesión desde ssh en un terminal.

Tengo una función de autenticación rápida 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
}

Por lo tanto, una rápida autenticación remoteserver.com copiará la nueva clave remota.

Creo que el error tiene que ver con que la frase de contraseña no se haya convertido (mi antiguo Snow Leopard no tenía ninguna)

Intenta eso y ve si ayuda.

No tardó más de 10 minutos en hacerlo. Pasé a Google para siempre para ver si había alguna otra mención de esto. ¡Este sitio fue 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: abrir formato SSH.

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. Seleccionar 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á utilizando el formato pem para su 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 ppk a pem fácilmente 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 otorgan acceso de lectura a cualquier otra persona, se considerará una amenaza para la seguridad.

Esto debería resolver el problema.

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