Cómo funciona el SSH sin contraseñas con EZSSH y Entra ID
EZSSH usa certificados SSH para crear claves de acceso de vida corta firmadas por nuestra autoridad de certificación respaldada por HSM. Dan acceso puntual a su recurso y a la vez dejan un registro de auditoría que se puede rastrear hasta el usuario y sus acciones.
Cómo funciona el SSH sin contraseñas
Cada conexión empieza con su identidad corporativa y termina con un certificado que expira solo. Sin agentes ni llaves SSH de larga duración.
Un usuario pide una conexión SSH
El usuario empieza con la CLI ezssh, inicia sesión con su cuenta de Entra ID e indica a qué recurso quiere conectarse.
EZSSH evalúa la solicitud
EZSSH comprueba el acceso del usuario al endpoint solicitado y el flujo de aprobación correspondiente.
Se solicita un certificado SSH
Se genera de forma segura un par de claves en la máquina del usuario, y solo se envía la clave pública a EZSSH para que la firme.
La CA en el HSM firma la solicitud
La CA de EZSSH respaldada por HSM firma la solicitud, de modo que el certificado es de confianza y no se puede manipular.
El usuario se autentica con su certificado SSH
El usuario presenta su certificado SSH firmado para autenticarse contra el recurso solicitado, usando la compatibilidad nativa de la plataforma con certificados SSH. Sin agentes.
El certificado SSH expira solo
Cuando termina su periodo de validez, el certificado expira automáticamente y ya no sirve para autenticarse. Hay que pedir uno nuevo para volver a acceder al endpoint.
Protocolos y detalles técnicos
Autenticación y emisión
Protección de las claves
Acceso y despliegue
Proteja sus endpoints SSH en minutos
Empiece hoy una prueba gratuita, o hable con uno de nuestros expertos en identidad sobre cómo EZSSH puede bajar su costo de TI y a la vez mejorar la productividad y la seguridad de sus usuarios.
Precios transparentes
Ver los detalles de preciosStartup
Gestión de acceso a servidores y a GitHub para hasta 100 endpoints
Premium
El más popular ✦CA respaldadas por HSM con FIPS 140-3, endpoints ilimitados y exportación al SIEM
Business Critical
Respuesta de soporte en una hora y un año de retención de registros
Preguntas frecuentes
EZSSH usa certificados SSH para crear claves de acceso de vida corta firmadas por nuestra autoridad de certificación respaldada por HSM. Dan acceso puntual a su recurso y a la vez dejan un registro de auditoría que se puede rastrear hasta el usuario y sus acciones.
Sí. Cada política dentro de la cuenta de cada cliente tiene su propia autoridad de certificación respaldada por HSM, lo que crea un perímetro de identidad limitado a esa política de acceso. También existe la opción de usar su propia CA: aporte su Azure Key Vault, dé a EZSSH permisos de creación y firma, y usted sigue controlando sus claves privadas y cómo se usan.
No. Usar un certificado de vida corta suena a mucho trabajo, pero el usuario no se entera de nada. Escribe el comando y todo lo demás ocurre por detrás. Lo único que sabe es que tiene una forma segura de conectarse a su infraestructura.
No. Como EZSSH usa certificados SSH nativos, la mayoría de las distribuciones de Linux pueden confiar en una autoridad de certificación concreta y aceptar sus certificados sin cambios constantes. Una vez que confían en ella, se concede acceso a cualquier certificado que cumpla los requisitos que fijó el administrador, así que nunca ejecuta un agente con muchos privilegios ni código de terceros en sus servidores.
El cliente de EZSSH crea una llave SSH nueva en la computadora del usuario y la clave privada nunca sale de ahí. Solo se envía la clave pública a EZSSH para firmarla, y el certificado se borra de la computadora del usuario cuando expira.
Sí. El servicio de EZSSH comprueba el acceso del usuario al endpoint que pidió y aplica el flujo de aprobación correspondiente. Un usuario puede quedar aprobado automáticamente, necesitar una aprobación de doble llave de otro usuario, o ser denegado automáticamente.
El responsable del recurso crea una política de EZSSH y EZSSH genera una clave protegida por HSM única para ella. Esa clave se añade después como CA de confianza en sus servidores, automáticamente si los recursos están en Azure, o ejecutando los scripts que EZSSH generó para la política.