[nycbug-talk] restricted login shell and ssh

George Georgalis george at galis.org
Mon Feb 11 13:37:28 EST 2008

I thought the standard way was to modify the line
used in authorized_keys? eg you can specify "only
allow the rsync command" on the same line you put the
users public key.... note I configure sshd to use
/etc/ssh/auth/${USER}.pub for auth keys, since users
can't normally manage that file anyway... (especially
with pam disabled for ssh) the technique I describe is a
free chapter from the O'Reiley openssh book.

the link seems mostly for kererbos based systems

// George

On Mon, Feb 11, 2008 at 11:31:47AM -0500, Jesse Callaway wrote:
>I popped my hand up and made a statement in the OpenSSH meeting
>recently and made a completely false assertion. Tested it this
>morning. I said that you could still pass commands to the shell (which
>shell I was thinking of, I'm not sure...) if a user has a restricted
>login, such as rsynconly. Hopefully nobody believed me. Anyway, using
>the script referenced below I made a user with a restricted login. I'm
>sure false or nologin would have proved it to myself more readily, but
>I like to take the long way to figure out I'm wrong.
>So I ran
>ssh sinko at server.com "ls -R"
>The ls -R command was passed as an argument to the rsynonly shell, and
>lo! I was not able to issue the command to "the shell" Duh.
>To beat it into my skull I ran
>sftp sinko at server.com
>Here I got the message "Received message too long <some number>"
>Short story is that I was assuming that sshd will pass commands on to
>/bin/sh no matter what. Well, it doesn't. It passes commands on to the
>shell specified in your login config.
>Here is a nice link explaining a little bit about how the subsystems
>(scp, sftp) are called.
>talk mailing list
>talk at lists.nycbug.org

George Georgalis, information system scientist <IXOYE><

More information about the talk mailing list