SFTP chrooted and ownership problem

  • Hi there,


    I've got a problem with chrooted SFTP. This is the fresh install of OMV (4.1.27-1).
    Auth.log says:

    Code
    Dec  2 16:26:30 malyfin sshd[31753]: Accepted password for bik from x.x.x.x port 7237 ssh2
    Dec  2 16:26:30 malyfin sshd[31753]: pam_unix(sshd:session): session opened for user bik by (uid=0)
    Dec  2 16:26:30 malyfin sshd[31753]: User child is on pid 31760
    Dec  2 16:26:30 malyfin sshd[31760]: fatal: bad ownership or modes for chroot directory component "/"
    Dec  2 16:26:30 malyfin sshd[31753]: pam_unix(sshd:session): session closed for user bik

    In the sshd_config I've add:


    Code
    Subsystem sftp internal-sftp
    Match User bik
    ChrootDirectory /srv/dev-disk-by-label-lustro/esftp/bik
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

    The specified folder bik has a 755 permissions ofc.


    I've red all the threads about chrooting sftp and most of the problems was with permissions.
    Mine is different I think, sshd is trying to chroot this user to / instead to his home dir specyfied in sshd_config.


    Please advice 'cause I'm stuck and don't have any clue anymore.


    J

    • Offizieller Beitrag

    Just to be clear, you aren't using the sftp plugin?

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Verify the following ownership and permissions are set:


    root:root 0755 /srv/dev-disk-by-label-lustro


    root:root 0755 /srv/dev-disk-by-label-lustro/esftp

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • ryecoaaron, I've tried it out secondly when editing sshd_config failed for me. Tried it but it wasn't working anyway so I've removed it.


    gderf, it is.



    Code
    drwxr-xr-x 8 root root    4096 Dec  2 15:11 dev-disk-by-label-lustro
    drwxr-xr-x 3 root root  4096 Dec  2 15:12 esftp
  • cd /


    ls-al


    These two should be similar:


    drwxr-xr-x+ 24 root root 4096 Nov 28 23:27 .
    drwxr-xr-x+ 24 root root 4096 Nov 28 23:27 ..


    If they are I am out of ideas.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Einmal editiert, zuletzt von gderf ()

  • Code
    cd /
    root@malyfin:/# ls -al
    total 108
    drwxrwxr-x  27 root root  4096 Dec  2 16:10 .
    drwxrwxr-x  27 root root  4096 Dec  2 16:10 ..

    this the / of file system if I understand You correctly.
    Or if You mean the / of the chrooted account (/srv/dev-disk-by-label-lustro/esftp/bik) as it is set the home dir of the bik user and here is output

    Code
    /srv/dev-disk-by-label-lustro/esftp/bik# ls -al
    total 12
    drwxr-xr-x 3 root root 4096 Dec  2 16:33 .
    drwxr-xr-x 3 root root 4096 Dec  2 15:12 ..
  • I meant the / of the filesystem. Yours are different than mine. Not sure why though.


    There is great risk making changes to those. You could totally hose the whole system.


    I remember many years ago having the same problem with my chroot'd sftp and the problem was that one of those dot directories had its permissions wrong. Changing it fixed the problem.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • I suggest that you have a verified to be able to restore backup of your system disk, because what I am suggesting might hose the box, and with a known good backup and restore procedure you can get out of it.


    (If you are a person of faith, I suggest saying a prayer)


    Then in the shell as the root user:


    chmod 755 /

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • But after "755 /" I need to set the proper permissions to other subfolders so I think it's not so simple like chmod 755 /.
    This box is still under construction so I haven't done any backup image of the system drive yet.


    Do You think that cause of a problem could stick in luks? I'm using omv plugin.

  • No. the other subfolders related to this appear to have correct ownership and permissions.


    Try what I suggest.


    I can't comment about any luks interaction, I don't use it here.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    Do You think that cause of a problem could stick in luks?

    No. LUKS is underneath the filesystem.


    Is this an arm board using an armbian image? Is so, lots of them had the root / filesystem wrong but it was only the root filesystem.


    Tried it but it wasn't working anyway so I've removed it.

    I'd be very curious to know what wasn't working.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • No, it's Dell R210.
    The root is mounted on hdd 160gb, formatted when installing omv.


    The sftp plugin works and user can log into the system but he's not chrooted and just logged directly in / and has access to / ofc.
    So it wasn't working for me and I've removed it from omv.


    Temporarly I'm using other omv box in the same rack but still need to fix the / permissions like gderf said.
    I"ll let You know if it works.

    • Offizieller Beitrag

    The sftp plugin works and user can log into the system but he's not chrooted and just logged directly in / and has access to / ofc.

    Common issue because the user is only chrooted if they are a member of the sftp-access group. That is the only reason that group exists. I guess that is not clearly explained in the plugin settings screen.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!