¿Es una buena idea una ubicación central para claves_autorizadas?

29

Estoy en el proceso de configurar un servidor en la nube para ejecutar la siguiente pila: Ruby, Passenger, Apache; bajo Ubuntu 10.04 (Lucid Lynx).

En el proceso de querer hacer que el servidor sea más fácil de administrar, configuro las claves RSA rooty www-dataasí puedo sshingresar al servidor. Lo que no me gustó fue www-datael .sshdirectorio de ese en el /var/wwwque está la configuración de directorio predeterminada para apache. Mi preocupación es que si apache no está configurado correctamente, entonces el .sshdirectorio puede quedar expuesto.

Me encontré con la solución para mover el ~/.ssh/authorized_keysarchivo en una ubicación central mediante el cambio AuthorizedKeysFileen /etc/ssh/sshd_config. Esto viene con 2 ventajas: una ubicación única para las claves y no tener que preocuparse por una mala configuración de apache. La única desventaja que se me ocurre es que ahora todos los usuarios están disponibles para iniciar sesión en el servidor (claramente una espada de doble filo del archivo de clave central).

¿Hay algo que me haya perdido en esta configuración? ¿Me he expuesto en exceso o es una solución mejor que los authorized_keysarchivos individuales ?

Soy ecológico cuando se trata de la administración del servidor, pero estoy totalmente listo para ser llamado malos nombres por hacer cosas malas. :RE

linux apache-2.2 security ssh Gavin Miller
fuente
1
Al menos las claves públicas expuestas (solo lectura) en Internet no son el mayor riesgo ... (Sin embargo, podría permitir a los atacantes ver si pueden iniciar sesión en el servidor con una clave privada que obtuvieron en otro lugar, pero no no les permita iniciar sesión simplemente obteniendo eso ...) (Los problemas serios son si hay un id_rsaarchivo ~/.sshy logran leerlo)
Gert van den Berg

Respuestas:

51

Todos los archivos de claves se pueden centralizar en el mismo directorio y no mezclar en el mismo archivo.

Simplemente configure el sshd_configarchivo así:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

En tu servidor:

  • las claves de www-data estarán en /etc/ssh/authorized_keys/www-data
  • las claves raíz estarán en /etc/ssh/authorized_keys/root

En cuanto a los derechos de acceso, sshd acepta estas configuraciones:

/etc/ssh/authorized_keyses propiedad root:rooty tiene el modo 755. Los archivos clave son propiedad root:rooty tienen el modo 644.

Otros modos pueden funcionar pero no los he probado.

mahn
fuente
3
+1, pero no haría que los otros mordieran. Establezca la propiedad de los archivos% u para el usuario para que esto no sea necesario.
Aaron Copley
1
Buena solución al problema de que los usuarios malintencionados pueden agregar más claves públicas a sus ~ / .ssh / Authorizedkeys que otorgan acceso a otros.
bbaassssiiee
Acabo de confirmar que el modo 600 para el archivo de claves autorizado de un usuario no funciona; necesita ser el modo 644
Luis E.
@bbaassssiiee Esto ABSOLUTAMENTE NO resuelve ese problema. Simplemente pueden compartir su clave privada con quien quieran dar acceso (esta posibilidad puede mitigarse, por supuesto, pero esta respuesta es absolutamente cero para mitigarla)
DylanYoung
1
@DylanYoung Admito que es posible compartir claves privadas. Pero con chattr puedo revocar el acceso de escritura a los archivos autorizado_claves para poder distribuirlos exclusivamente, salvaguardando una sola línea en cada archivo también.
bbaassssiiee
15

En general, no haría lo que estás sugiriendo. Rompe suposiciones comunes (como ~/.ssh/authorized_keystrabajar para sus usuarios e introduce problemas que ya ha mencionado en su pregunta. Si ve problemas evidentes antes de la implementación, significa que su solución no es ideal.

En cuanto a la seguridad, también creo que es una idea TERRIBLE que todos compartan una cuenta de servicio: en este momento solo eres tú y sabes que eres el que está haciendo los cambios. En 5 años, cuando tenga 5 administradores, querrá saber quién cambió qué y buscar en los registros de auditoría para ver quién usó qué clave cuando es un dolor real.
Es mejor que la gente inicie sesión como ellos mismos y use sudoo algo similar para escalar sus privilegios y hacer lo que sea necesario.

Si aún desea centralizar las claves SSH, le sugiero que busque en un sistema de implementación como Puppet o radmind para administrar / distribuir los authorized_keysarchivos a los ~user/.ssh/directorios apropiados (o piratear una solución interna que los coloque en su lugar).
A medida que se expande a varios servidores, es posible que desee consultar el parche de clave pública LDAP para versiones anteriores de OpenSSH (o la AuthorizedKeysCommanddirectiva y un script apropiado en la versión más reciente de OpenSSH) para poder centralizar a sus usuarios y no tener que distribuir sus claves en toda su red, pero es probable que esté bastante lejos para usted.

voretaq7
fuente
1
+1 para el argumento de compartir. En resumen, me llevó un momento darme cuenta de su implicación: no debería haber ningún directorio ~ www-data / .ssh, por lo que no hay riesgo de seguridad por parte del navegador web.
thiton
¡Gracias por la respuesta! Si te estoy entendiendo correctamente. No debería tener rootni www-dataaccesible a través de una clave ssh, ¿es correcto?
Gavin Miller
1
Tener un ~www-data/.sshdirectorio no es algo terrible (con los permisos apropiados no es un riesgo sustancial), pero si va a usarlo ~www-data/.ssh, probablemente sea mejor no tener su raíz web ~www-data(mover la raíz web o mover www-datael directorio de inicio). La diferenciación de los usuarios es el argumento más importante en mi humilde opinión: sé que si veo el jsmithinicio de sesión, sé que es John Smith. Si veo el www-datainicio de sesión, necesito cavar más para averiguar quién era.
voretaq7
La razón por la que necesitaba una clave ssh para www-data es que estoy usando Beanstalk (SCM y herramienta de implementación) para hacer las implementaciones a través de SFTP. ¿Debería crear una cuenta separada para que Beanstalk haga el ftp'ing? ¿Cuál sería la mejor solución allí?
Gavin Miller
1
Como está en la mayoría de los sistemas AuthorizedKeysFilepor /etc/ssh/sshd_configdefecto %h/.ssh/authorized_keys. Aquí %hhay un marcador de posición para el directorio de inicio. Lo que le impide configurarlo /some/folder/ssh_keys_by_user/%h/o incluso /root/ssh_keys/%u. Incluso podría darle al usuario respectivo acceso de escritura a su archivo individual allí (y solo el suyo) para vincular el archivo a la ubicación estándar (con ln -s /root/ssh_keys_by_user/username /home/username/.ssh/authorized_keys) y no romper los supuestos antes mencionados.
con-f-use