¿Cómo almacenar claves SSH?

67

Recientemente comencé a usar claves SSH en lugar de contraseñas (gracias a GitHub, por supuesto), así que tenga en cuenta que soy bastante nuevo en este concepto. Actualmente, mis claves simplemente se encuentran en ~ / .ssh, pero no estoy seguro de si es una buena práctica. Por ejemplo, si tengo varias máquinas, necesitaría duplicar mis claves privadas, lo que creo que no es deseable. O, si mi HDD se apaga, perderé esas claves, lo que (supongo) también es indeseable.

Entonces, ¿cuáles son las mejores prácticas para almacenar claves SSH de forma segura, conveniente y confiable?

Parece que usar una tarjeta inteligente es una opción (consulte Tarjetas inteligentes para almacenar claves gpg / ssh (Linux): ¿qué necesito? ) ¿ Es esta la mejor?

Actualización: la razón de la pregunta fue que muchos servicios (como GitHub, AWS EC2) proporcionan guías sobre cómo configurar las claves SSH para usar el servicio, pero poco o ningún fondo (como qué hacer si ya tiene una clave generada por ssh-keygen[1], cuáles son las medidas de seguridad recomendadas). Y no está claro si esa información no es importante, o se espera que la conozca 'por defecto'.

Para resumir las respuestas hasta este punto (pero léalas, y si tiene algo que agregar, por favor hágalo): parece que en este caso está bien si solo deja sus claves privadas en ~ / .ssh, siempre que guárdelos de otras personas; pero asegúrese de tener otra forma de acceder al servicio para cargar o generar una nueva clave si pierde una (que normalmente es el caso).

[1] GitHub solía proporcionar ayuda sobre cómo administrar múltiples claves .

security ssh-keys

— Anton Strogonoff
fuente

Ese enlace parece estar roto help.github.com/multiple-ssh-keys

— KJ Price

@KJ Price, gracias a la Máquina Wayback de Internet Archive , la página todavía está disponible en línea, aunque no en su enlace original. Se puede encontrar una copia de la página archivada el 2 de septiembre de 2011 en Multiple SSH keys .

— luna

41

Por ejemplo, si tengo varias máquinas, necesitaría duplicar claves privadas, lo que creo que no es deseable.

No, en realidad no lo haces. Si tiene varias máquinas, simplemente cree una clave privada separada en cada una. Para cada clave privada, solo suba la clave pública correspondiente a GitHub usando el mismo proceso.

Además, si mi HDD se apaga, perderé mi clave privada, lo que (supongo) también es indeseable.

Realmente no; Si pierde su clave privada, simplemente genere una nueva y cargue la clave pública correspondiente.

Por lo que vale, tiene razón en que duplicar una clave privada es altamente indeseable. Idealmente, una clave privada debe generarse en un archivo ( ~/.ssh/id_rsapor ejemplo) y nunca debe abandonar ese archivo; es decir, nunca debe copiarse, moverse y, especialmente, no transferirse a través de una red. (por ejemplo, los excluyo de las copias de seguridad) Debido a la naturaleza de los protocolos de autenticación asimétricos, solo debe preocuparse por mantener su clave privada fuera del alcance de los demás. Si vas un poco por la borda y pierdes el rastro de ti mismo, generalmente no es gran cosa. (Esto no debe confundirse con las claves privadas de cifrado asimétrico , por ejemplo, las claves GPG, a las que probablemente desee conservar).

— David Z
fuente

14

Esto solo funciona si tiene algún otro método para acceder a los servidores a los que esa clave privada proporciona acceso. Puede cargar la nueva clave pública solo si tiene ese acceso de respaldo.

— ÁRBOL

2

@TREE: correcto, pero en mi experiencia es excepcionalmente raro encontrar un servidor que no proporcione algún método alternativo de acceso (o al menos de agregar una clave pública adicional sin pasar por SSH).

— David Z

3

Gracias, eso aclara mucho las cosas. Realmente, perder la clave SSH privada no parece un problema, ya que para todos los servicios que estoy usando siempre parece haber otra forma de acceder a un servicio para cargar uno nuevo.

— Anton Strogonoff

3

AWS no proporciona ninguna otra forma de acceso además de la clave privada. Debe desconectar el disco y perder el tiempo con él para obtener acceso una vez que haya perdido su clave privada.

— Asad Saeeduddin

1

Tenga en cuenta que puede poner una contraseña en su clave privada si desea otra capa de seguridad.

— sudo

8

Agregaría que ~ / .ssh / es legible por su navegador si está utilizando la misma cuenta de usuario para ejecutar ambos.

¡Intentalo! Apunte su navegador a su clave privada en su directorio de inicio. Es divertido.

Por lo tanto, recomendaría almacenar claves ssh en el directorio de inicio de otra cuenta de usuario.

una palabra sobre las claves de protección de frase de contraseña

En estos días, descifrar contraseñas no aleatorias es súper rápido. Echa un vistazo a hash cat
- (Aunque las contraseñas aleatorias y largas de más de 12 caracteres aún tardan bastante en llegar a la fuerza bruta)
- Por lo tanto, las claves ssh cifradas con AES son indescifrables en el futuro previsible, siempre y cuando utilice buenas frases de contraseña largas. Ver recomendaciones de github
Entonces, un sitio web puede adivinar su clave sin JavaScript. Y luego fuerza bruta la llave fuera de línea.
Y los navegadores también pueden buscar en su Portapapeles con JS. Por lo tanto, copiar frases de contraseña muy largas también lo pone en riesgo de los ataques javascript más sofisticados.

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

— HeyWatchThis
fuente

17

Para ser claros, solo porque el navegador puede leer su clave privada, eso no significa que un sitio web que se ejecuta en el navegador pueda.

— Ajedi32

66

Pero, si inyecta un proceso en el proceso del navegador. Entonces puedes tomar el control del navegador también. Entonces este argumento es perfectamente válido.

— BigSack

Pero luego tiene que hackear el proceso que inyecta procesos en el registro de procesos de la unidad de procesamiento de su navegador.

— Skid Kadda

8

Hay una muy buena herramienta llamada KeePass2 ( http://keepass.info/ ) con la extensión ( http://lechnology.com/software/keeagent/ )

Puede almacenar contraseñas, claves SSH y mucho más (en la página oficial de KeePass hay extensiones mucho más útiles)
Si desea iniciar sesión automáticamente con sus claves SSH, solo necesita instalar PuTTY, Pageant y KeePass con KeeAgent. Si lo está configurando correctamente, no tiene que configurar las claves en PuTTY, Pageant o FileZilla.

Lo uso yo mismo y estoy bastante feliz por eso. Tengo más de 30 VPS y un servidor raíz con una cierta cantidad de claves SSH diferentes y lo único que tengo que hacer es abrir KeePass (no es mi contraseña segura principal) y luego solo necesito escribir en la consola mi frase de contraseña.

— CentrixDE
fuente

3

Recomendaría almacenar claves privadas:

sin conexión (no en la nube)
en más de un lugar
aparte de cualquier cosa con la que esté relacionado, por ejemplo, una clave para sus datos cifrados, almacénelos en un lugar separado de los datos

Yo diría que el mejor lugar sería:

un disco duro externo
una tecla flash
una computadora no conectada a internet

Aún mejor, simplemente imprímalo y colóquelo en una caja fuerte a prueba de fuego.

— paja
fuente

44

Seguridad / mejores prácticas trabajan de la mano con practicidad. Si una estrategia de seguridad obstaculiza la capacidad de usar un sistema, el usuario lo evitará en lugar del atacante.

— zaTricky

1

Tengo un archivo tar que tiene mi configuración de directorio de usuario (.bashrc, .ssh / y otros archivos de configuración) que guardo en un lugar seguro. Cuando obtengo una nueva cuenta de shell en cualquier lugar, descomprimo el archivo tar en ella.

Solo debe poner sus claves privadas en servidores de confianza, de lo contrario, debe crear una nueva clave privada en el servidor solo para ese servidor y permitirle el acceso a las cosas a las que desea que tenga acceso.

Personalmente, me siento cómodo simplemente copiando mi .ssh / cosas en todas partes (también significa que mediante la clave ssh regular se obtiene acceso ssh al instante, ya que ya está en el archivo autorizado_keys).

— OchoBitTony
fuente

Supongo que tener encriptado ~ / .ssh dando vueltas en un dispositivo USB evitaría la necesidad de generar y cargar una nueva clave en caso de falla del hardware. Sin embargo, dado que hay muy pocos servidores a los que utilizo las claves SSH para acceder (y muy pocas máquinas desde las que me conecto), generar nuevas claves no causará demasiada sobrecarga.

— Anton Strogonoff

2

Es caballos para cursos y depende de por qué usas las teclas. No veo un problema al copiar una clave privada ssh sobre un enlace SSH ya encriptado. Pero si no confía en la máquina de destino y no sabe quién tiene acceso de root, no debe poner nada en el servidor que no pueda permitirse perder.

— EightBitTony

No desea poner su clave privada en el servidor de otra persona. Cualquier persona con acceso de raíz en ese servidor puede leer su clave privada y luego puede suplantar su identidad en los sistemas a los que accede con esa clave privada. Solo debe poner su clave pública para acceder al servidor. Y no piense que la frase de contraseña ayuda mucho si la está usando en una máquina remota para descifrar una clave privada.

— Codeguy007

Puede reenviar ssh-agent sobre ssh. De esa manera no necesita almacenar la clave privada en el servidor o enviar su frase de contraseña a través de la red. stackoverflow.com/questions/12257968/…

— Codeguy007

1

Puede almacenar sus claves ssh en un directorio separado dentro de una partición encriptada. Luego puede usar ssh apuntando a ese directorio con -i:

ssh -i identity_file me@example.com

Descripción completa ( man ssh):

-i archivo de identidad

Selecciona un archivo del que se lee la identidad (clave privada) para la autenticación de clave pública. El valor predeterminado es ~ / .ssh / identity para la versión 1 del protocolo, y ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 y ~ / .ssh / id_rsa para la versión 2. del protocolo. también se especificará por host en el archivo de configuración.
Es posible tener múltiples opciones -i (y múltiples identidades especificadas en los archivos de configuración). Si la directiva CertificateFile no ha especificado explícitamente certificados, ssh también intentará cargar la información del certificado del nombre de archivo obtenido al agregar -cert.pub a los nombres de los archivos de identidad.

Mi enfoque de seguridad es que divido la información en privada y general. No quiero encriptar toda la partición de mi casa, por eso copio archivos secretos (como los que están en ~/.ssh) en una partición encriptada.

Creo que esto proporciona una seguridad bastante eficiente, porque el malware no encontrará nada en ~ / .ssh, y probablemente no escaneará todo el sistema o los perfiles de shell para encontrar esa ubicación.

-F configfile

establece la ruta al archivo de configuración.

PD: Crearía un alias alias ssh='ssh -i ... -F ...'y lo pondría en tu perfil.

PPS No he comprobado esto todavía, y no sé cómo otros programas (como git) funcionarán con estas configuraciones ssh.

— Yaroslav Nikitenko
fuente