Timothee Ravier de Red Hat, mantedor dos proxectos Fedora Silverblue e Fedora Kinoite, propuxo un xeito de evitar o uso da utilidade sudo, que usa o bit suid para aumentar os privilexios. En lugar de sudo, para que un usuario normal execute comandos con dereitos de root, proponse utilizar a utilidade ssh cunha conexión local ao mesmo sistema a través dun socket UNIX e a verificación dos permisos baseados en claves SSH.
Usar ssh en lugar de sudo permítelle desfacerse dos programas suid do sistema e habilitar a execución de comandos privilexiados no ambiente host de distribucións que usan compoñentes de illamento de contedores, como Fedora Silverblue, Fedora Kinoite, Fedora Sericea e Fedora Onyx. Para restrinxir o acceso, pódese utilizar adicionalmente a confirmación da autorización mediante un token USB (por exemplo, Yubikey).
Un exemplo de configuración de compoñentes do servidor OpenSSH para acceder a través dun socket Unix local (unha instancia sshd separada lanzarase co seu propio ficheiro de configuración):
/etc/systemd/system/sshd-unix.socket: [Unidade] Descrición=Documentación do socket Unix do servidor OpenSSH=man:sshd(8) man:sshd_config(5) [Socket] ListenStream=/run/sshd.sock Accept=si [Instalar] WantedBy=sockets.target
/ etc / systemd / system /[protexido por correo electrónico]: [Unidade] Descrición=Daemon de servidor OpenSSH por conexión (socket Unix) Documentation=man:sshd(8) man:sshd_config(5) Wants=sshd-keygen.target After=sshd-keygen.target [Servizo] ExecStart=- /usr/sbin/sshd -i -f /etc/ssh/sshd_config_unix StandardInput=socket
/etc/ssh/sshd_config_unix: # Deixa só a autenticación de chave PermitRootLogin prohibit-password PasswordAuthentication non PermitEmptyPasswords non GSSAPIAuthentication no # restrinxe o acceso aos usuarios seleccionados AllowUsers root adminusername # Deixa só o uso de .ssh/authorized_keys2.authorized. ssh /authorized_keys # activar sftp Subsistema sftp /usr/libexec/openssh/sftp-server
Activa e inicia a unidade systemd: sudo systemctl daemon-reload sudo systemctl enable —agora sshd-unix.socket
Engade a túa chave SSH a /root/.ssh/authorized_keys
Configurando o cliente SSH.
Instale a utilidade socat: sudo dnf install socat
Complementamos /.ssh/config especificando socat como proxy para o acceso a través dun socket UNIX: Host host.local User root # Use /run/host/run en lugar de /run para traballar desde contenedores ProxyCommand socat - UNIX-CLIENT: / run/ host/run/sshd.sock # Ruta á chave SSH IdentityFile ~/.ssh/keys/localroot # Activar o soporte TTY para o shell interactivo RequestTTY yes # Eliminar a saída innecesaria LogLevel QUIET
Na súa forma actual, o usuario adminusername agora poderá executar comandos como root sen introducir un contrasinal. Comprobando a operación: $ ssh host.local [root ~]#
Creamos un alias de sudohost en bash para executar “ssh host.local”, semellante a sudo: sudohost() { if [[ ${#} -eq 0 ]]; entón ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login" else ssh host.local "cd \"${PWD}\"; exec \»${@}\»» fi }
Comprobe: $ sudohost id uid=0(root) gid=0(root) groups=0(root)
Engadimos credenciais e activamos a autenticación de dous factores, permitindo o acceso root só cando se insire un token USB Yubikey.
Comprobamos que algoritmos son compatibles coa Yubikey existente: lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{print $2}'
Se a saída é 5.2.3 ou superior, use ed25519-sk ao xerar claves; se non, use ecdsa-sk: ssh-keygen -t ed25519-sk ou ssh-keygen -t ecdsa-sk
Engade a chave pública a /root/.ssh/authorized_keys
Engade unha ligazón de tipo de clave á configuración sshd: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes [protexido por correo electrónico],[protexido por correo electrónico]
Restringimos o acceso ao socket Unix só ao usuario que pode ter privilexios elevados (no noso exemplo, adminusername). En /etc/systemd/system/sshd-unix.socket engade: [Socket] ... SocketUser=adminusername SocketGroup=adminusername SocketMode=0660
Fonte: opennet.ru