keypair auth and limiting access to sftp

Peter W peterw at usa.net
Tue Sep 18 02:28:13 EST 2001


On Sun, Sep 16, 2001 at 09:37:55PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> Peter, you may want to check the current snapshot.  On 9/14 I included
> a patch from the OpenBSD tree on subsystem and key pairs.

>      [session.c]
>      command=xxx overwrites subsystems, too

The patch is so small that I don't understand it! I figured it might be more
"correct" to add a subsystem= restriction, so you could, for instance, allow
a user to use sftp but not issue commands; or would that simply be a matter
of listing the subsystem command (e.g. "/usr/libexec/openssh/sftp-server")  
in the command= restriction?

> Hope this helps what you are doing.

I hope so, too. Any idea when this might be rolled out in an official 
release? I think the current behavior does pose security threats, as many 
admins have been using command= and the no-* restrictions in hopes of 
securely allowing things like rsync to work with keypair auth, and the 
ability of clients presenting keypairs that are otherwise tightly restricted 
to use sftp is frightening. It could lead to almost immediate remote shell.
 Step 1) connect with sftp and overwrite authorized_key2
 Step 2) connect with ssh and you have a full shell
Ugh. That attack just hit me.

-Peter

> On Sun, 16 Sep 2001, Peter W wrote:

> > I was about to post on that topic. I would like to see OpenSSH changed
> > so you can have the sftp subsystem installed/available, but *disable*
> > access to the sftp susbsytem on a keypair-by-keypair basis in the
> > authorized_keys2 file, much as one restricts commands with command=
> >
> > As it stands,[0] it is unsafe to depend on authorized_keys2 to restrict
> > a client keypair authentication to some well-defined task.



More information about the openssh-unix-dev mailing list