14 votos

Linux ssh: permitir la clave pública de autenticación sin dar de usuario derechos de lectura de la clave privada

Los usuarios que hayan iniciado sesión en mi servidor Linux debe ser capaz de ssh a una determinada máquina remota con una cuenta predeterminada. La autenticación en la máquina remota utiliza la clave pública, por lo que en el servidor de la clave privada correspondiente está disponible.

No quiero que el servidor que los usuarios realmente ser capaz de leer la clave privada. Básicamente, el hecho de que tienen acceso al servidor permite la ssh a la derecha, y la eliminación de ellos desde el servidor también debe denegar la conexión a la máquina remota.

¿Cómo puedo permiten a los usuarios abrir una conexión ssh sin darles acceso de lectura a la clave privada?

Mis pensamientos hasta el momento: obviamente, el ssh ejecutable debe ser capaz de leer la clave privada, por lo que se debe ejecutar en el marco de otro usuario en el servidor que tiene los derechos. Una vez que la conexión ssh se establece, entonces puede "seguir" a los usuarios de modo que se pueden introducir los comandos e interactuar con la máquina remota.

  • Es este un buen enfoque?
  • ¿Cómo debo aplicar el futuro?
  • ¿Cómo puede el usuario iniciar la conexión (es decir, la ejecución de la ssh del usuario que tiene derechos de lectura de la llave)?
  • Hay una brecha de seguridad? - si los usuarios pueden ejecutar ssh como otro usuario, pueden hacer todo lo que otro usuario podría (incluyendo la lectura de la clave privada)?

31voto

HBruijn Puntos 16577

Que es una de las razones sudo existe. Simplemente permiten a los usuarios ejecutar 1 solo comando con sólo el pre-autorizado opciones de línea de comandos y la más obvia de elusión se resuelven. por ejemplo,

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

configura sudo para todos los miembros del grupo users puede ejecutar el comando ssh como usuario some_uid sin entrar en su propia contraseña (o de la some_uid cuenta) cuando se ejecute:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

Quitar el NOPASSWD: opción para forzar a que los usuarios introduzcan su contraseña antes de iniciar sesión en el remoto host.
Posiblemente configurar un alias o un contenedor de secuencia de comandos como una conveniencia para los usuarios debido a que sudo es bastante exigente sobre el uso de los argumentos correctos.

10voto

mcqwerty Puntos 2106

Este parece un buen caso de uso para la autenticación basada en el anfitrión. Este es un método de autenticación donde SSH no utilizar un individuo de usuario's clave en el equipo local (en este caso, el servidor) para autenticar; en su lugar, utiliza el host's de la clave privada, la que se almacena en /etc/ssh/ y que sólo es legible por root.

Para ello, tendrás que crear un archivo con el nombre .shosts en la máquina remota, en el directorio de inicio del usuario que desea iniciar sesión en como (no en ~/.ssh). El archivo debe tener el contenido

server-hostname +

donde server-hostname es el nombre de su servidor, y + es literalmente un signo más de que sirve como un comodín que significa "cualquier usuario".

Usted también tendrá que asegurarse de que el equipo remoto puede comprobar la clave de host del servidor, lo que significa que la clave de host del servidor debe aparecer en /etc/ssh/ssh_known_hosts o ~/.ssh/known_hosts en la máquina remota. Si esto no es ya el caso, se puede establecer por la tala en la máquina remota y ejecutar

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

Una vez que haya configurado estos pasos, usted puede eliminar la clave privada en el servidor por completo, si usted no lo necesita para nada. (Y si no, siempre puedes configurarlo para que sea legible sólo por root o algo).

Usted también puede hacer cosas como permitir o negar algunos de los usuarios de acceder a la máquina remota. Consulte las páginas man de ssh y hosts.equiv para más detalles.

Uno de los problemas con esta configuración es que los usuarios que inicien sesión en el equipo remoto puede modificar .shosts. No hay nada que puedan hacer lo que les permitiría iniciar sesión en el equipo remoto como un usuario diferente, pero que podría cortar su propia cuenta o la de otras personas el acceso a la máquina remota. Si esto es una preocupación, usted podría ser capaz de hacer .shosts sólo modificable por root o algo así - no estoy seguro de si esto funciona, pero se puede probar y ver. (Otros métodos como el con sudo son susceptibles a los mismos riesgos, ya que un usuario siempre puede eliminar ~/.ssh/authorized_keys.)

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: