SFTP users can see server folders and files - is it normal?

myhken

It's not a big deal, since I have restricted all SFTP use with IP block etc on my own hosting server, but, if I use SFTP on a normal FTP user (a site user) and in FileZilla then click out of the site users home folder, the user can see all other home folders - but do not have access to the folders (and then files).
But if I click to next level, I can see all folders on the server (like etc, var, bin, boot, dev, lib an so on) and on thees folders, I can also see files, and I can download the files, but I can't change, upload or delete the files.

Is this normal? Of course, if I had use the root user it had been normal. But I'm only using the normal username and password Virtualmin has created for a site.
I did also test this on a Cpanel server, and it's the same there.

If I'm using normal FTP, they don't see anything then their home folder. It's just apply to SFTP usage.

Here you can see a normal site user, can see files under /etc/httpd/conf

Neoon

Yes you need to force chroot on the directory.

https://www.thegeekstuff.com/2012/03/chroot-sftp-setup/

myhken

@Neoon said:
Yes you need to force chroot on the directory.

https://www.thegeekstuff.com/2012/03/chroot-sftp-setup/

Thank you, it was just that I was needing.

angstrom

But I guess that this would also prevent shell access via ssh, right?

asv

@myhken,
See below.

@angstrom,
You can make a jail with whatever binaries you'd like.

For example, in /etc/ssh/sshd.conf:

Subsystem sftp internal-sftp  

Match Group minions  
    PasswordAuthentication no  
    ChrootDirectory %h  
    AllowTcpForwarding no  
    AllowAgentForwarding no  
    PermitTunnel no  
    X11Forwarding no  

Then, using Ansible (or whatever is your preference),

---
- name: Create minions group
  group:
    name: minions
    state: present

- name: Create minion
  user:
    name: minion
    shell: /bin/sh
    groups: minions

- name: Add pubkey from current user
  authorized_key:
    user: minion
    state: present
    key: '{{ item }}'
  with_file:
    - "~/.ssh/id_rsa.pub"

- name: chmod/chown homedir to make jail valid
  file:
    path: /home/minion
    state: directory
    mode: 0755
    owner: root

- name: Create data exchange directory
  file:
    path: /home/minion/data
    state: directory
    mode: 0755
    owner: minion

- name: Create system root dirs within chroot
  file:
    path: /home/minion/{{item}}
    state: directory
    owner: root
  with_items:
    - usr
    - usr/bin
    - bin
    - lib
    - lib/x86_64-linux-gnu
    - lib64

- name: Copy sh to chroot /bin
  copy:
    src: '/bin/{{ item.src }}'
    dest: '/home/minion/bin/{{ item.dest }}'
    mode: 0755
  with_items:
    - { src: 'sh', dest: 'sh' }
    - { src: 'ls', dest: 'ls' }
    - { src: 'df', dest: 'df' }

- name: Copy rsync to chroot /usr/bin
  copy:
    src: '/usr/bin/{{ item.src }}'
    dest: '/home/minion/usr/bin/{{ item.dest }}'
    mode: 0755
  with_items:
    - { src: 'rsync', dest: 'rsync' }

- name: Copy libs from /lib/x86_64-linux-gnu
  copy:
    src: '/lib/x86_64-linux-gnu/{{ item.src }}'
    dest: '/home/minion/lib/x86_64-linux-gnu/{{ item.dest }}'
    mode: 0755
  with_items:
    - { src: 'libattr.so.1', dest: 'libattr.so.1' }
    - { src: 'libacl.so.1', dest: 'libacl.so.1' }
    - { src: 'libpopt.so.0', dest: 'libpopt.so.0' }
    - { src: 'libc.so.6', dest: 'libc.so.6' }

- name: Copy ld-linux-x86-64.so
  copy:
    src: '/lib64/{{ item.src }}'
    dest: '/home/minion/lib64/{{ item.dest }}'
    mode: 0755
  with_items:
    - { src: 'ld-linux-x86-64.so.2', dest: 'ld-linux-x86-64.so.2' }

This way we are effectively limiting user to rsync and sftp.

ZiriusPH

@asv isn't ansible expensive?

Tom

@ZiriusPH said:
@asv isn't ansible expensive?

It's open source?

jetchirag

sshd_config:

PasswordAuthentication yes

#Subsystem sftp /usr/lib/openssh/sftp-server

Subsystem sftp internal-sftp
Match group sftpusers
ChrootDirectory %h

donli

@ZiriusPH said:
@asv isn't ansible expensive?

It's "only" $5,000/year for "up to 100" nodes ( https://www.ansible.com/products/engine/pricing ).

jetchirag

@donli said:

@ZiriusPH said:
@asv isn't ansible expensive?

It's "only" $5,000/year for "up to 100" nodes ( https://www.ansible.com/products/engine/pricing ).

You don't need that product for using ansible. You can use FOSS version.

angstrom

@asv said: @angstrom, You can make a jail with whatever binaries you'd like.

Yes, I see that, but I guess that if you jail/chroot sftp for user X, then X no longer has shell access via ssh, right?

jetchirag

@angstrom said:

@asv said: @angstrom, You can make a jail with whatever binaries you'd like.

Yes, I see that, but I guess that if you jail/chroot sftp for user X, then X no longer has shell access via ssh, right?

Hmm, no. See my comment above, it only chroot user for sftp, ssh is unaffected.

angstrom

@jetchirag said:

@angstrom said:

@asv said: @angstrom, You can make a jail with whatever binaries you'd like.

Yes, I see that, but I guess that if you jail/chroot sftp for user X, then X no longer has shell access via ssh, right?

Hmm, no. See my comment above, it only chroot user for sftp, ssh is unaffected.

Okay. (I have yet to try this.)

I wonder, though, in what practical scenario I would want to chroot user X for sftp but would otherwise want to allow X to ssh freely.

jetchirag

angstrom said:

I wonder, though, in what practical scenario I would want to chroot user X for sftp but would otherwise want to allow X to ssh freely.

You'd change the condition to your preference. Instead of Match group xyz use Match user xyz.

angstrom

@jetchirag said:

angstrom said:

I wonder, though, in what practical scenario I would want to chroot user X for sftp but would otherwise want to allow X to ssh freely.

You'd change the condition to your preference. Instead of Match group xyz use Match user xyz.

I guess that what I'm asking is more of a conceptual question than a technical one: why decide/choose to chroot user X for sftp but at the same time not decide/choose to choot X for ssh?

jetchirag

angstrom said: I guess that what I'm asking is more of a conceptual question than a technical one: why decide/choose to chroot user X for sftp but at the same time not decide/choose to choot X for ssh?

Gotcha. IMO SFTP is very common and easy to chroot than ssh. Mostly, you would disable ssh access and only enable sftp to allow operations related to files.

angstrom

@jetchirag said:

angstrom said: I guess that what I'm asking is more of a conceptual question than a technical one: why decide/choose to chroot user X for sftp but at the same time not decide/choose to choot X for ssh?

Gotcha. IMO SFTP is very common and easy to chroot than ssh. Mostly, you would disable ssh access and only enable sftp to allow operations related to files.

Yeah, either that (no ssh, chroot for sftp) or (chroot for ssh, chroot for sftp), but I can't think of a practical scenario for (no-chroot for ssh, chroot for sftp).

FHR

jetchirag said: Gotcha. IMO SFTP is very common and easy to chroot than ssh. Mostly, you would disable ssh access and only enable sftp to allow operations related to files.

That's exactly what I'm doing. Requires minimal amount of configuration and it's safe.