Este post no va a ser alta tecnología pero supongo que a más de uno le ayudará. Ya nos meteremos con cosas más chungas más adelante 
Primero de todo una pequeña introducción, SSH (Secure Shell) es un programa que permite autenticarnos en máquinas remotas, ejecutar comandos, mover archivos, etc. Proporciona una capa de seguridad cifrando el tráfico y permitiendo usar distintas técnicas: AES, 3DES, Blowfish, Twofish, Arcfour, CAST, DES. Supone una alternativa a rlogin, rsh, rcp, rdist y está protegido de ataques como IP spoofing, IP source routing y DNS spoofing. En este caso vamos a usar OpenSSH.
Para que nos entendamos bien seguiré las siguientes directrices, pondré en azul lo que sea edicición de archivos y en verde lo que sean órdenes. Yo uso Gentoo así que me basaré en esta distribución aunque por supuesto con unos mínimos cambios todo lo descrito aquí sería portable a cualquier otra distribución incluso a otros sistemas tipo unix.
Dependiendo de la distribución el paquete openssh puede constar de un sólo paquete, como es el caso de Gentoo, o de varios paquetes (normalmente uno para el cliente y otro para el servidor, como es el caso de Ubuntu y por lo tanto supongo que Debian).
Para instalar el servidor en Gentoo e iniciarlo por defecto:
|
# emerge openssh # rc-update add sshd default # /etc/init.d/sshd start |
Para conectarnos a máquina con el cliente:
|
$ ssh user@hostname |
Por defecto ssh usa el puerto 22 y podemos no especificar el usuario, en ese caso el cliente intentará usar el mismo nombre de usuario de la máquina local que ejecuta el cliente. En el caso de que se use un puerto distinto al predeterminado se puede especificar de la siguiente manera:
|
$ ssh -p xxxxx user@hostname |
En la parte del cliente por defecto si usamos sftp no tendremos el típico ‘line completion’ que tenemos de normal en bash, para disponer de ellos deberemos compilar el paquete con la flag libedit.
Cuando se está corriendo iptables en el servidor es necesario abrir las conexiones para el puerto 22 así que podríamos añadir la siguiente linea en nuestro script de iptables:
|
iptables -A INPUT -p tcp -m state –state NEW -m tcp –dport 22 -j ACCEPT |
El primer paso antes de hacer más complejo el setup es configurar adecuadamente el propio servicio.
Editando /etc/ssh/sshd_config:
|
… Port 22 Protocol 2 ListenAddress 192.168.1.100 AllowUsers user1 user2 user3 #AllowGroups … PermitRootLogin no StrictModes yes MaxAuthTries 3 … PermitEmptyPasswords no ChallengeResponseAuthentication yes UsePam yes AllowTCPForwarding yes … PrintLastLog yes TCPKeepAlive yes PermitUserEnvironment no UsePrivilegeSeparation yes |
Exiiste una opción interesante que por defecto no se incluye en el archivo de configuración, ésta es AllowUsers y permite que sólo puedan acceder los usuarios especificados. En un servidor en el que todos los usuarios van a entrar remotamente no tiene sentido pero para el ordenador de tu casa sí, de este modo puedes tener tu usuario con acceso pero el usuario de tu abuela/hermana/madre cuyo password coincide con su user está denegado. Del mismo modo funcionaría AllowGroups.
Una vez hemos configurado el servidor de SSH podemos ir ajustado otras opciones del sistema. Por ejemplo, mediante PAM, podemos bloquear una cuenta después de varios intentos fallidos de autenticación. Modificando /etc/pam.d/sshd:
#%PAM-1.0 auth required pam_stack.so service=system-auth auth required pam_tally.so onerr=fail no_magic_root auth required pam_shells.so auth required pam_nologin.so account required pam_stack.so service=system-auth account required pam_tally.so onerr=fail no_magic_root deny=4 password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth |
En este ejemplo la cuenta se bloquearía al cuarto intento. Esto por supuesto se podría usar para bloquear intentos fallidos en el sistema entero, no sólo SSH.
Para desbloquear este estado se puede crear una tarea que se ejecute todas las horas, en /etc/cron.hourly/pam_tally_reset
|
#!/bin/bash pam_tally –reset |
Por supuesto, no hay que olvidar de darle permisos de ejecución al archivo:
# chmod a+x /etc/cron.hourly/pam_tally_reset |
Se podría configurar para poder acceder sin contraseñas mediante intercambio de claves y key fingerprints pero según mi punto de vista no es lo más recomendable si tienes varias máquinas porque el hecho de que te comprometan una máquina te compromete varias. En el caso de que se use, es muy importante ajustar bien los permisos de los archivos donde se guardan las claves para que no puedan ser leídos por otros usuarios.
En las próximas entregas veremos otras maneras de controlar los accesos fallidos, algo de túneles, X forwarding y como enjaular el servicio de diferentes maneras. Cualquier corrección o ampliación será bienvenida. ¡Hasta entonces!
–
Fuente original en http://vierito.es/wordpress
3 responses so far ↓
1 kuasar // Mar 30, 2008 at 3:39 am
“PAM! y te entruñan!”
xDDDDDDDD
2 dares6 // Mar 31, 2008 at 1:49 pm
mus
3 Dejar bonito un server SSH - Parte 2 | It should work... // Mar 31, 2008 at 5:50 pm
[...] RSS ← Dejar bonito un server SSH – Parte 1 [...]
Leave a Comment