Using this exploit, connected non root users can gain root access. Multiple user machines are more or less a thing of the past. These days most common use case of ssh is logging in to a remote server you already own with root privileges. So most of the users are unaffected by this exploit.
These days most common use case of ssh is logging in to a remote server you already own with root privileges
I only see this in relatively small and "young" teams. In any bigger organization I've worked in, a new user is created for each person who uses the machine.
To root, and you must have a sudo password to get it. It stops both hackers and colleagues who need access to the servers, but can't be trusted with root privileges.
Comments
Using this exploit, connected non root users can gain root access. Multiple user machines are more or less a thing of the past. These days most common use case of ssh is logging in to a remote server you already own with root privileges. So most of the users are unaffected by this exploit.
Are you sure? The text implies that the unsafe path is getting interrupted while parsing a DSA key, which presumably occurs before authentication?
Indeed, remote root is possible.
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion....
I only see this in relatively small and "young" teams. In any bigger organization I've worked in, a new user is created for each person who uses the machine.
I have a script that looks at your github org/team and generates/updates users on-demand then lets you connect.
The script is pretty straightforward, see AuthorizedKeysCommand and https://github.com/{$user}.keys
Certainly, but in my org they're trusted with sudo access (which gets logged to syslog).
I don't think it's best practice to give root privilege to a login account.
What do you give it to?
To root, and you must have a sudo password to get it. It stops both hackers and colleagues who need access to the servers, but can't be trusted with root privileges.