[kwlug-disc] Setting shell to a script

[Paul Nijjar]

After re-reading my original posting I realize that I was not being
very clear. I am relatively happy with the SSH lockdown as-is. I am
less happy with local logins. 

The whitelisting script that I pointed to does appear to lock down SSH
connections okay. It is based upon the 'command=' feature Tim
mentioned. 

My concern is with non-SSH access to the account. There is no password
on this account so I think (?) that nobody should be able to log in
interactively, but I am not certain of this, and in the spirit of
paranoia I am wondering if I can further lock down the account so that
if somebody was to authenticate with a non-SSH method they would not
be able to do anything. It is probably not worth spending a lot of
time on this, but given that I am thinking about security now it would
be nice to add as many layers of defence as I can. 

Setting the user shell to /bin/bash allows me to SSH with the
whitelist, but it would be nice if things were tighter. 

Setting the user shell to /usr/bin/rssh does work, but is less secure.
I can configure RSSH to allow my user only to use rsync. Then if
somebody tries to log in (say via sudo -s) then they are denied. But
this is less secure than the whitelist for SSH, because it will allow
*any* rsync command, and the whitelist restricts the commands that are
allowed. RSSH will not allow me to run the whitelist script. 
(Allowing any rsync command is terrible because then an attacker can
rsync in any user-controlled file, including authorized_keys.)

Setting the user shell to /sbin/nologin or equivalent does not work
any better than /bin/false. 

I did not try /bin/rbash but I am pretty sure it is useless unless I
go through a bunch of other work to set up a chroot. 

Setting the user shell to the whitelist script does work (!). If
somebody connects via SSH they can only run a whitelisted command.[1] If
somebody uses sudo -s they get kicked out immediately. But I do not
know whether setting a shell to an arbitrary Python script is a bad
idea. The script is not particularly hardened, and Python offers a big
attack surface. In my defence the only user input that is allowed is
SSH_ORIGINAL_COMMAND, but unlike Chris I am running this directly (but
only for commands in the whitelist). So I am still wondering whether
this idea is really stupid or whether it does (nominally) increase the
security of the system. How difficult is it for somebody to break out
of an arbitrary, no-input Python script to get a shell?

- Paul

[1] I think (but have not yet verified) that this is happening because
SSH calls the shell when it logs in BEFORE executing whatever is in
'command='. So the 'command=' invocation is being ignored. 


On Wed, Sep 04, 2019 at 10:18:28PM -0400, Tim Laurence wrote:
> By editing you authorized_keys file you can also force ssh to execute a
> specific command on login. This will mean whenever a certain key is used it
> will automatically launch a specified command such as the remote end of a
> rsync client.
> 
> https://manpages.debian.org/buster/openssh-server/authorized_keys.5.en.html
> 
> Look for the 'command=' on the man page above to find the option that does
> this.
> 
> --Tim
> 
> On Wed, Sep 4, 2019 at 5:55 PM Jason Eckert <jason.eckert at gmail.com> wrote:
> 
> > Have you tried using /sbin/nologin instead of /bin/false?
> >