¿Necesito tener una frase de contraseña para mi clave SSH RSA?


71

Antes de comenzar en mi trabajo actual (en una pequeña empresa), mi oficina no tenía firewall en la red y, literalmente, nunca se hizo una copia de seguridad. Ahora que me he registrado como un departamento dedicado de sysadmin / one-man-IT, he estado haciendo todo lo posible para cambiar esto. Después de explicarle a mi jefe cuán vulnerables éramos, me permitió configurar algunos servidores de respaldo, uno de los cuales está en su casa.

En este momento, estoy tratando de configurar todo para poder automatizar las copias de seguridad diarias. Estoy planeando usar rsync a través de ssh para hacer esto. Por razones de seguridad y para facilitar la automatización, estaba planeando deshabilitar el inicio de sesión de contraseña ssh y solo usar la validación de clave rsa. Bueno, si tengo un conjunto de frases de contraseña rsa, todavía tendría que ingresar una contraseña, y eso es un problema.

¿No tener una contraseña rsa hace que las cosas sean significativamente menos seguras? Soy la única persona en la compañía que tiene algún tipo de pista sobre este tipo de cosas, por lo que no me preocupa demasiado que alguien llame a una terminal en mi máquina (que siempre está bloqueada cuando estoy AFK, de todos modos ) y enviarse a uno de los servidores de respaldo y causar daños. Todavía soy muy, muy nuevo en el mundo de la administración de sistemas, y esta es la primera vez que hago algo así, y no quiero dejar ningún hueco en la configuración de seguridad.

Las computadoras en cuestión aquí ejecutan Ubuntu 10.10, SME Server y OSX 10.6, si eso de alguna manera hace alguna diferencia.


55
Realmente no debería haber ninguna pérdida de seguridad al no tener una frase de contraseña en su clave. Mantener la integridad de seguridad de la clave en este punto se vuelve integral ya que si alguien puede copiarla, no hay clave secreta que les impida usarla.
Chris Marisic

1
Tal vez solo soy yo, pero no tengo idea de lo que el comentario anterior está tratando de decir.
underscore_d

3
@underscore_d Básicamente dice: No tiene ningún impacto en la seguridad SSH tener o no frases de contraseña para sus claves, PERO debe mantener sus claves localmente seguras.
Hartator

Respuestas:


89

Como sabes, la ventaja que te brinda la frase de contraseña es que si alguien puede leer tu clave privada, no puede usarla.

Si alguien puede acceder a esa clave privada, debe dar por sentado que tiene acceso (ed) / comprometido a cualquier máquina configurada con la clave pública. Cosas como .bash_history o .ssh / config solo lo hacen más fácil, incluso si su .ssh / known_hosts está ofuscado.

No tener una contraseña en tu clave no es el fin del mundo, aquí hay 3 ideas para intentar y ayudarte a asegurarte un poco mejor a pesar de esto. ( El problema es el segundo, lee eso si nada más )


  1. No utilice la misma clave en todas las máquinas y usuarios. Genere a cada usuario en cada máquina (que necesita hacer este tipo de cosas) su propio par de claves. Esto le permitirá mantener un control de grano fino sobre qué es capaz de saber dónde.

  2. Al agregar la clave a su archivo Author_keys, puede bloquearla para que solo pueda ejecutar un comando específico o usarla solo desde un host específico.

    Vea man sshy busque command = y from =

    La sintaxis es algo así como:

    from="1.2.3.4",command="/path/to/executable argument" ssh-rsa key name

    es decir, ingrese 'rsync' allí y solo su clave podría llamar a 'rsync', y solo desde la dirección IP 1.2.3.4. Se pueden separar varias IP por ,. Los nombres de host también son compatibles.

  3. Otra cosa que me viene a la mente es la directiva 'AllowUser' en su sshd_config

    Permitir usuarios

    A esta palabra clave puede seguirle una lista de patrones de nombre de usuario, separados por espacios. Si se especifica, el inicio de sesión solo se permite para los nombres de usuario que coinciden con uno de los patrones. '*' y '?' se puede usar como comodines en los patrones. Solo los nombres de usuario son válidos; no se reconoce una identificación de usuario numérica. Por defecto, el inicio de sesión está permitido para todos los usuarios. Si el patrón toma la forma USER @ HOST, USER y HOST se verifican por separado, restringiendo los inicios de sesión a usuarios particulares de hosts particulares.

    Básicamente, eso garantiza que el usuario solo pueda iniciar sesión desde una determinada ubicación. (aunque también acepta comodines). No va a resolver todos sus problemas, pero al menos lo hará más difícil para los demás.


1
Hermoso: esto es exactamente lo que necesitaba saber. Muchas gracias!
eckza 23/03/11

3
No hay problema, ¡no lo tome como una lista exhaustiva! :-) Cosas como revisar regularmente auth.log / secure etc. recuerdan.
Caro

3
¿Entonces auditar en lugar de preocuparse por el robo de su frase de contraseña?
Ehtesh Choudhury

3
@shurane ¡Haz las dos cosas!
Caro

4

Puede usar algo como un llavero para que tener una frase de contraseña sea menos doloroso. Esto es un poco más seguro que usar un inicio de sesión sin contraseña, y se puede usar en combinación con las otras respuestas aquí. La respuesta de PriceChild fue bastante buena.


-4

Personalmente uso DSA, no RSA, principalmente porque es lo que siempre he usado y sé que "simplemente funciona", pero la teoría, supongo, es la misma. Puede reemplazar dsacon rsaen el siguiente.

En la fuente:

$ ssh-keygen -t dsa

Luego copie el contenido del .ssh/id_dsa.pubarchivo .ssh/authorized_keysen la cuenta de usuario en el destino.

Entonces, debería poder intercambiar entre la fuente y el destino sin contraseñas.


1
¿Hay alguna razón por la que defienda dsa sobre rsa? Más a menudo he visto lo contrario recomendado.
Caro

@PriceChild: AFAIK, su seguridad es más o menos equivalente (suponiendo un tamaño de clave suficiente). Al no ser un criptógrafo, confío en la decisión de OpenSSH y GnuPG de usar RSA como algoritmo de clave predeterminado. Ver también esta pregunta .
Grawity

No hay una razón real, principalmente una elección personal, y el hecho de que RSA fue pirateado recientemente y se robaron códigos confidenciales: cómo eso se relaciona con las claves RSA No tengo idea (¿quién lo hace?) Pero siempre he usado DSA ya que parecía más seguro .
Majenko

9
Me temo que el hackeo de "la empresa RSA" no tiene ningún efecto en la seguridad de "el algoritmo RSA". Consulte también secure.wikimedia.org/wikipedia/en/wiki/RSA_Security - "RSA recibió su nombre del algoritmo de criptografía de clave pública RSA, que a su vez recibió el nombre de las iniciales de sus coinventores: Ron Rivest, Adi Shamir y Len Adleman ".
Caro

66
@ Matt: Lo único que tienen en común es el nombre. El algoritmo criptográfico asimétrico RSA es matemática pura, no hay forma de que pueda debilitarse por una intrusión en los sistemas de algunas corporaciones.
Grawity
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.