Estoy leyendoEste artículosobre cómo configurar copias de seguridad desatendidas en Duplicity.
Estoy en la parte llamada 7.2. Almacenamiento en caché de claves SSH
Agregué lo siguiente a mi raíz.bash_profile
keychain --clear id_rsa
. /root/.keychain/www-sh
El artículoindica que el llavero debería iniciarse y que en este momento se me debería solicitar mi CONTRASEÑA para mi clave privada (/root/.ssh/id_rsa).
No obtengo los resultados esperados aquí, aunque el llavero se inicia, arroja algunas advertencias en este punto:
KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL
* Found existing ssh-agent (2014)
* ssh-agent: All identities removed.
* Warning: /root/.ssh/id_rsa.pub missing; can't tell if /root/.ssh/id_rsa is loaded
root@www:~#
He encontrado alguna mención de esto en elForos de Gentoopero los usuarios del hilo parecen estar desconcertados en cuanto a por qué el llavero solicita la clave pública id_rsa.puby me preguntaba si alguien sabía por qué el llavero solicitaría la clave pública.
Respuesta1
Admito libremente que no tengo conocimiento del funcionamiento interno del llavero, pero es completamente razonable que un agente ssh local esté molesto por no tener una clave pública que corresponda a una clave privada que sí tiene.
Considere lo que sucede cuando se acerca a un servidor remoto para autenticarse. El servidor remoto sabe, por su authorized_keysarchivo, que está preparado para aceptar un cliente que pueda demostrar que tiene la clave privada correspondiente a cada entrada del mismo. ¿Pero cómo le pide eso al cliente? No puede dar cada clave privada, ni ninguna propiedad de la misma, porque no la tiene; todo lo que puede hacer es presentar la(s) clave(s) pública(s), o sus huellas digitales, que aceptará.
Si el cliente tiene alguna de esas claves públicas, puede seleccionar inmediatamente la clave privada correspondiente y dar una respuesta que el servidor aceptará como correcta. Si no tiene esas claves públicas, ¿qué debe hacer? ¿Probar cada clave privada de su repertorio por turno? Difícilmente podría imaginarse una receta mejor para la divulgación de información insegura; un sombrero negro sólo tendría que configurar un ataque de intermediario en una única conexión nueva para recolectar respuestas legítimas de cada clave de su conjunto de claves.
Es posible que los pares de claves tengan algún tipo de numeración interna, pero sería completamente arbitrario e imprudente confiar en ello. No hay una propiedad interna garantizada que vincule una clave pública y privada, porque las claves en un par de claves no comparten nada, salvo que una es (con suerte) la única entidad que puede deshacer lo que hace la otra.
No, la mejor manera para que el cliente seleccione la clave privada correcta para usar en cualquier servidor determinado es tener las claves públicas coincidentes para ayudarlo en la selección de claves.
Respuesta2
Creo que keychainestá intentando ser más seguro que el programa del que sirve ( ssh).
A partir de mi versión actual de OpenSSH, es posible agregar una clave privada ssh-agentsin ssh-addtener el archivo de clave pública. Después de hacer esto, podrá ver si tuvo éxito, ya que ssh-add -ltambién mostrará el nombre del archivo de clave privada. sshutilizará la clave almacenada en caché para conectarse, incluso si hay más de una identidad disponible. Probarlos por turno se menciona explícitamente en la documentación.
$ ssh -V
OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016
$ man ssh_config
...
IdentityFile
...
It is possible to have multiple identity files speci‐
fied in configuration files; all these identities
will be tried in sequence. Multiple IdentityFile
directives will add to the list of identities tried
(this behaviour differs from that of other configura‐
tion directives).
...
Creo que lo mejor es usar la AddKeysToAgentopción de ssh. Le pedirá la frase de contraseña sólo la primera vez en su sesión, si la tiene ssh-agentdisponible. En tu .bashrcpuedes agregar soloeval $(keychain --eval --noask)