que - ssh putty digitalocean
¿Cómo resolver "sign_and_send_pubkey: error de firma: el agente rechazó la operación"? (10)
Después de actualizar Fedora 26 a 28, enfrenté el mismo problema. Y faltaban los siguientes registros
/var/log/secure
/var/log/messages
PROBLEMA:
antop@localmachine ~ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]''s password:
El mensaje de error no señala el problema real. Problema resuelto por
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
Configuración de una nueva gota Digital Ocean con claves SSH.
Cuando ejecuto
ssh-copy-id
esto es lo que obtengo:
ssh-copy-id [email protected]
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]''s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh ''[email protected]''"
and check to make sure that only the key(s) you wanted were added.
Sin embargo, cuando intento ingresar, esto sucede:
ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]''s password:
Al ingresar la contraseña, he iniciado sesión muy bien, pero esto, por supuesto, anula el propósito de crear la clave SSH en primer lugar. Decidí echar un vistazo al lado del servidor ssh-agent y esto es lo que obtengo:
[email protected]:~# eval `ssh-agent -s`
Agent pid 5715
[email protected]:~# ssh-add -l
The agent has no identities.
user / .ssh / Authorized_keys también contiene una entrada de clave ssh-rsa, pero
find -name "keynamehere"
no devuelve nada.
Ejecute
ssh-add
en la máquina del cliente, que agregará la clave SSH al agente.
Confirme con
ssh-add -l
(nuevamente en el cliente) que efectivamente se agregó.
Estaba teniendo el mismo problema en Linux Ubuntu 18 . Después de la actualización de Ubuntu 17.10 , cada comando git mostrará ese mensaje.
La forma de resolverlo es asegurándose de tener el permiso correcto en
id_rsa
e
id_rsa.pub
.
Verifique el número chmod actual usando
stat --format ''%a'' <file>
.
Debe ser
600
para
id_rsa
y
644
para
id_rsa.pub
.
Para cambiar el permiso en los archivos use
chmod 600 id_rsa
chmod 644 id_rsa.pub
Eso resolvió mi problema con la actualización.
Esto debería ser más bien una pregunta de Superusuario.
Bien, tengo exactamente el mismo error dentro de MacOSX SourceTree, sin embargo, dentro de un terminal iTerm2, las cosas funcionan a la perfección.
Sin embargo, el problema parece ser que tengo
dos
ssh-agent
ejecución; (
El primero es
/usr/bin/ssh-agent
(también conocido como MacOSX''s) y luego también HomeBrew instaló
/usr/local/bin/ssh-agent
ejecución.
Al encender un terminal desde SourceTree, me permitió ver las diferencias en
SSH_AUTH_SOCK
, usando
lsof
encontré los dos
ssh-agent
diferentes y luego pude cargar las claves (usando
ssh-add
) en el
ssh-agent
predeterminado del sistema ( es decir,
/usr/bin/ssh-agent
), SourceTree estaba funcionando nuevamente.
Para mí, el problema era copiar / pegar incorrectamente la clave pública en Gitlab. La copia generó una devolución extra. Asegúrese de que lo que pega es una clave de una línea.
Podría haber varias razones para obtener el error SSH:
sign_and_send_pubkey: error de firma: el agente rechazó la operación
Algunos de ellos podrían estar relacionados con los problemas destacados por las otras respuestas (ver las respuestas de este hilo), algunos podrían estar ocultos y, por lo tanto, requerirían una investigación más detallada.
En mi caso, recibo el siguiente mensaje de error:
sign_and_send_pubkey: error de firma: el agente rechazó la operación
[email protected]: Permiso denegado (publickey, gssapi-keyex, gssapi-with-mic)
La única forma de encontrar el problema real era invocar la opción detallada -v que resultó en la impresión de mucha información de depuración:
debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1
Tenga en cuenta que la línea que dice
key_load_public: No such file or directory
hace referencia a la siguiente línea y no a la línea anterior.
Entonces, lo que realmente dice SSH es que no pudo encontrar el archivo de clave pública llamado
id_rsa.website.domain.com-cert
y ese parecía ser el problema en mi caso ya que mi archivo de clave pública no contenía el sufijo
-cert
.
Larga historia corta: la solución en mi caso fue solo asegurarme de que el archivo de clave pública se nombrara como se esperaba. Nunca podría sospechar eso sin depurar la conexión.
La conclusión es USAR EL MODO VERBOSO SSH (opción -v) para descubrir qué está mal, puede haber varias razones, ninguna que se pueda encontrar en este / otro hilo.
Sí. Ejecute ssh-add en la máquina del cliente. Luego repita el comando ssh-copy-id [email protected]
Tuve el error al usar gpg-agent como mi agente ssh y al usar una subclave gpg como mi clave ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .
Sospecho que el problema fue causado por tener una entrada de PIN inválida tty para gpg causada por mi comando sleep + lock utilizado en mi configuración de sway
bindsym $mod+Shift+l exec "sh -c ''gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock''"
o solo el sueño / suspender
Restablezca la entrada de pin tty para solucionar el problema
gpg-connect-agent updatestartuptty /bye > /dev/null
y la solución para mi comando sway sleep + lock:
bindsym $mod+Shift+l exec "sh -c ''gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null''"
sign_and_send_pubkey: signing failed: agent refused operation
un
sign_and_send_pubkey: signing failed: agent refused operation
error de
sign_and_send_pubkey: signing failed: agent refused operation
.
Pero en mi caso, el problema era un camino de
pinentry
incorrecto.
En mi
${HOME}/.gnupg/gpg-agent.conf
la
pinentry-program
apuntaba a una ruta de pinentry antigua.
Corregir la ruta allí y reiniciar el
gpg-agent
me lo arregló.
Lo descubrí siguiendo los registros con
journalctl -f
.
Allí donde las líneas de registro como las siguientes contienen la ruta incorrecta:
Jul 02 08:37:50 my-host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-host gpg-agent[12677]: can''t connect to the PIN entry module ''/usr/local/bin/pinentry'': IPC connect call failed
A este error:
# git pull
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Verifique o agregue nuevamente la clave pública en la cuenta de Github> perfil> ssh.
Resolví así:
# chmod 400 ~/.ssh/id_rsa
# ls ~/.ssh/id_rsa -ls
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26 2017 /home/reinaldo/.ssh/id_rsa
# git pull
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.
Gracias.