New Subsystem criteria for Match option block in OpenSSH server

Ángel González keisial at gmail.com
Tue May 22 03:06:43 EST 2012


On 21/05/12 09:12, John Olsson M wrote:
> I'm not sure what part you are referring to. What we need to be able to do is to place just the SFTP server in a chroot jail. But I'll give you some background so you can understand better what it is we want to do
>
> We have a box/node/machine/server/whatever that runs SLES as Nicola wrote. This server has two SSH servers running; one on port 22 and one on port 4422. When logging in to port 22 credentials are first verified against /etc/passwd and then an LDAP server is checked if /etc/passwd failed, for port 4422 it is only /etc/passwd that is checked and SFTP subsystem is disabled.
>
> If you just do a "normal" ssh login (without specifying any subsystem) you end up in what we call "COM CLI" which can be thought of as a text-based interface to an information model (you can navigate a tree structure, modify attributes and create objects, etc). This information model will also provide a branch showing a virtual filesystem. Thus this is a completely different animal compared to a Bash shell, it is purely a high level management interface for the server.
>
> Now when connecting to port 22 using an SFTP client, this client may only see the same virtual filesystem that is also visible via the information model. Thus the SFTP server must run in a chrooted environment, but SSH (COM CLI) may not since the COM CLI must be able to access the complete system.
> Connecting to port 4422 gives you a standard Bash shell.
>
> Did this answer your question, or did I answer some other question which you did not ask? :)
>
> /John
Dirty workaround: the port 22 shell is is a setuid wrapper which exits
from the chroot, drops permissions and execs the "COM CLI".


More information about the openssh-unix-dev mailing list