Escenario
Dos sitios de trabajo, el sitio 1 y el sitio 2. Dos servidores Linux, el servidor A y el servidor B. Se puede acceder al servidor A desde ambos sitios, mientras que al servidor B solo se puede acceder desde el sitio 1. Dos estaciones de trabajo Windows, una en el sitio 1 y la otra en el sitio 2.
Estoy en Windows en el sitio 1, usando PuTTY para conectarse al servidor A que está configurado solo para autenticación ssh pública.
Uso gpg-agent con la configuración enable-putty-support
activada en lugar de pageant para usar una tarjeta inteligente para la autenticación de git en $popular_git_site
.
La mayoría de las veces, en el sitio 1, necesito conectarme de forma remota al servidor B utilizando el Cliente NX de NoMachine v3.5.x. A partir de ahí, necesito poder hacer un ssh en el servidor A usando la autenticación pública también. Dado que el servidor B ejecuta NX Server v3.5.x, el reenvío de agentes no funciona con el cliente NX. Por lo tanto, con la tarjeta inteligente no disponible, tengo que asegurarme de tener una clave privada disponible en el servidor B.
Por lo tanto, creé un par de claves RSH ssh protegido con contraseña en el servidor B usando
ssh-keygen -t rsa
La contraseña es verylongandcomplicatedpassword
. Por lo tanto, no quiero escribir mucho.
Agregué la clave pública .ssh/id_rsa.pub
a .ssh/authorized_keys
en el servidor A, así como en el servidor B. El uso de ssh desde el servidor B al servidor A ahora funciona. Viceversa también funciona ahora.
Problema
En Windows en el sitio 1 tengo una configuración de conexión PuTTY para el servidor B mediante el reenvío de agentes para mi tarjeta inteligente para poder usar git en el servidor B y autenticar con mi tarjeta inteligente.
Quiero lo mismo para el servidor A, porque el servidor B es inalcanzable desde el sitio 2, donde a veces también trabajo. gpg-agent
se inicia como un elemento de inicio con gpg-connect-agent /bye
y se ejecuta en Windows.
Por lo tanto, yo scp
'd la clave privada .ssh/id_rsa
del servidor B en mi máquina Windows. Lo abrí con éxito con PuTTYgen y lo guardé en formato PuTTY en C:\Users\name\ssh\id_rsa.ppk
.
Creé una nueva conexión PuTTY al servidor A, tipo de conexión SSH
.
Connection --> SSH --> Auth -->
[Check] Attempt Authentication using Pageant
[Uncheck] Attempt "keyboard-interactive" auth
[Check] Allow agent forwarding
Private Key File for Authentication: C:\Users\name\ssh\id_rsa.ppk
Este tipo de obras. Sin embargo, el mismo PuTTY, no gpg-agent
, me solicita la contraseña verylongandcomplicatedpassword
- cada vez que ! El reenvío del agente tampoco funciona, ya que no puedo pasar del servidor A al servidor B sin volver a escribir mi contraseña después de iniciar sesión correctamente desde PuTTY.
Creo que PuTTY no puede agregar la clave a gpg-agent
o comunicarse con ella correctamente a pesar de que enable-putty-support
esté activado en la configuración gpg-agent
y gpg-agent
trabajando como un campeón para git y agente forwaring trabajando para git en el servidor B en el sitio 1.
Lo que probé
Pensando que soy extremadamente inteligente, comencé a estudiar cómo convertir mi .ssh/id_rsa
a un formato que pueda usar en gpg2 para gpg-agent
. Esta búsqueda de Google arrojó principalmente resultados de mierda.
Lo mejor de eso, porque en realidad menciona una forma de convertir la clave, es aquí .
OpenSSH to GnuPG S / MIME
Primero debemos crear un certificado (autofirmado) para nuestra clave ssh:
openssl req -new -x509 -key ~/.ssh/id_rsa -out ssh-cert.pem
Ahora podemos importarlo en GnuPG
openssl pkcs12 -export -in ssh-certs.pem -inkey ~/.ssh/id_rsa -out ssh-key.p12 gpgsm --import ssh-key.p12
Note que no puede importar / exportar claves DSA ssh a / desde GnuPG
Dicho y hecho. Observe el error obvio en el segundo comando (ssh-cert s .pem vs ssh-cert.pem). Hice todos los comandos openssl
en el servidor B, luego copié el archivo ssh-key.p12
a Windows y lo importé a gpg. Puedo ver la clave como X.509 en Kleopatra, una interfaz gráfica para gpg en Windows.
Sin embargo, a pesar de esto, nada cambió y nada parece funcionar. He intentado con la configuración original de PuTTY anterior. El comportamiento no ha cambiado.
Dejando el campo Private Key File for Authentication
vacío, recibo el mensaje habitual:
Error fatal de PuTTY Desconectado: no hay métodos de autenticación compatibles disponibles (servidor enviado: publickey)
No sé por qué esto no funciona. ¿GnuPG S / MIME o X.509 no es lo que necesito? También intenté convertir el .ssh/id_rsa.pub
, pensando que podría tratarse de un problema de clave pública, pero openssl
se queja de que solo quiere convertir claves privadas.
Lo que no necesito
Sugerencias de respuestas
- Soy estúpido por querer esto
- nadie nunca tendría que querer hacer esto
- si no me gusta cómo funciona ssh / gpg / PuTTY, puedo codificar el mío
- man gpg, man ssh, man ssh_config