Autentificación de clave pública SSH vs Nombre de usuario / contraseña para acceso a API

Hay varias diferencias.

Primero, al configurar su servidor de API para que acepte el nombre de usuario / contraseña (en lugar de permitir solo el acceso mediante claves, lo que es cada vez más una buena práctica) puede disminuir su seguridad en general, ya que, ahora, los usuarios con poca capacidad las contraseñas en el sistema (o, lo que es peor, los servicios que instala que pueden tener contraseñas predeterminadas codificadas) harán que sea posible violar su servidor. Los ataques de fuerza bruta son repentinamente una opción para aquellos que desean ingresar a su sistema (que, si ejecuta un servidor SSH en una IP pública, tiene garantía para ver casi de inmediato). Deshabilitar el inicio de sesión en ssh a través de contraseñas y requerir claves de inicio de sesión es tan simple como configurar: "PasswordAuthentication no" en su sshd_config y reiniciar el servicio sshd (o su servidor). Hago esto en cada caja de Linux que construyo como uno de los primeros pasos. Además, esto fomenta la configuración de una contraseña muy larga y aleatoria, ya que (si configura / etc / sudeoers correctamente) nunca lo usará para nada. :)

En segundo lugar, con la opción de clave ssh, puede configurar fácilmente el archivo authorized_keys de manera que:

1. Solo permitir el acceso desde una IP específica; y
2. Permitir solo que el usuario / script que accede acceda a un determinado comando.

De esta manera, incluso si alguien compromete la caja de su cliente, la clave robada no se puede usar para iniciar sesión en su servidor desde cualquier otro lugar del mundo, y , si la configura correctamente, ni siquiera se puede utilizar para iniciar sesión desde su cliente para otra cosa que no sea lo que usted permitió. Por ejemplo, uso esto para configurar cuentas / claves que no pueden hacer nada excepto rsync con ciertas opciones de una carpeta determinada. Entonces, incluso si la clave fue robada, el atacante no gana nada más que poder ejecutar el comando de que la máquina cliente se está ejecutando de todos modos, y solo desde la IP del cliente, en ninguna otra parte. Es decir, obtener la clave no ha permitido al atacante comprometer el servidor API. Es posible que pueda restringir una cuenta que esté basada en una contraseña para ejecutar solo un determinado comando o solo iniciar sesión desde una IP determinada, pero nunca he visto esto hecho y no sé qué tan fácil es.

En tercer lugar, cuando desee dar acceso a su servidor de API a otra persona / sistema en el futuro, y desee usar contraseñas, se encontrará con el problema de distribución de claves (lo suficientemente irónico). Es decir, debe tener un canal seguro para intercambiar la contraseña de la cuenta inicial para que el usuario pueda iniciar sesión. Con las claves SSH, todo lo que tienen que hacer es enviarles por correo electrónico su clave pública (que no es algo que necesite seguridad), y ( Siempre que confíe en que el correo electrónico proviene de ellos, hay formas de garantizarlo, y puede darles acceso.

Por lo tanto, espero que esto lo haya convencido de que hay valor en el uso de claves (y, en realidad, no debería usar el acceso de solo contraseña en nada; las claves o 2FA para servicios públicos son la única manera de ir :-) ). Aclamaciones.

  

¿Por qué se considera mejor la autorización SSH? Me refiero a si alguien   obtiene acceso a mi máquina linux, entonces pueden leer ambos   nombre de usuario / contraseña O la clave SSH y luego pueden copiar estos   información a su propia computadora portátil.

Sí, es cierto, si alguien obtiene acceso completo a su máquina, tiene problemas de cualquier manera.

  

¿Me estoy perdiendo algo aquí?

Sí. Todas las situaciones en las que un atacante aún no ha obtenido acceso completo a su máquina. Hay ataques fácilmente implementados que son posibles con la autenticación de nombre de usuario / contraseña que no son posibles con las claves SSH.

Bueno, si elimina la idea de nombre de usuario / contraseña (que no es seguro en absoluto para este uso) podría implementar un entorno chroot para que el ssh-client se conecte. utilizando el cifrado de clave pública ECDSA o RSA, (usted envía la clave privada con la aplicación y almacena las claves autorizadas fuera del chroot).

Especialmente si crea un "buzón" para que escriban los clientes, o cree un archivo especial FIFO / LIFO con solo acceso de escritura desde el entorno chroot. puede dejar que el cliente escriba de forma segura en el servidor sin darle ningún acceso de lectura.

Si solo es un archivo que desea cargar, utilice el cliente sFTP incorporado de ssh. Esto significaría que solo puede cargar un archivo directamente, sin dar acceso al shell en absoluto en el entorno chroot.

Si activa la conexión ssh a través de un script en el "cliente", no necesita tener un archivo ssh.config. Solo puede especificar los argumentos de línea de comando que desea en el script.

En cuanto a por qué una clave es mejor, desde el punto de vista de la seguridad, solo tenemos que ver cómo el sistema SSH usa las claves:

• El cliente SSH solicita un servidor SSH (qué tipo de versión / intercambio de claves / autenticación admite)
• El servidor SSH responde con capacidades y token de clave pública.
• El cliente SSH responde con un "token de cifrado" codificado en secreto (una operación del token de clave pública con algo de magia de cifrado) que está firmado con su clave privada.
• El servidor SSH autentica la firma (la clave pública descifra el mensaje) y valida el token de cifrado, luego responde su propio token de cifrado, utilizando formas similares a las del cliente.
• El cliente SSh valida el token de cifrado recibido.
• El servidor SSH configura un túnel seguro utilizando las nuevas claves. que comienza el shell.

• ssh-client configura el punto final del túnel seguro e inicia el proxy de shell.

  conexión ssh yaay establecida.

Le sugiero que lea sobre SSH y las claves y chroot para comprender mejor lo que está tratando de hacer.