-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Hello devs,
I wanted to just point out something that you may know, but that users may not. For complete and secure logging, it is not sufficient to simply set the user shell to sudosh. You must either use ForceCommand or a bastion that disallows users from invoking SSH directly. Otherwise you have the issue of the following session on somehost going (partially) unaudited:
$ ssh user@somehost bash
In this case, even though the user's shell may be set to sudosh, the only things that will be audited are the initial invocation of bash and the stdout/stderr of the bash shell that was invoked. The stdin of the bash session will not be logged, based on my (limited) testing. Apologies if I made a mistake in testing, but this is what it looks like to me
References to ForceCommand and a bastion host are made in the documentation, but I feel that the documentation doesn't do a great job in pointing out this "bypass" (albeit partial) of session logging.
Maybe I am just not reading the README carefully enough, but it seems like this specific case should be called out as a common pitfall as I think a lot of system administrators overlook things like this, unless they have experience in doing basic subversion testing
Feel free to close this with comments if you feel that this is common knowledge and not a risk. Alternately, maybe you can update the README, or invite a PR to improve the README. I just wanted to make sure there was awareness around this common mistake that syadmins tend to make. I've seen this sort of mistake in several environments, not with sudosh, but with similar tools
Thanks