¿Siempre es mejor colocar authorized_keys en el propio directorio .ssh que en el directorio .ssh de la raíz? [duplicar]

Desde el punto de vista de la seguridad, desea que las personas utilicen sudo y no su (Sudo se puede configurar para que registre toda la actividad, es decir, un registro de auditoría).

aún más sobre la mayoría de * nix root el acceso a ssh está prohibido (la configuración en el archivo de configuración que recomendaría que habilites). esto es para evitar que un SSH (-server) dañado pueda ser utilizado para el acceso ROOT.

Otra seguridad que recomendaría es usar claves cifradas (ya que tiene una contraseña que debe ingresar para su clave no su solicitud de inicio de sesión) y usar un agente para compartir tus claves publicas De lo contrario, todo lo que necesitaría es su clave almacenada para obtener acceso, eliminando uno de los umbrales de seguridad.

aún más, el uso del límite sudo (y su ) solo para las tareas de Administración del Sistema (y solo para aquellas tareas que no se pueden hacer de otra manera) usa groups para el acceso compartido, no el root .

Incluso me atrevería a recomendarle que use diferentes claves por conexión (no reutilice las claves, especialmente la clave id_rsa) y use .ssh / config para establecer qué clave se usará cuando.

- > Aclaración adicional para las "claves diferentes"

La razón por la que usas diferentes claves es que tienes seguridad en capas, hace que sea más fácil revocar una clave y reemplazarla (y no 'olvidar' un servidor antiguo que te bloquea la entrada) y si lo haces por cliente Y la conexión tiene la misma opción en ambos extremos.

Especialmente si controla más de unos pocos servidores, esto puede convertirse en una molestia a largo plazo. para algunos sistemas, incluso tengo más de 1 clave para segregar los permisos y la autoridad (tener varias "zonas de seguridad" en el servidor con diferentes claves (que tienen contraseñas diferentes), de modo que la de acceso de escritura no sea la misma que la de shell acceso.

Otro punto que me gustaría resaltar es que siempre es mejor usar la menor cantidad de permisos posible. Entonces, en lugar de usar su para iniciar sesión como root, use su para convertirse en un usuario diferente (el que tiene permiso de escritura en su carpeta de todos modos, como www-data en ubuntu para las carpetas httpd de apache) de lo que hace, y si realmente necesito usar más permisos (los permisos de cambio y las aplicaciones de instalación son los que más me conviene) usar "sudo [operación] (opciones)" en lugar de simplemente sudo su. No solo deja estos registros de auditoría más limpios, sino que también limita los posibles errores (escribir en la ubicación incorrecta, escribir archivos como root cuando deberían ser propiedad del servidor web, etc.) y requiere que usted sepa qué es lo que está haciendo. En lugar de ir simplemente "hey, funcionó así la última vez".

"Sudo su" es como quitar un muro con una bomba de tubo. elimina la pared, pero un simple martillo podría haber hecho lo mismo (con menos daño colateral posible).

Se trata de administrar un riesgo, como con todas esas cosas.

Si rutinariamente haces todo como root, sugeriría que ese es tu problema, en lugar del mecanismo de inicio de sesión. ¿Por qué? Bueno, porque lo estás haciendo todo con un máximo nivel de privilegio.

Eso sugiere que no ha configurado sus permisos y ACL de manera adecuada. Idealmente, nadie debería alguna vez 'trabajar como root', y simplemente privilegiar escalar ocasionalmente para ejecutar comandos que requieren ese privilegio.

El inicio de sesión directo como root parece más bien un punto discutible, especialmente si no es necesario volver a autenticarse para sudo su .

Personalmente, sugeriría que no hagas una de las dos cosas y en su lugar:

• use sudo para comandos individuales cuando lo necesite.
• funciona normalmente como "tú".
• configure permisos que le permitan a "usted" hacer las cosas que necesita.

Y limita la cantidad de root de actividad que estás haciendo.

En realidad, solo se me ocurren algunos beneficios de seguridad al iniciar sesión como tú mismo y usar sudo en lugar de iniciar sesión como root.

• Las pistas de auditoría están disponibles si no es el único administrador en la máquina (si es el único administrador, esto no se aplica en absoluto)
• Tienes que ingresar tu contraseña para elevar a root con sudo, que brinda protección marginal contra el compromiso clave (esto no es realmente una gran cantidad de seguridad; un adversario inteligente podría hacer algo como cambiar tu PATH). Bashrc y cree su propio script "sudo" que guarda su contraseña la próxima vez que inicie sesión). Este beneficio no se aplica en absoluto si ha configurado sudo para el inicio de sesión sin contraseña.
• Tiene más protección si se aleja de una sesión abierta de SSH sin bloquear la consola (si alguna vez hace esto, estoy revocando su licencia de administrador de sistemas).

En mi opinión, la razón principal por la que la mayoría de las personas recomienda que inicies sesión con una cuenta de usuario normal y te eleves a la raíz para las tareas de administración del sistema solo no es realmente protegerte de los atacantes, es protegerte de ti mismo (eso es accidental). la barra diagonal adicional en rm -rf es mucho menos peligrosa si se ejecuta como usted que como root). Personalmente, si no espero realizar tareas no root en una máquina, no me molestaré en absoluto con la cuenta de usuario normal, simplemente la eliminaré y usaré la raíz (solo).

Si estás paranoico y te gustaría beneficiarte realmente de la protección adicional provista por sudo, agregaría dos claves SSH. Cree uno para la raíz e instálelo en /root/.ssh/authorized_keys, y cree uno para su usuario normal. Edite / etc / sudoers para que solo su cuenta normal pueda realizar tareas específicas que deben realizarse como root de forma rutinaria. Para todo lo demás, asegúrese de que su pertenencia a un grupo le permita realizar las tareas que necesita realizar. La clave de usuario normal va en su computadora. La tecla de raíz va en una unidad flash o tarjeta inteligente / token en una caja fuerte contra incendios. La compensación es la conveniencia (como siempre lo es), pero si realmente crees que necesitas la seguridad adicional, esa es una manera de hacerlo (no es la única manera, solo lo que se me ocurrió).