1 This program (call it `sh.ssh` or `bash.ssh`) is intended to set as login shell for users
2 who should be limited what they can run over ssh.
4 `sh.ssh` looks up which commands (shell command lines) are allowed by the invoking
5 user's group membership. It looks up `/etc/ssh/AllowGroupCommands` file.
8 Using `sh.ssh` as login shell enables sysadmins to:
10 - allow `~/.ssh/rc` system wide
11 - but don't allow it here anyone only for certain groups
12 - users still can write their files including `~/.ssh/rc`
13 - allow both password and pubkey auth
14 - because running `~/.ssh/rc` can only be disabled globally or per-pubkey
15 - while not worrying about arbitrary commands called by `~/.ssh/rc`
16 - because it is not allowed here only for certain groups
19 However being a login shell does not only play role at login, other programs like
20 to invoke it when they run any shell command line, so `sh.ssh` have check whether it is
21 invoked as part of a login process or just casually. So it has a "controlled" mode
22 and a "permissive" mode. The logic is the following:
24 - is `SHELL_DIRECTLY_BY_SSHD` env var set? -> controlled mode
25 - it's a good idea to set it by `/etc/pam.d/sshd`.
26 eg: `session required pam_env.so envfile=/etc/ssh/env user_readenv=0`
27 and put `SHELL_DIRECTLY_BY_SSHD=1` in `/etc/ssh/env`.
28 - parent process owner different than us or is it root? -> controlled mode
29 - parent process execuable ends in `/sshd` or `/dropbear`? -> controlled mode
30 - otherwise -> permissive mode
31 - it's highly recommended to set `SHELL_DIRECTLY_BY_SSHD` environment
32 because process ownership and process command name checks are less reliable
33 and is not robostly tested on different systems.