Cuando aprendí a hacer claves ssh por primera vez, todos los tutoriales que leí indicaban que debería elegirse una buena frase de contraseña. Pero recientemente, al configurar un proceso de daemon que necesita ssh para otra máquina, descubrí que la única forma (parece) de tener una clave que no necesito autenticar en cada arranque es crear una clave con un vacío frase de contraseña Entonces mi pregunta es, ¿cuáles son las preocupaciones con el uso de una clave sin frase de contraseña?
Respuestas:
Una clave sin frase de contraseña depende de que nadie más pueda acceder a esa clave (que de todos modos no podría obtener los recursos a los que da acceso). Por lo tanto, si la clave otorga acceso a una máquina al lado, y ambas máquinas tienen el mismo nivel de seguridad electrónica y física, entonces no es realmente un gran problema.
Por otro lado, si su clave está en una máquina con poca seguridad (quizás tiene muchos usuarios que no son de confianza, es fácilmente accesible físicamente o no está bien actualizada con su régimen de parches), entonces probablemente no lo haga ' No quiero mantener las claves sin contraseña allí.
En última instancia, se debe confiar en su configuración y sopesar los riesgos / costos de hacerlo: si puede estar bastante seguro de que no es realmente más fácil para un atacante obtener acceso a la clave que al recurso al que la clave le da acceso Entonces estás bien. Si no tiene esa confianza, probablemente debería solucionar los motivos :)
Otra solución, que mejora la seguridad y te hace más fácil, para que no tengas que escribir tu contraseña todo el tiempo:
si desea cifrar su clave privada, puede usarla ssh-agenten su estación de trabajo para 'almacenar en caché' la clave no cifrada. cuando desea almacenar su clave descifrada, ejecuta ssh-add ~/.ssh/id_rsao como se llame su clave privada. se le pedirá la contraseña, y la clave descifrada estará disponible para sus conexiones ssh hasta que ssh-agentcierre la sesión, cierre o cierre.
puedes killlas teclas con almacenada ssh-agent -ky se puede asignar un tiempo de vida de la clave para estar en la memoria, con ssh-agent -t [seconds]lo que por ejemplo; si no desea mantener su clave descifrada para siempre, pero desea hacer muchos cambios en sus hosts, puede establecer el tiempo de espera en 5-10 minutos. para que no tenga que ingresar continuamente la contraseña de su clave.
una vez más, todo esto tiene que ver con la confianza que tiene en la seguridad de su / estación de trabajo / que, si usted es el único que tiene acceso a él, y tiene una contraseña local bastante segura, y no Invite exploits y rootkits sobre usted mismo, su clave privada sin contraseña es razonablemente segura.
si eres como yo, y mantienes tu clave privada en una memoria USB, definitivamente querrás encriptarla, aunque sea solo una clave privada (una separada de la que uso en mi estación de trabajo, así que si pierdo mi clave, puedo eliminar fácilmente la clave pública de la memoria USB de la ~/.ssh/authorized_keyslista de mi servidor , lo que también trae una / excelente / razón para agregar comentarios ÚTILES a sus claves públicas)
En su respuesta a una respuesta anterior, dijo que solo las personas en las que confía tienen acceso a la máquina con las llaves. Solo quiero aclarar que su clave privada NO necesita estar en el servidor al que se está conectando, en caso de que eso sea lo que está haciendo. solo su clave pública debe estar en el servidor, y eso no es un problema, por eso es una clave 'pública'.
oh, olvidé mencionar; inicio ssh-agentcuando inicio X, de lo contrario, las claves descifradas con las que almaceno ssh-addno se retienen a través de diferentes xtermsesiones, y tengo que volver a ingresar la contraseña cada vez que cierro el archivo que xterminicié ssh-add. En mi ~/.xinitrcarchivo, tengo:
if [ -x /usr/bin/ssh-agent ]; then
eval $(/usr/bin/ssh-agent)
fi
Tengo la llamada para ssh-agentterminar evalporque ssh-agent devuelve algunas variables de entorno que deben establecerse cuando se ejecuta, y se ejecuta desde ~/.xinitrc, las variables de entorno son constantes a lo largo de la sesión X.
ssh-agenty ssh -A -i privkey user@hostlo permite, permitirá el reenvío del agente ssh, lo que le permitiría acceder a un servidor desde el servidor inicial, sin colocar su clave privada en el primer servidor. No se recomienda el encadenamiento ssh, incluso sin el reenvío de claves ssh habilitado, y ssh -Atiene sus propios problemas de seguridad. no hay razón para que la clave en el servidor no se pueda cifrar, mientras que la clave en su estación de trabajo no requiere frase de contraseña.
Puede echar un vistazo a una pregunta similar que hice sobre las claves privadas SSL para servidores web. Básicamente, hay tres opciones:
Cada uno de ellos es defectuoso, por lo que todo depende de qué es lo que más temes.
Para el acceso automatizado, que como usted dice requiere claves sin frase de contraseña, siempre uso las opciones adicionales de autorizado_claves (vea sshd (8)) para limitar el comando que se puede ejecutar.
Por lo general, proporciono una secuencia de comandos cuidadosamente escrita en el extremo remoto, que hace exactamente el trabajo (o trabajos, puede ver los parámetros) que quiero que me permitan.
Luego también lo bloqueo a las direcciones IP que pueden conectarse con esa clave (no 100% infalible, pero también está bien con la restricción de comando).
Mientras nadie más que usted tenga acceso a la clave, no necesita una frase de contraseña. De hecho, no puede utilizar una frase de contraseña en las claves utilizadas por el software automatizado.
Si desea usar ssh para hacer cualquier tipo de procedimiento automatizado, estoy pensando específicamente en las comprobaciones de Nagios, entonces probablemente no quiera usar una frase de contraseña.
En esta situación, probablemente no estaría usando esto fuera de una LAN, y tendría la clave almacenada de forma segura en el servidor que realiza el procedimiento.
La mayoría de los tutoriales sobre SSH anticiparán que una persona inicie sesión desde una red externa, posiblemente desde una computadora insegura, en cuyo caso el consejo es sólido.
Básicamente, a menos que sepa que hay una buena razón para no hacerlo, cree una frase de contraseña. Ser demasiado flojo para escribir su contraseña cada vez podría ser una razón suficiente para usted :-)