Bitwarden ha integrado un agente SSH en su aplicación de escritorio, permitiendo a los usuarios almacenar y gestionar claves Secure Shell (SSH) directamente dentro de una bóveda cifrada. Este cambio permite a los desarrolladores y administradores de sistemas alejarse del almacenamiento de claves privadas en archivos locales, gestionándolas en su lugar a través de un gestor de contraseñas centralizado que maneja la autenticación para servidores, commits de Git y otros servicios basados en SSH.
Esta imagen ilustra el paso inicial para habilitar el almacenamiento SSH dentro de la aplicación de escritorio de Bitwarden.
Estado de la bóveda y lógica de autorización
El comportamiento del agente SSH de Bitwarden está regido directamente por el estado de la bóveda del usuario. Cuando la bóveda está cerrada o bloqueada (antes del desbloqueo inicial), el agente no listará ni firmará solicitudes.
Una vez que la bóveda se desbloquea, el agente se activa. Los usuarios pueden elegir si la aplicación debe aprobar automáticamente las solicitudes o requerir una autorización manual. Si la autorización está habilitada, Bitwarden solicita al usuario que apruebe cada solicitud específica para usar una clave SSH, asegurando que los procesos en segundo plano o los servidores remotos no puedan usar una clave sin un consentimiento explícito.
“El reenvío de agente SSH permite que un servidor remoto al que estás accediendo se autentique en otros servidores utilizando tus claves, sin exponer tus claves privadas fuera de tu bóveda.”
— Bitwarden SSH Agent | Bitwarden
Configuración del sistema e integración
Para utilizar Bitwarden como el agente SSH principal, los usuarios deben configurar su sistema operativo para enrutar las solicitudes SSH al socket de Bitwarden. En Windows, esto implica desactivar el servicio nativo OpenSSH Authentication Agent.
Esta imagen demuestra el panel de Servicios de Windows donde los usuarios deben desactivar el agente nativo.
Gráfico elaborado por HN Digest a partir de las cifras reportadas por bitwarden.com; los valores se muestran tal como aparecen en la fuente.
En macOS y Linux, los usuarios deben establecer la variable de entorno SSH_AUTH_SOCK para que apunte al socket específico creado por la aplicación de escritorio de Bitwarden. Por ejemplo, un usuario de macOS podría añadir un comando a su archivo .zshrc o .bashrc para asegurar que la variable persista a través de las sesiones de la terminal.
Una vez configurado, herramientas estándar como ssh-add -L o git pueden comunicarse con Bitwarden para la autenticación, permitiendo un flujo de trabajo fluido a través de diferentes entornos de desarrollo.
Reenvío de agente SSH y compensaciones de seguridad
La integración es compatible con el reenvío de agente SSH, lo que permite que un servidor remoto se autentique en un segundo servidor utilizando las claves locales del usuario. Debido a que las claves permanecen dentro de la bóveda de Bitwarden, las claves privadas nunca se exponen realmente al servidor intermedio; el servidor simplemente solicita a la instancia local de Bitwarden que realice la autenticación.
Si bien esto mejora la conveniencia al eliminar la necesidad de mover manualmente las claves entre máquinas, introduce una compensación entre la facilidad de uso y la seguridad. Los usuarios pueden mitigar los riesgos del reenvío de agentes utilizando la función 'Pedir autorización', que garantiza que cualquier solicitud de un servidor remoto para usar una clave local debe ser aprobada manualmente por el usuario.
Esta captura de pantalla muestra la función 'Pedir autorización' utilizada para mitigar los riesgos asociados con el reenvío de agentes.
Qué dicen los lectores de Hacker News
- Escéptico: Varios comentaristas expresaron escepticismo sobre la gravedad del informe, señalando que la solicitud de extracción (pull request) pertinente fue cerrada sin ser fusionada y que la función se describe como opcional. comentario ↗
- Alternativa: Un comentarista sugirió usar un enclave seguro en macOS para gestionar claves SSH, lo que requeriría una huella digital para cada nueva sesión para asegurar que el usuario sea consciente de cada conexión. comentario ↗
- Alternativa: Otros recomendaron el uso de una llave de seguridad de hardware, como una Yubikey, configurada para requerir un toque físico para confirmar cada operación de autenticación. comentario ↗
- Escéptico: Un comentarista argumentó que el problema es un fallo de diseño fundamental en cómo funcionan los agentes SSH, señalando que estas herramientas están destinadas a facilitar infraestructuras seguras como los hosts de salto (jump hosts). comentario ↗
Resumen de opiniones del hilo de Hacker News; no son hechos verificados. Leer el debate completo ↗