Timothee Ravier de Red Hat, mantenedor de los proyectos Fedora Silverblue y Fedora Kinoite, propuso una forma de evitar el uso de la herramienta sudo, que utiliza el bit suid para elevar privilegios. En lugar de sudo, se sugiere usar la herramienta ssh con una conexión local a la misma sistema a través de un socket UNIX y una verificación de privilegios basada en claves SSH para ejecutar comandos como usuario normal con derechos de root.
El uso de ssh en lugar de sudo permite eliminar programas suid del sistema y organizar la ejecución de comandos privilegiados en entornos host de distribuciones que utilizan aislamiento de componentes basado en contenedores, como Fedora Silverblue, Fedora Kinoite, Fedora Sericea y Fedora Onyx. Para restringir el acceso, se puede implementar una verificación de privilegios utilizando un token USB (por ejemplo, Yubikey).
Ejemplo de configuración de componentes del servidor OpenSSH para acceder a través de un socket Unix local (se ejecutará una instancia separada de sshd con su propio archivo de configuración):
/etc/systemd/system/sshd-unix.socket: [Unit] Description=OpenSSH Server Unix Socket Documentation=man:sshd(8) man:sshd_config(5) [Socket] ListenStream=/run/sshd.sock Accept=yes [Install] WantedBy=sockets.target
/etc/systemd/system/sshd-unix@.service: [Unit] Description=OpenSSH per-connection server daemon (Unix socket) Documentation=man:sshd(8) man:sshd_config(5) Wants=sshd-keygen.target After=sshd-keygen.target [Service] ExecStart=-/usr/sbin/sshd -i -f /etc/ssh/sshd_config_unix StandardInput=socket
/etc/ssh/sshd_config_unix: # Оставляет только аутентификацию по ключам PermitRootLogin prohibit-password PasswordAuthentication no PermitEmptyPasswords no GSSAPIAuthentication no # ограничиваем доступ выбранным пользователям AllowUsers root adminusername # Оставляем только использование .ssh/authorized_keys (без .ssh/authorized_keys2 AuthorizedKeysFile .ssh/authorized_keys # включаем sftp Subsystem sftp /usr/libexec/openssh/sftp-server
Activamos y arrancamos la unidad systemd: sudo systemctl daemon-reload sudo systemctl enable —now sshd-unix.socket
Añadimos nuestra clave SSH en /root/.ssh/authorized_keys
Configuramos el funcionamiento del cliente SSH.
Instalamos la herramienta socat: sudo dnf install socat
Añadimos a /.ssh/config, especificando socat como proxy para acceder a través del socket UNIX: Host host.local User root # Usamos /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 # Habilitamos soporte TTY para el shell interactivo RequestTTY yes # Eliminamos salida adicional LogLevel QUIET
En su forma actual, el usuario adminusername ahora podrá ejecutar comandos con derechos de root sin introducir una contraseña. Verificamos el funcionamiento: $ ssh host.local [root ~]#
Creamos un alias en bash sudohost para ejecutar «ssh host.local» de forma similar a sudo: sudohost() { if [[ ${#} -eq 0 ]]; then ssh host.local «cd \»${PWD}\»; exec \»${SHELL}\» —login» else ssh host.local «cd \»${PWD}\»; exec \»${@}\»» fi }
Verificamos: $ sudohost id uid=0(root) gid=0(root) groups=0(root)
Añadimos verificación de privilegios e implementamos autenticación de dos factores, permitiendo el acceso a root solo con la inserción de un token USB Yubikey.
Verificamos qué algoritmos soporta el Yubikey existente: lsusb -v 2>/dev/null | grep -A2 Yubico | grep «bcdDevice» | awk ‘{print $2}’
Si se muestra un valor de 5.2.3 o superior, usamos ed25519-sk para generar claves, de lo contrario, ecdsa-sk: ssh-keygen -t ed25519-sk o ssh-keygen -t ecdsa-sk
Agrega la clave pública a \/root\/.ssh\/authorized_keys
Agregamos la vinculación al tipo de clave en la configuración de sshd: \/etc\/ssh\/sshd_config_unix: PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com
Limitar el acceso al socket UNIX solo al usuario que puede elevar privilegios (en nuestro ejemplo, adminusername). En \/etc\/systemd\/system\/sshd-unix.socket agregamos: [Socket] … SocketUser=adminusername SocketGroup=adminusername SocketMode=0660
Fuente: opennet.ru
