Easy methods to configure SFTP with restricted listing entry

0

Get real time updates directly on you device, subscribe now.

Steps to configure SFTP on Linux server with entry restricted to the precise listing solely. Additionally, find out how to deny SSH login and solely permit SFTP login to the consumer.

SFTP with restricted listing entry

On this article, we’ll stroll you thru the process to configure SFTP in your server and limit sftp consumer entry to a selected listing.

The entire course of is listed under steps. You probably have SFTP configured already or customers created already you possibly can skip these steps.

Add SFTP consumer to the systemPrepare SFTP directoryConfigure SFTP on SSH service layerAllow consumer for SFTP solely and deny SSH accessVerify entry

In under instance, we’ll create consumer sftp_user1, permit his sftp entry, deny him ssh entry and limit his sftp entry to the listing /sftp_uploads/user1

Add SFTP consumer to the system

It’s a easy useradd stuff. For simple administration of SFTP customers, add the SFTP group as properly in your system.

[[email protected] ~]# groupadd sftp_group
[[email protected] ~]# useradd -g sftp_group -s /sbin/nologin sftp_user1
[[email protected] ~]# passwd sftp_user1

 

[root@kerneltalks ~]# groupadd sftp_group

[root@kerneltalks ~]# useradd -g sftp_group -s /sbin/nologin sftp_user1

[root@kerneltalks ~]# passwd sftp_user1

 

Put together SFTP listing

Remember that you need to have a base listing that will probably be owned by root i.e. ChrootDirectory. After which below it, you possibly can create your restricted listing the place SFTP consumer is to be restricted. So as soon as SFTP consumer is logged in he’s jailed into ChrootDirectory and he can’t transfer past it.

Set possession and permissions for the SFTP listing. I stored them completely for proprietor i.e. sftp_user1 solely.

[[email protected] ~]# mkdir -p /sftp_uploads/user1
[[email protected] ~]# chown root:root /sftp_uploads
[[email protected] ~]# chown sftp_user1:sftp_group /sftp_uploads/user1
[[email protected] ~]# chmod 700 /sftp_uploads/user1

 

[root@kerneltalks ~]# mkdir -p /sftp_uploads/user1

[root@kerneltalks ~]# chown root:root /sftp_uploads

[root@kerneltalks ~]# chown sftp_user1:sftp_group /sftp_uploads/user1

[root@kerneltalks ~]# chmod 700 /sftp_uploads/user1

 

Configure SFTP in SSH service

SFTP is a sub-service provided by SSH daemon. To allow it, add under strains in SSH configuration file /and so on/ssh/sshd_config

In case your SSH config file already has /usr/libexec/openssh/sftp-server enabled as sftp subsystem then hash it out.

Subsystem sftp internal-sftp
Match Group sftp_group #OR Match Person sftp_user1
ChrootDirectory /sftp_uploads
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

 

Subsystem sftp insidesftp

Match Group sftp_group  #OR Match Person sftp_user1

ChrootDirectory /sftp_uploads

ForceCommand insidesftp

X11Forwarding no

AllowTcpForwarding no

 

Right here line-wise –

Tells SSH daemon to run the inner sftp subsystem.Match customers with the first group sftp_group or match solely specified consumer i.e. sftp_user1When they attempt to login limit their working listing below the bottom /sftp_uploadOnly permit them to make use of sftp service and deny ssh loginDisable all X11 ahead for these customers so that they cant entry GUI appsDisable TCP forwarding as properly for them

Restart SSH daemon to choose up these new configurations. You may restart with HUP for those who don’t need the prevailing SSH connection to be impacted.

[[email protected] ~]# systemctl restart sshd
[[email protected] ~]# kill -HUP <PID of sshd course of>

 

[root@kerneltalks ~]# systemctl restart sshd

[root@kerneltalks ~]# kill -HUP <PID of sshd course of>

 

Confirm entry

Now there are three issues we have to confirm right here –

sftp_user1 ought to capable of join utilizing the sftp protocolsftp_user1 shouldn’t be allowed to log in utilizing SSHWhen logged in utilizing sftp, sftp_user1 needs to be restricted to /sftp_uploads/user1 listing solely.

Let’s take a look at all three factors –

[[email protected] ~]# sftp [email protected]
[email protected]’s password:
Related to 192.168.zero.106.
sftp>

 

sftp_user1@192.168.zero.106s password:

Related to 192.168.zero.106.

sftp>

 

So the primary level is validated.

[[email protected] ~]# ssh [email protected]
[email protected]’s password:
Couldn’t chdir to house listing /house/sftp_user1: No such file or listing
This service permits sftp connections solely.
Connection to 192.168.zero.106 closed.

 

sftp_user1@192.168.zero.106s password:

Might not chdir to house listing /house/sftp_user1: No such file or listing

This service permits sftp connections solely.

Connection to 192.168.zero.106 closed.

 

There! The second level validated.

[[email protected] ~]# sftp [email protected]
[email protected]’s password:
Related to 192.168.zero.106.
sftp> ls
user1
sftp> pwd
Distant working listing: /user1

 

sftp_user1@192.168.zero.106s password:

Related to 192.168.zero.106.

sftp> ls

user1

sftp> pwd

Distant working listing: /user1

 

And the third level as properly. You may see the SFTP consumer’s working listing is restricted to /usr1 which is /sftp_uploads/user1 on SFTP server. Since we jailed him utilizing ChrootDirectoy /sftp_uploads, he’s inside it and can’t see past. Therefore /user1 is PWD for SFTP consumer.

Source link

Leave A Reply

Your email address will not be published.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More