SFTP chrooted and ownership problem

jeremiasz · Dec 2nd 2019, 4:38pm

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

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:

Source 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

ryecoaaron · Dec 2nd 2019, 5:57pm

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

gderf · Dec 2nd 2019, 6:19pm

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

jeremiasz · Dec 2nd 2019, 8:43pm

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.

Source 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

gderf · Dec 2nd 2019, 9:00pm

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.

jeremiasz · Dec 2nd 2019, 9:28pm

Source 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

Source 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 ..

gderf · Dec 2nd 2019, 10:02pm

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.

jeremiasz · Dec 2nd 2019, 10:06pm

ok gderf, I understand that it should be 755 on . and .. also but how to set it up in the running system?

gderf · Dec 2nd 2019, 11:36pm

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 /

jeremiasz · Dec 2nd 2019, 11:51pm

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.

gderf · Dec 3rd 2019, 12:09am

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.

ryecoaaron · Dec 3rd 2019, 12:49am

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.

jeremiasz · Dec 4th 2019, 4:13pm

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.

ryecoaaron · Dec 4th 2019, 4:16pm

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.