Timothee Ravier de la Red Hat, un întreținător al proiectelor Fedora Silverblue și Fedora Kinoite, a propus o modalitate de a evita utilizarea utilitarului sudo, care folosește bitul suid pentru a escalada privilegiile. În loc de sudo, pentru ca un utilizator normal să execute comenzi cu drepturi root, se propune să folosească utilitarul ssh cu o conexiune locală la același sistem prin intermediul unui socket UNIX și verificarea permisiunilor pe baza cheilor SSH.
Folosirea ssh în loc de sudo vă permite să scăpați de programele suid din sistem și să activați executarea comenzilor privilegiate în mediul gazdă al distribuțiilor care folosesc componente de izolare a containerelor, cum ar fi Fedora Silverblue, Fedora Kinoite, Fedora Sericea și Fedora Onyx. Pentru a restricționa accesul, poate fi utilizată suplimentar confirmarea autorizării folosind un token USB (de exemplu, Yubikey).
Un exemplu de configurare a componentelor serverului OpenSSH pentru acces prin intermediul unui socket Unix local (o instanță sshd separată va fi lansată cu propriul fișier de configurare):
/etc/systemd/system/sshd-unix.socket: [Unitate] Description=OpenSSH Server Unix Socket Documentation=man:sshd(8) man:sshd_config(5) [Socket] ListenStream=/run/sshd.sock Accept=da [Instalare] WantedBy=sockets.target
/ Etc / systemd / system /[e-mail protejat]: [Unitate] Descriere=Daemon de server OpenSSH per conexiune (socket Unix) 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: # Lasă doar autentificarea cu chei PermitRootLogin prohibit-password PasswordAuthentication nu PermitEmptyPasswords nu GSSAPIAuthentication nu # restricționează accesul la utilizatorii selectați AllowUsers root adminusername # Lasă doar utilizarea .ssh/authorized_keys2.authorized. ssh /authorized_keys # enable sftp Subsistem sftp /usr/libexec/openssh/sftp-server
Activați și lansați unitatea systemd: sudo systemctl daemon-reload sudo systemctl enable —acum sshd-unix.socket
Adăugați cheia SSH la /root/.ssh/authorized_keys
Configurarea clientului SSH.
Instalați utilitarul socat: sudo dnf install socat
Suplimentăm /.ssh/config prin specificarea socat ca proxy pentru acces prin intermediul unui socket UNIX: Host host.local User root # Utilizați /run/host/run în loc de /run pentru a funcționa din containere ProxyCommand socat - UNIX-CLIENT: / run/host/run/sshd.sock # Calea către cheia SSH IdentityFile ~/.ssh/keys/localroot # Activați suportul TTY pentru shell-ul interactiv RequestTTY da # Eliminați ieșirea inutilă LogLevel QUIET
În forma sa actuală, utilizatorul adminusername va putea acum să execute comenzi ca root fără a introduce o parolă. Verificarea operațiunii: $ ssh host.local [root ~]#
Creăm un alias sudohost în bash pentru a rula „ssh host.local”, similar cu sudo: sudohost() { if [[ ${#} -eq 0 ]]; apoi ssh host.local "cd \"${PWD}\"; exec \"${SHELL}\" --login" else ssh host.local "cd \"${PWD}\"; exec \»${@}\»» fi }
Verificați: $ sudohost id uid=0(rădăcină) gid=0(rădăcină) grupuri=0(rădăcină)
Adăugăm acreditări și activăm autentificarea cu doi factori, permițând accesul root numai atunci când este introdus un token USB Yubikey.
Verificăm ce algoritmi sunt acceptați de Yubikey existent: lsusb -v 2>/dev/null | grep -A2 Yubico | grep „bcdDevice” | awk „{printează $2}”
Dacă rezultatul este 5.2.3 sau mai mare, utilizați ed25519-sk la generarea cheilor, în caz contrar utilizați ecdsa-sk: ssh-keygen -t ed25519-sk sau ssh-keygen -t ecdsa-sk
Adaugă cheia publică la /root/.ssh/authorized_keys
Adăugați o legătură de tip cheie la configurația sshd: /etc/ssh/sshd_config_unix: PubkeyAcceptedKeyTypes [e-mail protejat],[e-mail protejat]
Limităm accesul la socket-ul Unix doar la utilizatorul care poate avea privilegii ridicate (în exemplul nostru, adminusername). În /etc/systemd/system/sshd-unix.socket adăugați: [Socket] ... SocketUser=adminusername SocketGroup=adminusername SocketMode=0660
Sursa: opennet.ru