fix(permission-hardener): ssh-agent gets 755 perms

Replace the commented-out matchwhitelist entry for ssh-agent with an
explicit permission entry (755) for /usr/bin/ssh-agent.

When ssh-agent's matchwhitelist entry was commented out in commit
7a5f8b87af, permission-hardener began resetting it to restrictive
defaults (744), preventing non-root users from executing ssh-agent. This
broke split SSH functionality in Qubes OS for me because I was using
Kicksecure in the vault qube, and ssh-agent runs under a non-root user in
that configuration (see https://forum.qubes-os.org/t/split-ssh/19060).

As noted in the comment, Debian installs with 2755 permissions as a way
to mitigate ptrace attacks, but this rationale doesn't apply due to
kernel.yama.ptrace_scope=2 being set in Kicksecure.

usr/lib/permission-hardener.d/25_default_whitelist_ssh.conf

@@ -5,11 +5,21 @@
 ## "/usr/local/etc/permission-hardener.d/20_user.conf" for your custom
 ## configuration. When security-misc is updated, this file may be overwritten.
 
+## Used for SSH client key management
+## https://manpages.debian.org/bookworm/openssh-client/ssh-agent.1.en.html
+## Debian installs ssh-agent with setgid permissions (2755) and with
+## _ssh as the group to prevent ptrace attacks that could extract
+## private keys from the agent's memory. However, as Kicksecure makes use
+## of kernel.yama.ptrace_scope=2 by default, this is not a concern.
+##
+## ssh-agent is often run under non-root users, so 755 permissions make
+## sense here to avoid breakage.
+/usr/bin/ssh-agent 755 root root
+
 ## Used only for SSH host-based authentication
 ## https://linux.die.net/man/8/ssh-keysign
 ## Needed to allow access to the machine's host key for use in the
 ## authentication process. This is a non-default method of authenticating to
 ## SSH, and is likely rarely used, thus this should be safe to disable.
-#ssh-agent matchwhitelist
 #ssh-keysign matchwhitelist
 #/usr/lib/openssh matchwhitelist