¿Cómo proteger SSH para que varios usuarios puedan iniciar sesión en una cuenta?

Sí, puede tener varias claves que pueden iniciar sesión en una cuenta. Esta es una configuración común entre los usuarios que tienen múltiples máquinas de confianza y mantienen una clave privada separada en cada una.

Esta también es una configuración razonable para una cuenta de servicio que solo está destinada a acceder a una aplicación. En esta situación, generalmente se combina con un shell de inicio de sesión restringido o para propósitos especiales que solo permite el acceso a esa aplicación específica. Por ejemplo, gitosis es una puerta de entrada al sistema de control de versiones de Git, y maneja la autenticación del usuario por sí misma, manteniéndose en una unión git cuenta a nivel de unix. Si varias personas pueden ejecutar comandos arbitrarios a través de esta cuenta, realmente debería darles diferentes cuentas de Unix.

Haga que los usuarios le envíen una clave pública y concatene las claves públicas para formar el archivo ~/.ssh/authorized_keys , o agregue de manera equivalente cada clave pública a partir de un archivo vacío.

Puede poner restricciones en las propias claves en authorized_keys file . Por ejemplo, ssh-rsa AAAA… [email protected] declara una clave sin restricciones, mientras que un usuario que inicia sesión con la siguiente clave solo puede iniciar sesión desde una subred IP específica, no puede reenviar puertos y solo puede ejecutar un comando específico:

command="/usr/local/bin/restricted-app",from="192.0.2.0/24",no-agent-forwarding,no-port-forwarding,no-x11-forwarding ssh-rsa AAAA… [email protected]

Si confía en las restricciones de comandos, tenga cuidado de que el comando no permita ninguna forma indirecta de obtener un shell o editar archivos en el directorio .ssh o en cualquier otra ubicación confidencial. Puede hacer que el directorio principal de la cuenta, el directorio ~/.ssh y su contenido sean propiedad de la raíz y estén accesibles para que el usuario pueda leerlos, lo que evitaría la escalada de privilegios en caso de que la aplicación restringida tenga una vulnerabilidad de sobrescritura de archivos pero no una vulnerabilidad de escape de shell.

Establezca LogLevel VERBOSE (un paso adelante del nivel predeterminado INFO ) en la configuración del servidor ( sshd_config ) para registrar qué clave se usó para iniciar sesión en la cuenta cada vez.

¿Ha considerado hacer solo 3 usuarios y colocarlos en un grupo que solo puede ejecutar esa acción en particular? Esto aumentará su capacidad de rastreo. Este es realmente el motivo por el cual los usuarios y grupos están disponibles en un sistema operativo.

Si por alguna razón eso no es posible, aún puede permitir que inicien sesión (y no HACER NADA más) y su para un usuario en particular.

También hay otros sistemas como PowerBroker que brindan un shell adicional que registra todos los movimientos de comando, pero para su caso de uso es probablemente una exageración masiva.

Es fácil permitir que varias claves accedan a una cuenta determinada: simplemente coloque todas las claves públicas , una después de la otra, en el archivo .ssh/authorized_keys de la cuenta de destino. Cualquier usuario que controle una de las claves privadas correspondientes podrá abrir una conexión a esa cuenta.

Idealmente, no genere las claves usted mismo; haga que cada usuario genere su propio par de claves (con ssh-keygen ) y le envíe el .ssh/id_dsa.pub o .ssh/id_rsa.pub resultante (según el tipo de clave que generaron). Luego, pegue el contenido del archivo .pub en el .ssh/authorized_keys (estos son archivos de texto).

Para restringir lo que estos usuarios pueden hacer con la cuenta, vea la respuesta de @Gilles (esa es una pregunta importante, pero ortogonal).