SFTP chrooted and ownership problem

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • 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:

      Source Code

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

      Source Code

      1. Subsystem sftp internal-sftp
      2. Match User bik
      3. ChrootDirectory /srv/dev-disk-by-label-lustro/esftp/bik
      4. AllowTCPForwarding no
      5. X11Forwarding no
      6. 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
    • 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!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380
    • 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!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380

      The post was edited 1 time, last by gderf ().

    • Source Code

      1. cd /
      2. root@malyfin:/# ls -al
      3. total 108
      4. drwxrwxr-x 27 root root 4096 Dec 2 16:10 .
      5. 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

      Source Code

      1. /srv/dev-disk-by-label-lustro/esftp/bik# ls -al
      2. total 12
      3. drwxr-xr-x 3 root root 4096 Dec 2 16:33 .
      4. 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!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380
    • 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!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380
    • 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!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380
    • jeremiasz wrote:

      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.

      jeremiasz wrote:

      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 5.1.3 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      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.
    • jeremiasz wrote:

      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 5.1.3 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!