Me gusta la siguiente configuración para administrar el acceso SSH, que uso en el trabajo para administrar un grupo de usuarios en una pequeña flota de servidores. La seguridad y la facilidad de administración ocupan un lugar destacado en la lista de mis prioridades.
Sus características clave son administrar fácilmente los derechos SSH a través de la membresía de grupo Unix, tener permisos bien definidos y ser seguros de forma predeterminada.
Configuración
Instalar software (opcional pero útil):
yum install members # or apt install members
Agregar grupos:
addgroup --system allowssh
addgroup --system sftponly
En /etc/ssh/sshd_config, asegúrese de que la siguiente configuración sea No:
PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no
Y al final de /etc/ssh/sshd_config, agregue estas dos estrofas:
Match Group allowssh
PubkeyAuthentication yes
Match Group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
(no olvide reiniciar SSH después de editar el archivo)
Explicación
Entonces, ¿qué hace todo esto?
- Siempre deshabilita los inicios de sesión de raíz, como medida de seguridad adicional.
- Siempre deshabilita los inicios de sesión basados en contraseña (las contraseñas débiles son un gran riesgo para los servidores que ejecutan sshd).
- Solo permite el inicio de sesión (pubkey) para los usuarios del
allowsshgrupo.
- Los usuarios del
sftponlygrupo no pueden obtener un shell a través de SSH, solo SFTP.
La administración de quién tiene acceso se realiza simplemente administrando la membresía del grupo (estos cambios entran en vigencia inmediatamente, no se requiere reiniciar SSH):
# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#
Tenga en cuenta que los usuarios de sftp deben ser miembros de ambos sftponly(para asegurarse de que no obtendrán un shell) y de allowssh(para permitir el inicio de sesión en primer lugar).
Más información
Tenga en cuenta que esta configuración no permite inicios de sesión de contraseña ; Todas las cuentas deben usar la autenticación de clave pública. Esta es probablemente la mayor ganancia de seguridad que puede obtener con SSH, por lo que creo que vale la pena el esfuerzo, incluso si tiene que comenzar ahora.
Si realmente no quieres esto, agrega también PasswordAuthentication yesa la Match Group allowsshestrofa. Esto permitirá la autenticación de clave pública y contraseña para los allowsshusuarios.
Esta configuración limita a cualquier sftponlyusuario a su directorio de inicio. Si no quiere eso, elimine la ChrootDirectory %hdirectiva.
Si no desea que el cambiar la raíz de trabajo, es importante que el directorio personal del usuario (y cualquier directorio por encima de ella) es propiedad de root:rooty no puede ser escrito por grupo / otros. Está bien que los subdirectorios del directorio de inicio sean propiedad del usuario y / o se puedan escribir.
Sí, el directorio de inicio del usuario debe ser propiedad de la raíz y no debe poder escribirse para el usuario. Lamentablemente, hay buenas razones para esta limitación. Dependiendo de su situación, ChrootDirectory /homepodría ser una buena alternativa.
Configurar el shell de los sftponlyusuarios /sbin/nologinno es necesario ni perjudicial para esta solución, ya que SSH ForceCommand internal-sftpanula el shell del usuario.
Sin /sbin/nologinembargo, el uso puede ser útil para evitar que inicien sesión de otras maneras (consola física, samba, etc.).
Esta configuración no permite rootinicios de sesión directos a través de SSH; Esto forma una capa adicional de seguridad. Si realmente no necesita conexiones de root directos, cambiar la PermitRootLogindirectiva. Considere configurarlo en forced-commands-only, prohibit-passwordy (como último recurso) yes.
Para obtener puntos de bonificación, eche un vistazo a restringir quién puede surootear; añadir un grupo sistema llamado wheel, y añadir / activar auth required pam_wheel.soen /etc/pam.d/su.