[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