[clug] Wanted: Developer to securely implement a restricted SSH shell
Nathan O'Sullivan
nathan at mammoth.com.au
Mon Jan 4 16:13:07 MST 2010
> Except that the exact command that's run along with it's arguments are contained in the
> authorized_keys file. Once the command is run the stdin/out/err are connected to the
> client. The client doesn't get to specify any arguments.
>
The command specified in authorized_keys is simply passed to the user's
login shell.
My key point was simply that - if it actually runs or not, is up to the
shell.
If you look at my custom shell
http://www.mammothmedia.com.au/~nats/restricted-shell-job.txt
I refuse to run with any command line arguments, so specifying
command="anything" just causes my shell to exit.
I think I prefer that solution, since it means I can let the user just
directly edit their authorized_keys file instead of having to
parse/build it for them.
> I'm just not sure what class of attack you're talking about.
>
Any attack that can trick a shell into doing something its not intended
to. For example, use of .ssh/environment or the LD_PRELOAD* environment
variables. Someone with more experience than me, will know of others I
think.
> BTW the client ssh command probably needs the "-t" to get a ptty.
>
Doesnt seem to be required with my custom shell. With the implementation
in my .txt file, I can do "ssh dom000005 at xenhost" and am dropped into
the domU's console - so my implementation works, I'm just unsure what
else needs locking down.
Regards
Nathan
More information about the linux
mailing list