sftp server with chrootdirectory setup - SSH

This is a discussion on sftp server with chrootdirectory setup - SSH ; Hi, I want to setup a sftp ONLY server using openssh with internal-sftp and chrootdirectory feature. The sftp does work fine. It did what I expect. I can chroot, uploading/downloading,etc. But I want that ssh and scp are both denied ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: sftp server with chrootdirectory setup

  1. sftp server with chrootdirectory setup

    Hi,

    I want to setup a sftp ONLY server using openssh with internal-sftp
    and chrootdirectory feature. The sftp does work fine. It did what I
    expect. I can chroot, uploading/downloading,etc. But I want that ssh
    and scp are both denied at user's login, e.g, displaying an error
    message stating 'account not availabe', something like that. But with
    internal-sftp and chrootdirectory, the ssh session will hang, same
    thing for scp. I have tried openssh version 4.9, 5.0, 5.1. They are
    all same behavior. The configuration for sftp part looks like the
    following:

    Subsystem sftp internal-sftp
    Match Group sftponly
    ForceCommand internal-sftp
    ChrootDirectory %u

    The user's shell is set to /sbin/nologin. I tried on Fodera system.

    Any help?

    --xinhuan

  2. Re: sftp server with chrootdirectory setup

    xaz wrote:
    > Hi,
    >
    > I want to setup a sftp ONLY server using openssh with internal-sftp
    > and chrootdirectory feature. The sftp does work fine. It did what I
    > expect. I can chroot, uploading/downloading,etc. But I want that ssh
    > and scp are both denied at user's login, e.g, displaying an error
    > message stating 'account not availabe', something like that. But with
    > internal-sftp and chrootdirectory, the ssh session will hang, same
    > thing for scp. I have tried openssh version 4.9, 5.0, 5.1. They are
    > all same behavior. The configuration for sftp part looks like the
    > following:
    >
    > Subsystem sftp internal-sftp
    > Match Group sftponly
    > ForceCommand internal-sftp
    > ChrootDirectory %u
    >
    > The user's shell is set to /sbin/nologin. I tried on Fodera system.
    >
    > Any help?
    >
    > --xinhuan


    Basically, don't bother. Building a real chroot cage for OpenSSH is beyond the
    work most of us are willing to invest, and it's a packaging nightmare.
    Additionally, the new OpenSSH 5 chroot cage facility puts all the clients in
    the same chroot cage, which is also problematic.

    This is a lot of work, and is easily replaced with an HTTPS/WebDAV setup. That
    gives far more flexibility, the clients are built into Windows Network
    Neighborhood and various popular Linux tools such as lftp, and it allows quite
    a lot more refined control over upload/download/access privileges.

  3. Re: sftp server with chrootdirectory setup

    In article <488DF3D2.3010309@gmail.com> Nico Kadel-Garcia
    writes:
    >xaz wrote:
    >> Hi,
    >>
    >> I want to setup a sftp ONLY server using openssh with internal-sftp
    >> and chrootdirectory feature. The sftp does work fine. It did what I
    >> expect. I can chroot, uploading/downloading,etc. But I want that ssh
    >> and scp are both denied at user's login, e.g, displaying an error
    >> message stating 'account not availabe', something like that. But with
    >> internal-sftp and chrootdirectory, the ssh session will hang, same
    >> thing for scp. I have tried openssh version 4.9, 5.0, 5.1. They are
    >> all same behavior. The configuration for sftp part looks like the
    >> following:
    >>
    >> Subsystem sftp internal-sftp
    >> Match Group sftponly
    >> ForceCommand internal-sftp
    >> ChrootDirectory %u
    >>
    >> The user's shell is set to /sbin/nologin. I tried on Fodera system.
    >>
    >> Any help?


    I haven't tried any of the above or the following suggestion, but I
    believe dropping the ForceCommand directive may do what you want. You
    have no need for it since /sbin/nologin won't run anything for shell or
    command execution anyway, and internal-sftp is already forced for
    "Subsystem sftp". Possibly if you have some other Subsystem directives
    those commands may be run - so don't do that.

    >Basically, don't bother. Building a real chroot cage for OpenSSH is beyond the
    >work most of us are willing to invest, and it's a packaging nightmare.
    >Additionally, the new OpenSSH 5 chroot cage facility puts all the clients in
    >the same chroot cage, which is also problematic.


    Hm, strange assertions in response to a post that reports that the
    chrooting works fine and explicitly spells out the config for per-user
    chroot directory...

    --Per Hedeland
    per@hedeland.org

  4. Re: sftp server with chrootdirectory setup

    On 30 Jul, 20:18, p...@hedeland.org (Per Hedeland) wrote:
    > In article <488DF3D2.3010...@gmail.com> Nico Kadel-Garcia


    > >Basically, don't bother. Building a real chroot cage for OpenSSH is beyond the
    > >work most of us are willing to invest, and it's a packaging nightmare.
    > >Additionally, the new OpenSSH 5 chroot cage facility puts all the clients in
    > >the same chroot cage, which is also problematic.

    >
    > Hm, strange assertions in response to a post that reports that the
    > chrooting works fine and explicitly spells out the config for per-user
    > chroot directory...
    >
    > --Per Hedeland
    > p...@hedeland.org- Hide quoted text -
    >
    > - Show quoted text -


    That's not quirte he said. As he stated, " But with internal-sftp and
    chrootdirectory, the ssh session will hang, same thing for scp".

    I do see the ChrootDirectory setting (which I hadn't noticed the '%u'
    in before) that potentially does the username based configuration of
    ChrootDirectory. But it's still painful: setting up individual chroot
    direcoties this way requires individually maintained chroot cages.
    That's still.... awkward, and unnecessary.

  5. Re: sftp server with chrootdirectory setup

    In article
    Nico
    Kadel-Garcia writes:
    >On 30 Jul, 20:18, p...@hedeland.org (Per Hedeland) wrote:
    >> In article <488DF3D2.3010...@gmail.com> Nico Kadel-Garcia

    >
    >> >Basically, don't bother. Building a real chroot cage for OpenSSH is

    >beyond the
    >> >work most of us are willing to invest, and it's a packaging nightmare.
    >> >Additionally, the new OpenSSH 5 chroot cage facility puts all the clients in
    >> >the same chroot cage, which is also problematic.

    >>
    >> Hm, strange assertions in response to a post that reports that the
    >> chrooting works fine and explicitly spells out the config for per-user
    >> chroot directory...


    >That's not quirte he said. As he stated, " But with internal-sftp and
    >chrootdirectory, the ssh session will hang, same thing for scp".


    Yeah, but the sftp worked fine - it was just the "having ssh and scp
    print an error message" part that didn't.

    >I do see the ChrootDirectory setting (which I hadn't noticed the '%u'
    >in before) that potentially does the username based configuration of
    >ChrootDirectory. But it's still painful: setting up individual chroot
    >direcoties this way requires individually maintained chroot cages.
    >That's still.... awkward, and unnecessary.


    Well, if you want chroot, it will have to be either all users in the
    same directory or not - both are apparently possible. If you don't want
    chroot at all, that's another thing. Also per the docs the
    "internal-sftp" doesn't need any support files in the chroot directory,
    so if sftp is all you need it doesn't seem hard to setup.

    --Per Hedeland
    per@hedeland.org

  6. Re: sftp server with chrootdirectory setup

    On 31 Jul, 21:48, p...@hedeland.org (Per Hedeland) wrote:
    > In article
    > Nico
    >
    > Kadel-Garcia writes:
    > >On 30 Jul, 20:18, p...@hedeland.org (Per Hedeland) wrote:
    > >> In article <488DF3D2.3010...@gmail.com> Nico Kadel-Garcia

    >
    > >> >Basically, don't bother. Building a real chroot cage for OpenSSH is

    > >beyond the
    > >> >work most of us are willing to invest, and it's a packaging nightmare..
    > >> >Additionally, the new OpenSSH 5 chroot cage facility puts all the clients in
    > >> >the same chroot cage, which is also problematic.

    >
    > >> Hm, strange assertions in response to a post that reports that the
    > >> chrooting works fine and explicitly spells out the config for per-user
    > >> chroot directory...

    > >That's not quirte he said. As he stated, " But with internal-sftp and
    > >chrootdirectory, the ssh session will hang, same thing for scp".

    >
    > Yeah, but the sftp worked fine - it was just the "having ssh and scp
    > print an error message" part that didn't.


    I wouldn't call that 'working fine'.

    > >I do see the ChrootDirectory *setting (which I hadn't noticed the '%u'
    > >in before) that potentially does the username based configuration of
    > >ChrootDirectory. But it's still painful: setting up individual chroot
    > >direcoties this way requires individually maintained chroot cages.
    > >That's still.... awkward, and unnecessary.

    >
    > Well, if you want chroot, it will have to be either all users in the
    > same directory or not - both are apparently possible. If you don't want
    > chroot at all, that's another thing. Also per the docs the
    > "internal-sftp" doesn't need any support files in the chroot directory,
    > so if sftp is all you need it doesn't seem hard to setup.
    >
    > --Per Hedeland
    > p...@hedeland.org


    That's *working*? I'm.... shocked. Seriously. That's been a major
    issue of multiple client based OpenSSH for years. SFTP doesn't support
    symlinks properly, and the user interface is awful, but that's still a
    useful step. Unfortunately for me, I'm dealing with RHEL right now, so
    can't get these features without backporting OpenSSH to this OS, which
    breaks support models. But I'm delighted if it's working: I used to
    publish patches for exactly this sort of functionality, way back in
    the early days shortly after OpenSSH forked from Tectia's code.

  7. Re: sftp server with chrootdirectory setup

    In article
    <9ea9592b-44ed-4cd5-ac03-41a88348e411@d1g2000hsg.googlegroups.com> Nico
    Kadel-Garcia writes:
    >On 31 Jul, 21:48, p...@hedeland.org (Per Hedeland) wrote:
    >> In article
    >> Nico
    >>
    >> Kadel-Garcia writes:
    >> >On 30 Jul, 20:18, p...@hedeland.org (Per Hedeland) wrote:
    >> >> In article <488DF3D2.3010...@gmail.com> Nico Kadel-Garcia

    >>
    >> >> >Basically, don't bother. Building a real chroot cage for OpenSSH is
    >> >beyond the
    >> >> >work most of us are willing to invest, and it's a packaging nightmare.
    >> >> >Additionally, the new OpenSSH 5 chroot cage facility puts all the

    >clients in
    >> >> >the same chroot cage, which is also problematic.

    >>
    >> >> Hm, strange assertions in response to a post that reports that the
    >> >> chrooting works fine and explicitly spells out the config for per-user
    >> >> chroot directory...
    >> >That's not quirte he said. As he stated, " But with internal-sftp and
    >> >chrootdirectory, the ssh session will hang, same thing for scp".

    >>
    >> Yeah, but the sftp worked fine - it was just the "having ssh and scp
    >> print an error message" part that didn't.

    >
    >I wouldn't call that 'working fine'.


    Overall it isn't of course, but the OP's primary goal was apparently
    chrooted sftp - being nice to users that try something else, that they
    aren't allowed to do anyway, is probably good (might arguably depend on
    whether the users doing that are likely to be confused employees at your
    company or script kiddies on the Internet), but it hardly supports your
    claim of non-functionality or complexity of using the builtin chroot
    functionality.

    But anyway that was the problem that the OP was asking about, and I
    suggested (on speculation) a minor config change that might solve it.
    If you are going to declare a piece of software functionality useless
    based on a single user having problems getting a non-essential part of
    it working just right, there won't be much left.

    >> >I do see the ChrootDirectory *setting (which I hadn't noticed the '%u'
    >> >in before) that potentially does the username based configuration of
    >> >ChrootDirectory. But it's still painful: setting up individual chroot
    >> >direcoties this way requires individually maintained chroot cages.
    >> >That's still.... awkward, and unnecessary.

    >>
    >> Well, if you want chroot, it will have to be either all users in the
    >> same directory or not - both are apparently possible. If you don't want
    >> chroot at all, that's another thing. Also per the docs the
    >> "internal-sftp" doesn't need any support files in the chroot directory,
    >> so if sftp is all you need it doesn't seem hard to setup.


    >That's *working*? I'm.... shocked. Seriously. That's been a major
    >issue of multiple client based OpenSSH for years.


    What has been an issue? I don't see any mentioned in the paragraph of
    mine that you quote here.

    --Per Hedeland
    per@hedeland.org

  8. Re: sftp server with chrootdirectory setup

    On 1 Aug, 07:24, p...@hedeland.org (Per Hedeland) wrote:
    > In article
    > <9ea9592b-44ed-4cd5-ac03-41a88348e...@d1g2000hsg.googlegroups.com> Nico


    > >That's *working*? I'm.... shocked. Seriously. That's been a major
    > >issue of multiple client based OpenSSH for years.

    >
    > What has been an issue? I don't see any mentioned in the paragraph of
    > mine that you quote here.


    I meant the internal-sftp, where you do not have to build your own
    chroot cage to support a chrooted sftp site. It's working? Great!

    The lack of a working chroot cage for users in OpenSSH, up until
    version 5.0, was an issue. It was the sort of server-side system
    security issue, rather than application security issue, that made an
    SCP or SFTP repository much more dangerous to support. Without it,
    casual users could go poking around /tmp, /var/tmp/, check /etc/passwd
    for usernames, glance at /var/run or /var/log to get a hint of what
    kind of software is installed, poke around improperly secured /home
    directories, etc.

    Those are not such a big deal in a 'properly secured server', but in a
    mixed or development environment, they're awkward to keep cleaned up.

  9. Re: sftp server with chrootdirectory setup

    In article
    <3514d8bc-538c-495e-870b-0b3c9f8c0f80@m36g2000hse.googlegroups.com> Nico
    Kadel-Garcia writes:
    >On 1 Aug, 07:24, p...@hedeland.org (Per Hedeland) wrote:
    >> In article
    >> <9ea9592b-44ed-4cd5-ac03-41a88348e...@d1g2000hsg.googlegroups.com> Nico

    >
    >> >That's *working*? I'm.... shocked. Seriously. That's been a major
    >> >issue of multiple client based OpenSSH for years.

    >>
    >> What has been an issue? I don't see any mentioned in the paragraph of
    >> mine that you quote here.

    >
    >I meant the internal-sftp, where you do not have to build your own
    >chroot cage to support a chrooted sftp site. It's working? Great!


    Aha, the "shocked" was ironic. (I don't know if it's working, but the OP
    claimed it was.)

    >The lack of a working chroot cage for users in OpenSSH, up until
    >version 5.0, was an issue. [...]


    OK, so I think we have now established that you didn't actually read
    anything besides the word "chroot" from the posting you responded to,
    just repeated your (now obsolete) complaints about the lack of chroot
    functionality in OpenSSH that you have posted countless times before in
    this group. Such things happen on Usenet, but hopefully you can give
    more useful contributions in the future.

    --Per Hedeland
    per@hedeland.org

  10. Re: sftp server with chrootdirectory setup

    Per Hedeland wrote:
    > In article
    > <3514d8bc-538c-495e-870b-0b3c9f8c0f80@m36g2000hse.googlegroups.com> Nico
    > Kadel-Garcia writes:
    >> On 1 Aug, 07:24, p...@hedeland.org (Per Hedeland) wrote:
    >>> In article
    >>> <9ea9592b-44ed-4cd5-ac03-41a88348e...@d1g2000hsg.googlegroups.com> Nico
    >>>> That's *working*? I'm.... shocked. Seriously. That's been a major
    >>>> issue of multiple client based OpenSSH for years.
    >>> What has been an issue? I don't see any mentioned in the paragraph of
    >>> mine that you quote here.

    >> I meant the internal-sftp, where you do not have to build your own
    >> chroot cage to support a chrooted sftp site. It's working? Great!

    >
    > Aha, the "shocked" was ironic. (I don't know if it's working, but the OP
    > claimed it was.)


    No, I'm genuinely surprised. After the confusing and limited 'chroot'
    utilities of PrivSep, which actively destabilized OpenSSH on many systems and
    provided no user-visible difference, the successful use of such a working
    chroot capability is a good thing. And after the years of chroot bugs and
    requests being marked as 'WONTFIX', it's a pleasant surprise.

    >> The lack of a working chroot cage for users in OpenSSH, up until
    >> version 5.0, was an issue. [...]

    >
    > OK, so I think we have now established that you didn't actually read
    > anything besides the word "chroot" from the posting you responded to,
    > just repeated your (now obsolete) complaints about the lack of chroot
    > functionality in OpenSSH that you have posted countless times before in
    > this group. Such things happen on Usenet, but hopefully you can give
    > more useful contributions in the future.


    Well, yes. This was a problem for many years, and I'm delighted to see the
    features made available in this apparently effective fashion. I used to
    publish patches, all the way back at OpenSSH 3.1p1, and bug reports were
    consistently marked as 'WONTFIX' at that time. So I'm glad to see it, and
    apparently done as well as I could have hoped.

  11. Re: sftp server with chrootdirectory setup

    To attempt to answer the question. rather than talk about lack of
    functionality in ancient versions of openssh (!) -

    * Are the permissions correct on the user's home directory? If openssh
    is running as root, the owner of the root dir of the jail needs to be
    root. You'll need to assign group ownership to the group the target
    user is in. This doesn't on the face of it appear to make sense, but
    it works.

    * I notice you're using %u in the ChrootDirectory setting. Is this
    correct for you? Off the top of my head that's not an absolute path -
    that simply expands to the username. You may wish to specify '/home/
    %u' or somesuch. Alternately the %h variable expands to the full home
    directory path - but there are situations where this isn't necessarily
    desirable.


+ Reply to Thread