Timothee Ravier de Red Hat, responsable de los proyectos Fedora Silverblue y Fedora Kinoite, propuso una forma de evitar el uso de la utilidad sudo, que utiliza el bit suid para escalar privilegios. En lugar de sudo, para que un usuario normal ejecute comandos con derechos de root, se propone utilizar la utilidad ssh con una conexión local al mismo sistema a través de un socket UNIX y verificación de permisos basada en claves SSH.
Usar ssh en lugar de sudo le permite deshacerse de los programas suid en el sistema y habilitar la ejecución de comandos privilegiados en el entorno host de distribuciones que usan componentes de aislamiento de contenedores, como Fedora Silverblue, Fedora Kinoite, Fedora Sericea y Fedora Onyx. Para restringir el acceso, se puede utilizar adicionalmente la confirmación de autoridad mediante un token USB (por ejemplo, Yubikey).
Un ejemplo de configuración de los componentes del servidor OpenSSH para acceder a través de un socket Unix local (se iniciará una instancia sshd separada con su propio archivo de configuración):
/etc/systemd/system/sshd-unix.socket: [Unidad] Descripción=OpenSSH Server Unix Socket Documentation=man:sshd(8) man:sshd_config(5) [Socket] ListenStream=/run/sshd.sock Aceptar=yes [Instalar] WantedBy=sockets.target
/ etc / systemd / system /[email protected]: [Unidad] Descripción=Demonio de servidor por conexión OpenSSH (socket Unix) Documentación=man:sshd(8) man:sshd_config(5) Wants=sshd-keygen.target After=sshd-keygen.target [Servicio] ExecStart=- /usr/sbin/sshd -i -f /etc/ssh/sshd_config_unix StandardInput=socket
/etc/ssh/sshd_config_unix: # Deja solo autenticación de clave PermitRootLogin prohibit-password PasswordAuthentication no PermitEmptyPasswords no GSSAPIAuthentication no # restringe el acceso a usuarios seleccionados AllowUsers root adminusername # Deja solo el uso de .ssh/authorized_keys (sin .ssh/authorized_keys2 AuthorizedKeysFile .ssh /authorized_keys # habilitar sftp Subsistema sftp /usr/libexec/openssh/sftp-server
Active e inicie la unidad systemd: sudo systemctl daemon-reload sudo systemctl enable —ahora sshd-unix.socket
Agregue su clave SSH a /root/.ssh/authorized_keys
Configurando el cliente SSH.
Instale la utilidad socat: sudo dnf install socat
Complementamos /.ssh/config especificando socat como proxy para el acceso a través de un socket UNIX: Host host.local Usuario raíz # Use /run/host/run en lugar de /run para trabajar desde contenedores ProxyCommand socat - UNIX-CLIENT: / run/ host/run/sshd.sock # Ruta a la clave SSH IdentityFile ~/.ssh/keys/localroot # Habilitar soporte TTY para el shell interactivo RequestTTY sí # Eliminar salida innecesaria LogLevel QUIET
En su forma actual, el usuario adminusername ahora podrá ejecutar comandos como root sin ingresar una contraseña. Comprobando la operación: $ ssh host.local [root ~]#
Creamos un alias de sudohost en bash para ejecutar “ssh host.local”, similar a sudo: sudohost() { if [[ ${#} -eq 0 ]]; luego ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login" else ssh host.local "cd \"${PWD}\"; ejecutivo \»${@}\»» fi }
Verifique: $ sudohost id uid=0(raíz) gid=0(raíz) grupos=0(raíz)
Agregamos credenciales y habilitamos la autenticación de dos factores, permitiendo el acceso raíz solo cuando se inserta un token USB Yubikey.
Comprobamos qué algoritmos son compatibles con el Yubikey existente: lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{imprimir $2}'
Si el resultado es 5.2.3 o superior, use ed25519-sk al generar claves; de lo contrario, use ecdsa-sk: ssh-keygen -t ed25519-sk o ssh-keygen -t ecdsa-sk
Agrega la clave pública a /root/.ssh/authorized_keys
Agregue un enlace de tipo de clave a la configuración de sshd: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes [email protected],[email protected]
Restringimos el acceso al socket Unix solo al usuario que puede tener privilegios elevados (en nuestro ejemplo, adminusername). En /etc/systemd/system/sshd-unix.socket agregue: [Socket] ... SocketUser=adminusername SocketGroup=adminusername SocketMode=0660
Fuente: opennet.ru