Skip to content
HackIndex logo

HackIndex

SSH Authorized Keys ForcedCommand and Wrapper Audit

2 min read Jan 3, 2026

Once you have access, you check whether SSH access control is being altered via authorized_keys options or server-side forced commands.

This is not about adding persistence. It’s about detecting it, documenting it, and understanding why SSH behavior differs per user.

Check per-user authorized_keys options

The risk pattern is authorized_keys entries with restrictive or unexpected options, especially command=. Those options change what happens when a key authenticates.

On a host where you have filesystem access:

┌──(kali㉿kali)-[~]
└─$ grep -nE 'command=|from=|permitopen=|no-pty|no-port-forwarding|environment=' ~/.ssh/authorized_keys 2>/dev/null

If you can enumerate other users after privilege gain:

┌──(kali㉿kali)-[~]
└─$ sudo find /home -maxdepth 3 -type f -name authorized_keys -print 2>/dev/null
┌──(kali㉿kali)-[~]
└─$ sudo find /home -maxdepth 3 -type f -name authorized_keys -exec grep -nE 'command=|SSH_ORIGINAL_COMMAND|permitopen=|no-pty' {} \; 2>/dev/null

If you find command=, capture the full line in notes. That’s the control point.

Check sshd server-side forced command policy

Server-wide forced commands override interactive shells and can make SSH sessions behave inconsistently across users.

┌──(kali㉿kali)-[~]
└─$ sudo sshd -T 2>/dev/null | grep -iE 'forcecommand|authorizedkeyscommand|permittty|allowtcpforwarding'

Also check config and Match blocks:

┌──(kali㉿kali)-[~]
└─$ sudo grep -nE '^(Match|ForceCommand|AuthorizedKeysCommand|AllowTcpForwarding|PermitTTY|PermitTunnel|PasswordAuthentication|PubkeyAuthentication)' /etc/ssh/sshd_config 2>/dev/null

References