octubre 24, 2020
Articles
No hay comentarios

El servidor dropbear ssh no ' me dejó conectar

Estoy tratando de obtener acceso ssh a mi enrutador. Actualmente solo tengo acceso telnet e instalé dropbear y se está ejecutando (usando opkg en una unidad USB conectada al enrutador).

Desde el principio, lo que hice fue generar una clave privada y descifrarla (desde dropbear no admite esto todavía) y la pública: 

cd .ssh openssl genrsa -des3 -out id_rsa openssl rsa -in id_rsa -out id_rsa ssh-keygen -y -f id_rsa > authorized_keys

Subí la clave pública (authorized_keys ) a /root/.ssh. Puse el archivo en un servidor Apache (en mi computadora local) y lo descargué en el enrutador usando wget (para que el archivo descargado obtenga root como propietario / grupo) y luego cambié los permisos a 0600 (lo mismo para el cliente pero con mi usuario ).

Cuando intento acceder, aparece un error de «Permiso denegado (clave pública)»: 

$ ssh -v -i ~/.ssh/id_rsa [email protected] OpenSSH_7.4p1, OpenSSL 1.0.2j 26 Sep 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/chazy/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/chazy/.ssh/id_rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4 debug1: Remote protocol version 2.0, remote software version dropbear debug1: no match: dropbear debug1: Authenticating to 192.168.1.1:22 as "root" debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: [email protected] debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:1EFA75uwLp+4hBW0t3aaY05QjLzYd4jjDWoULAzF/8o debug1: Host "192.168.1.1" is known and matches the RSA host key. debug1: Found key in /home/chazy/.ssh/known_hosts:1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/chazy/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey).

A menos que yo » Leí mal lo que dice la documentación ( repositorio de GitHub ):

Auth de clave pública del servidor :

Puede usar ~ / .ssh / authorized_keys de la misma manera que con OpenSSH, simplemente coloque las entradas de clave en ese archivo. Deben tener el formato:

ssh- RSA AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV + ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk / yU99UVv6NWV / 5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET / MG8qyskG / 2IE2DPNIaJ3Wy + = Ws4IZEgdJgPlTYUBWWtCWOGc alguien @ hostname

debe asegurarse de que ~ / .ssh, y el archivo de claves, sólo pueden ser escritos por el usuario. Cuidado con los editores que partió la llave en varias líneas.

Dropbear admite algunas opciones para entradas de claves_autorizadas, consulte la página de manual.

Hice todo lo que dice, así que no sé dónde podría estar el problema.

La documentación menciona otra forma:

Autenticación de clave pública del cliente:

Dropbear puede realizar la autenticación de clave pública como cliente, pero tendrá que convertir las claves de estilo OpenSSH al formato Dropbear, o usar dropbearkey para crearlas.

Si tiene una clave privada de estilo OpenSSH ~ / .ssh / id_rsa, debe hacer:

dropbearconvert openssh dropbear ~ / .ssh / id_rsa ~ / .ssh / id_rsa.db dbclient -i ~ / .ssh / id_rsa.db

Dropbear no admite claves de host cifradas, aunque puede conectarse a ssh-agent.

Entonces, esto indica que si convierto la clave privada en un dropbear clave privada, puedo usar el cliente dropbear para conectarme al servidor dropbear: 

dropbearconvert openssh dropbear id_rsa id_rsa.db

Voy a intentarlo y ver si funciona. Pero de todos modos, la autenticación de la clave pública del servidor debería funcionar.

Comentarios

  • ¿El servidor / config dropbear ssh permite el inicio de sesión de root? De forma predeterminada en varios servidores ssh, el inicio de sesión de root no está permitido por seguridad.
  • Creo que sí, no ‘ no veo ningún archivo de configuración en opt/etc/dropbear (solo las claves del host), y el parámetro para no permitirlo es -w (sin usarlo).
  • Pregunta editada: siguió los pasos para convertir la clave ssh en un dropbear clave y nada (como lo señaló Ipor Sircer en la primera respuesta).
  • Se encontró documentación en el repositorio de github (no se puede ‘ informar allí, los problemas no están habilitados) . Pregunta editada de nuevo. El mismo problema todavía 🙁

Respuesta

Respuesta corta: Probablemente esté ejecutando OpenWrt, y necesita poner su clave pública en /etc/dropbear/authorized_keys en lugar de /root/.ssh/authorized_keys.

Respuesta larga:

El GitHub El repositorio al que apunta es el que mantiene el autor de dropbear; dice que ~/.ssh/authorized_keys funciona, y según GitHub lo ha hecho al menos durante 14 años. Mirando el código en svr-authpubkey.c agrega /.ssh/authorized_keys al «pw_dir».

Yo, sin embargo , tuve el mismo problema que tú, y descubrí que el binario proporcionado en OpenWrt 18.06.1 en realidad está abriendo /etc/dropbear/authorized_keys. Usar ese archivo me funciona .

Este comportamiento está documentado en los documentos de OpenWrt .

Entonces, ¿por qué?

Dado que el código anterior no puede producir ese nombre de archivo por sí solo (falta .ssh) y no hay .ssh enlace simbólico en ninguna parte, ejecuté strings en el binario. Eso mostró que /etc/dropbear/authorized_keys se menciona explícitamente, justo antes del %s/.ssh/authorized_keys que se puede esperar del código de GitHub. Concluyo que el binario de OpenWrt no está compilado de las mismas fuentes … y de hecho, OpenWrt parchea el código ascendente con este parche . Cambia el archivo usado a /etc/dropbear/authorized_keys si (y solo si) el usuario de destino es root.

Ya que mencionas opkg, imagino que también estás usando OpenWrt, y que este es tu problema. He agregado una etiqueta OpenWrt a su pregunta.

Respuesta

authorized_keys es un archivo, no un directorio.

Un ejemplo de archivo de claves_autorizadas: 

 # Comments allowed at start of line ssh-rsa AAAAB3Nza...LiPk== [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected]

http://man.he.net/man5/authorized_keys

También el .ssh/ y todos los archivos en él deben ser propiedad y ser legibles solo por el usuario, en este caso root.

Comentarios

  • Acabo de arreglar eso pero aún no tuve suerte 🙁 (ver pregunta actualizada).

Respuesta

man dropbearkeys: 

NOTES The program dropbearconvert(1) can be used to convert between Dropbear and OpenSSH key formats. Dropbear does not support encrypted keys. EXAMPLE generate a host-key: # dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key extract a public key suitable for authorized_keys from private key: # dropbearkey -y -f id_rsa | grep "^ssh-rsa " >> authorized_keys

Comentarios

  • Logré convertir la clave privada, pero aún así no tuve suerte 🙁 (ver pregunta actualizada).

Respuesta

Debe crear la clave ssh usando la herramienta dropbearkey. RSA_KEYFILE = / etc / dropbear / dropbear_rsa_host_key DSS_KEYFILE = / etc / dropbear / dropbear_dss_host_key

dropbearkey -t dss -f $ DSS_KEYFILE

dropbearkey -t rsa -f $ RSA_KEYFILE

Luego reinicie el demonio dropbear. Luego intente conectarse, debería funcionar.

Respuesta

Algunos consejos que pueden ayudarlo a conectarse usando PKI con Dropbear, esto probó un contenedor basado en paquetes Alpine Linux 3.12, conectándose desde un cliente OpenSSH.

  1. El usuario necesita un shell.
  2. El usuario no necesita una contraseña de inicio de sesión.
  3. El usuario «s ~ no debe ser escribible en grupo / mundo (es decir chmod 755 eso, al menos; debería usar 700 para los directorios de inicio).
  4. El usuario «s ~/.ssh y ~/.ssh/authorized_keys debe ser accesible solo para el propietario (p. Ej., 700 en el directorio y 600 en el archivo).
  5. Allí debe ser un /tmp directorio de escritura
  6. Las entradas authorized_keys tienen el mismo formato que se usa por OpenSSH.

Estoy creando contenedores usando archivos seleccionados de paquetes alpine; Tengo una imagen de ~ 2 MB a la que puedo acceder mediante SSH siempre que se cumplan todos los requisitos anteriores.

Respuesta

I me encontré con esta pregunta mientras buscaba razones por las que la conexión a través de dropbear a mi servidor dejó de funcionar de repente (ha estado funcionando durante meses, pero solo se usa ocasionalmente cada dos semanas).

la solución / explicación i finalmente se encontró en el mensaje debug1: send_pubkey_test: no mutual signature algorithm con mayor nivel de detalle en el intento de conexión ssh de mis clientes, lo que me llevó a un artículo de solución de problemas de bitbucket .

Ese artículo menciona El algoritmo RSA está siendo rápidamente obsoleto en todos los sistemas operativos y clientes SSH debido a varias vulnerabilidades de seguridad […] como causa y enumera como posibles soluciones ya sea:

  • agregando PubkeyAcceptedKeyTypes +ssh-rsa al archivo cfg del cliente (solo use esto como solución temporal ya que es potente ¡ncionalmente inseguro!)

  • use el algoritmo / claves ECDSA o ED25519. ahora, con la versión dropbear presente en mi sistema, pude solo usar ECDSA ya que ED25519 me dio errores de algoritmo desconocido en el lado de dropbears.

Espero que esto ayude a alguien a tropezar con esta pregunta, como lo hice yo, aunque probablemente no sea una solución a la pregunta original, por favor. perdonar.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *