Como veras, la respuesta a tus preguntas depende mucho del entorno al que nos estemos refiriendo: No es lo mismo un servidor SSH accesible desde Internet, que otro sólo accesible desde una red privada. Mi punto de vista es que las medidas de seguridad deben ser proporcionales a la “sensibilidad” del servidor accedido.

1. El uso de “archivos de llave” es comodo, pero hay que tener en cuenta que si no está protegido, si alguien te lo “copia” tiene todo lo necesario para acceder. En cuestiones seguridad el principio “Algo que tengo” y “Algo que se” es una buena práctica. Para mi el uso de “passphrase” es imprescindible. Ten en cuenta que es un proceso que se hace en tu equipo, la “passphrase” no viaja en ningún momento fuera.
2. Es posible usar un mismo fichero de llave pública en tantos servidores como desees. Efectivamente, tal como comentas, esta labor se hace a través del fichero authorized_keys
3. Normalmente, es buena prácitca evitar el login directo del usuario root. En su lugar es adecuado crear un usuario alternativo (“adminssh”) y posteriormente hacer un su

En fin, como puedes ver en mis respuestas hay muchos “condicionales”, en estas materias cada administrador de sistemas tiene sus costumbres/buenas prácticas preferidas.

Un saludo.

1. Si es buena idea deshabilitar el login de usuario por contraseña en sshd_config (PasswordAuthentication no) y que la conexión se establezca ÚNICAMENTE con el par de llaves. Entiendo que de ser así, lo que se gana es la imposibilidad de atacar la contraseña del usuario mediante fuerza bruta, ya que al atacante necesitaría la llave privada, más difícil de obtener si no es por intrusión y robo. En caso de ser buena práctica: ¿es necesario proteger la llave privada mediante phrase?, ¡al final estamos introduciendo una clave para el acceso como en login shell!

2. ¿Una llave creada por el usuario fulano en el host1 puede ser usada por el usuario mengano en el host2? Esto es, ¿debe existir fulano en el host2? De ser posible sería teniendo la llave pública en authorized_keys del host2, entiendo.

3. Si es bueno crear un usuario específico para la conexión, por ejemplo adminssh. Por un lado, es un impedimento más a la hora de perpetrar una intrusión ya que es necesario averiguar un usuario válido de entrada (AllowUsers), por otro lado, en caso de realizarse la intrusión evitamos mostrar los archivos de un usuario común -si los hubiera-. También podría enjaularse al usuario mediante chroot.

3. He leído acerca de la buena práctica de crear una contraseña fuerte para root, pero mi duda es, si se inutiliza el login de root y mediante “su” la conexión es cifrada, ¿realmente es necesario una contraseña fuerte? Esto viene a cuento de que una contraseña larga o compleja es de difícil memorización y tiende a apuntarse en papel o archivo digital, que es de mal hábito.

Gracias.

Los caracteres “extraños” que se ven en fichero que me has enviado son secuencias de escape de la emulación de terminal que empleas parra conectarte al servidor.

¿Puedes verificar que tenes marcada la opción “Printable Output” en la configuración de PuTTY? El cometido de esta opción es precisamente, eliminar dichas secuencias. Asegúrate también estas usando una versión reciente de PuTTY.

Saludos

Gracias,.

Una buena idea eso de tener un manual explicando todas las opciones del PuTTY, tomo nota para futuros posts

PD: Te mando un correo privado y si puedes me envias el fichero de log le echo un vistazo a esos caracteres extraños ….. me pica la curiosidad.

Saludos.

Podría ser un tema de “encoding”. ¿Que aplicación usas para visualizar los logs? Puedes usar Notepad++ si usas Windows, Geany si usas Linux, o SciTE. Todos ellos tienen la posibilidad de cambiar la codificación. Prueba con ISO-8859-1 y UTF-8.

Ya me contaras …..

Muchas gracias por su tiempo.