2

EDIT: After much digging, this is almost certainly a result of /etc/profile.d/... being called before rbash is executed, and therefore not a problem with restricted bash in itself.

There seems to be a trivial rbash circumvention, whereby an SSH user can simply request that bash be executed.

The environment consists of a restricted $PATH, with a tiny subset of commands available. The id command is not available, which is what I base the following transcript on:

testuser@jumphost:~$ id
-rbash: id: command not found

.. but then ..

testuser@jumphost:~$ ssh localhost "bash"
testuser@localhost's password:  
id
uid=3033(testuser) gid=4033(jumpuser) groups=5033(foogroup) context=jumpuser_u:jumpuser_r:jumpuser_t:s0

..bash gets called; restricted shell has been circumvented.

I've tried to implement rbash being called via a Match Group / ForceCommand in the sshd_config, and while this does call rbash for me, the problem of being able to simply execute bash still exists.

We are not using public keys by default for the external users due to logistical reasons, so the ability to "command=" in the ~/.authorized_keys file is not an option. We'd also like to offer more than just ssh to the users.. a kinit / klist as well a few other menial programs.

Is there a mechanism to restrict this behaviour?

7
  • depends on what you want to allow to execute.
    – Jakuje
    Jul 21, 2016 at 12:35
  • @Jakuje - Let's say that only the ssh command should be available on the system, to jump further into the network. Jul 21, 2016 at 13:08
  • For that you don't even need a shell access. There is the -W switch doing that using only IO forwarding.
    – Jakuje
    Jul 21, 2016 at 13:11
  • @Jakuje - thank you for the reply. It turns out that our local requirements dictate that a user should be able to jump onto the box itself. My concern is the circumvention around rbash though. Jul 21, 2016 at 13:22
  • This looks more like a configuration issue. A properly setup restricted shell should not be able to execute the normal bash and properly setup SSH restrictions should not allow execution of arbitrary commands. Migrating the question will probably not help much because it is missing the information which are needed to help, i.e. the specific parts of the configuration. Jul 23, 2016 at 6:08

1 Answer 1

0

In closing, the solution was to better control the initial environment between the time of successful authentication, and the calling of rbash.

This was achieved with a wrapper shell which calls a "clean" bash with the flags --restricted, --rcfile ..., --noprofile, etc.... and a default case which logs the attempt at execution before exiting.

With apologies for the alarmist title...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.