¿Es realmente seguro conectarse a un servidor por SSH desde los hoteles durante un viaje?

¿Es realmente seguro conectarse a un servidor utilizando SSH desde hoteles durante un viaje?

Servidor :
- CentOS 7
- Autorización solo mediante clave RSA - se denegó la autenticación de contraseña
- Puerto no estándar

Estación de trabajo :
- Ubuntu 14
- contraseña de usuario
- contraseña para usar la clave RSA (método estándar)

Tal vez sea una buena idea mantener la mitad de la clave RSA privada en una memoria USB y agregar automáticamente (por script) esta mitad a ~ / .ssh / private_key antes de conectarse.

Internet será a través de WIFI en hoteles o por cable en un departamento alquilado.

UPD
Perdón por no estar claro al principio. Me refiero a la seguridad en dos aspectos aquí:

Seguridad de solo la conexión SSH a través de una red no confiable.
Seguridad de una computadora con la clave necesaria para la conexión SSH: si se la roban, cómo proteger el servidor ...

security physical-security

— Sergey Serov
fuente

¿Qué media clave RSA? ¿La parte pública de la clave de host ssh? ¿La mitad de la parte privada de su clave ssh de usuario?

— andol

la mitad de mi clave RSA privada, por supuesto :) y automáticamente por script para agregar esta mitad a ~ / .ssh / private_key antes de conectarme al servidor.

— Sergey Serov

Ya eres más seguro que la mayoría de la gente porque estás ejecutando Linux. Como está ejecutando versiones recientes, debería tener nuevas versiones de OpenSSH que admitan criptografía más fuerte. Después de seguir tecmint.com/5-best-practices-to-secure-and-protect-ssh-server puedes jugar limitándote a una criptografía más fuerte como stribika.github.io/2015/01/04/secure-secure- shell.html

— pollitos

@chicks "es más seguro que la mayoría de la gente porque estás ejecutando Linux" es una tontería. SSH es SSH, independientemente de si se ejecuta en Linux, Unix (la Mac) o Windows. Y podríamos señalar muchas fallas de seguridad extremadamente graves en Linux en la historia reciente (¿Heartbleed, alguien?). Solo digo, dejemos las tontas guerras de llamas del sistema operativo al margen donde pertenecen porque distrae de las preguntas y problemas reales. ¡Gracias! ;-)

— Craig

@chicks Supongo que eso es lo que estaba tratando de transmitir. Muchos problemas de seguridad en todos los sistemas operativos, y Microsoft ha avanzado enormemente desde que comenzó su iniciativa de "computación confiable" hace varios años. Simplemente creo que el asunto "estás más seguro porque Linux" desvía la conversación del problema actual ( respetuosamente); ;)

— Craig

Respuestas:

Entonces, con respecto a hacer una conexión ssh sobre una conexión explícitamente no confiable.

Suponiendo que ya tiene una entrada ~ / .ssh / known_hosts de una conexión anterior, sí, debería poder conectarse sin preocuparse de si la red es segura o no. Lo mismo ocurre si tiene algún otro medio para verificar la clave de host ssh.

Si nunca antes se ha conectado al servidor, ni tiene ninguna otra forma de verificar la clave de host ssh, es posible que desee tener más cuidado con la red que utiliza para conectarse.

— andol
fuente

¡¡Gracias!! Entonces, ¿es seguro conectarse al servidor por SSH incluso a través de cualquier wi-fi público?

— Sergey Serov

En realidad, esta respuesta se aplica a cualquier situación en la que desee ssh a un servidor remoto y cualquier parte de la ruta no esté bajo su control total (por lo que prácticamente cualquier cosa, aparte de ssh-shing a un localhost recién instalado o por un cable de enlace cruzado )

— Hagen von Eitzen

Vale la pena notar que si el cliente no conoce la clave del host, será posible un ataque MITM completo si se usa la autenticación de contraseña. Pero si se utiliza la autenticación basada en claves, el atacante solo podrá suplantar al servidor. El atacante tampoco podrá autenticarse en el servidor real. Es difícil para un atacante proporcionar una suplantación convincente del servidor en ese caso, por lo que puede notar que algo anda mal antes de que sea demasiado tarde. En resumen: la autenticación de clave pública es mucho más segura que la autenticación de contraseña .

— kasperd

@kasperd: Bueno, si el cliente de conexión tiene habilitado el reenvío de agentes, incluso la autenticación de clave pública puede proporcionar la experiencia completa de MITM. Pero sí, la autenticación de clave pública es definitivamente preferible a las contraseñas normales, cualquier día.

— andol

@kasperd: Bueno, puedo imaginar fácilmente a alguien descubriendo el reenvío de agentes, pero sin comprenderlo completamente, poniendo algo como "Host * \ n \ tForwardAgent yes" en su ~ / .ssh / config. La gente hace todo tipo de locuras :-)

— andol

En la segunda parte de su pregunta, parece estar preocupado por el robo de su computadora portátil y, con ella, sus claves privadas para su inicio de sesión SSH sin contraseña en sus servidores.

Tenga en cuenta que esto se puede resolver fácilmente (el problema de las claves privadas) almacenando las claves privadas "encriptadas" con una "frase de contraseña": pueden encriptarse inicialmente, mientras se generan con la utilidad ssh-keygen , proporcionando una frase de contraseña al final de el proceso de generación o, si ya los tiene sin codificar, utilizando la utilidad ssh-keygen con -popción. Una vez que se encripta la clave, en cada inicio de sesión se le pide que ingrese la frase de contraseña relacionada y ... si es correcto, todo procederá normalmente.

Además, si no desea ingresar la frase de contraseña cada vez que inicia el cliente ssh, puede usar el agente ssh : puede realizar un seguimiento, en la memoria, de las claves privadas sin cifrar. Simplemente puede ejecutar ssh-add apuntando al archivo que contiene la clave cifrada y, después de solicitar la frase de contraseña, la clave se agrega al conjunto administrado por el agente ssh. Después, cada vez que el cliente SSH requiere una clave protegida con frase de contraseña, el agente ssh proporciona de forma transparente la clave privada no cifrada relacionada al cliente ssh. Entonces, para usted, no es necesario ingresarlo de manera interactiva.

Tenga en cuenta que ssh-agent puede administrar muchas claves y, obviamente, puede "ajustar" su computadora portátil / escritorio para iniciar la ssh-addutilidad (para completar el conjunto de claves de ssh-agent) en el momento de inicio de sesión / inicio.

Además, si alguien roba su computadora portátil, sus claves privadas probablemente no sean el único contenido "sensible" que va a entregar: tenga en cuenta que con las distribuciones de escritorio de Linux de hoy en día es MUY fácil configurar una computadora portátil que se basa en "cifrado "sistema de archivos (el /homecomo iniciador, pero el conjunto /si es necesario). Entonces, por favor, considere esto también.

Todo lo anterior, obviamente, NO se aplica si NO confía en SU PROPIO cuaderno.

PD: en cuanto a su posibilidad de almacenar las dos mitades de la clave privada sin cifrar en diferentes medios: le recomiendo encarecidamente que no haga esto, ya que mantener las dos piezas de contenido confidencial en una forma no cifrada es mucho, mucho peor, que mantener dos ¡copias completas de todo el contenido, encriptadas!

— Damiano Verzulli
fuente

La primera parte de su pregunta ya ha sido respondida por una respuesta previa. Según su segunda parte, recomendaría agregar un segundo factor a su inicio de sesión ssh usando pam_google_authenticator. Es bastante fácil de configurar y configurar en cualquier distribución. En el caso de que le roben la clave privada que lleva consigo, no podrán iniciar sesión en su servidor sin la contraseña única de TOTP de google-authenticator.

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

— Arul Selvan
fuente