Cómo tratar con las claves SSH en un entorno inseguro

Question

Cómo tratar con las claves SSH en un entorno inseguro

#1 de Jenny D (3 votos)

2

Estoy tratando de encontrar una solución "segura" para la siguiente situación.

tl;dr ¿Cómo mantener las cosas seguras en un entorno que no lo es?

Trabajo en una empresa donde las estaciones de trabajo no son seguras en absoluto, es decir, hay un usuario similar a una raíz en cada sistema.
Básicamente, todos, y cualquiera, podrían encontrar la contraseña para este usuario y, por lo tanto, tendrían acceso a cualquier computadora y los archivos o documentos de cualquier persona que estén allí. (Sí, aquí hay un gran problema de seguridad para las estaciones de Linux, pero no nos concentremos en esto, no puedo hacer nada al respecto ...)

Sabiendo esto, trato de no mantener nada personal o sensible en la computadora. Sin embargo, me molesta cuando se trata de claves ssh que están vinculadas a algunas de mis cuentas personales. Lo mismo ocurre con cualquier archivo ssh-config, y para cualquier cosa.

Hasta ahora he evitado vincular ssh-keys desde esta computadora a cualquier cuenta hasta ahora, pero obviamente hay una mejor manera de manejar esto. Entiendo que establecer una frase de contraseña para una clave ssh debería hacerla inutilizable para cualquier persona que no tenga la frase de contraseña. Entonces, ¿cómo debo tratar con ssh-agent? ¿Debo dejar de usar esto para reforzar la seguridad aquí?

¿Tengo razón en mis suposiciones?
¿Qué puedo hacer para hacer las cosas de la forma más segura posible? ¿Cuál sería el camino a seguir?

PS: La seguridad aquí no es un requisito absoluto, se trata más de comprender cómo funciona y cómo podría protegerme mejor a mí mismo / a mi privacidad. No estoy buscando soluciones extremadamente sofisticadas o excesivas parano-cosas.
Supongo que tener otra computadora que no sea un gigantesco agujero de seguridad sería una buena manera de comenzar, pero esta no es una opción.

key-management ssh

pregunta d6bels 20.03.2015 - 09:58

fuente

1 respuesta

Lea otras preguntas en las etiquetas key-management ssh

¿Por qué la primera línea del mensaje http no se puede leer después del descifrado? código abierto IKE para Windows 7/8 [cerrado]

score 3 · Accepted Answer

Tienes razón sobre cómo funciona la frase de contraseña. Y, dada su situación, le aconsejaría que no use un agente de SSH. También debe tener en cuenta que si alguien con acceso root instala un keylogger en su máquina, su frase de contraseña puede verse comprometida. Para reducir el riesgo, puede mantener la clave, por ejemplo, una memoria USB, en lugar de en el disco duro local. Para mayor seguridad, obtenga una memoria USB encriptada como la Ironkey, que funciona con Linux, así como con Windows y Mac, y puede configurarse para que se bloqueen después de un cierto período de tiempo, de modo que incluso si la deja en la máquina, no será utilizable sin la contraseña.

Pero además de proteger su clave, hay algunas cosas que puede hacer en el sistema de destino para hacer que la clave sea menos útil para un atacante.

Tenga una clave separada para cada sistema desde el que se conecte.
Restrinja la clave en el servidor de destino, de modo que solo se pueda utilizar desde esa máquina. Para ello, edite el archivo authorized_keys en el servidor, insertando from="10.1.2.3" al comienzo de la línea que contiene esta clave. (Hay más información sobre cómo restringir las claves SSH en esta pregunta de ServerFault .)
Asegúrese de haber iniciado sesión en el servidor de destino y verifique si alguien realmente inició sesión allí. Los registros deben ir a un servidor remoto, ya que un atacante podría alterar los registros almacenados localmente.
No permitir inicios de sesión de root y sudo sin contraseña. Asegúrese de que las acciones sudo estén registradas.

Además de estos puntos específicos, también diría que uno debería siempre considerar la posibilidad de que una clave SSH pueda verse comprometida. La forma de lidiar con esto es no confiar completamente en la clave SSH para proteger su sistema; también debe mirar el sistema completo, registrar, verificar si hay rootkits, notar si / cuando se modifican los archivos del sistema, etc.