Bug#1038150: openssh-client: Please add the openssh-client group rename from "ssh" to "_ssh" to the bookworm release notes

On Fri, 16 Jun 2023 at 02:43:29 +0200, Alban Browaeys wrote:
>I cannot login anymore via ssh.
>I have the openemediavault installed on this box to manage the setup and
>it set AllowGroups to "root ssh" in /etc/ssh/sshd_config.
...
>After the request from a user to rename the "ssh" group to free it for its
>own use, the "ssh" group was rename to "_ssh" in
>https://salsa.debian.org/ssh-team/openssh/-/commit/18da782ebe789d0cf107a550e474ba6352e68911
>
>But other users as in
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990456#35 or tools to
>manage Debian have come to rely on this "ssh" group.

I believe the openssh maintainers' position on this would be that the 
ssh group was never intended to have ordinary users added to it, and 
therefore this would be a bug in "openemediavault", which seems to be 
third-party software that is not included in Debian?

The purpose of the group formerly named ssh (now _ssh) was documented in 
the openssh changelog in 2002:

   * New upstream release.
     ...
     - ssh-agent is installed setgid to prevent ptrace() attacks. The group
       actually doesn't matter, as it drops privileges immediately, but to
       avoid confusion the postinst creates a new 'ssh' group for it.

If a sysadmin or a piece of third-party software wants to limit ssh 
logins to members of a specific group, I believe the intention is that 
they should have created a separate group for that purpose (perhaps 
"ssh-users" or "remote-access" or similar) and added their ssh users to 
*that* group. Since bookworm, the "ssh" group name is available for that 
use, although it might be best avoided.

Unfortunately, /etc/group doesn't have a mechanism for pointing to 
documentation about the intended purpose of a group, so it's easy for a 
sysadmin or a piece of third-party software to start using a group for 
an unintended purpose, and I think that's what has happened here.

     smcv