Recently, I was faced with the task of organizing access to server files. Access was more precise, but for some reason the FTP server stopped working. It was too lazy to understand the reasons, and all the more, I have long wanted to replace the FTP protocol with something more reliable.
You, dear habrasoobschestvo, let it be known that FTP transmits data in an unencrypted form. And we, the paranoid of this world, are a little scared for our server and the data stored on it.
For this, I decided to completely abandon FTP in favor of SFTP. I use Ubuntu Server, and OpenSSH installed by default in it, I also know that it supports SFTP out of the box, so the task seemed to me extremely simple and I quickly began to put it into practice. With the same speed with which the task was performed, I was faced with the annoying fact that, by default, OpenSSH gives the user access to the entire file system, that is, to the
/ - root.
')
This fact is me, and I think you will not be satisfied. That is, on the one hand, it seems to be okay, because there are access rights that will not allow him, the user, just to write wherever he gets. But for security reasons, this gingerbread should not be his.
Here I will tell you in detail how to tune the OpenSSH server in Ubuntu Linux in order to chroot the user in the directory we need.
Why do I say tying?
- Yes, simply by the fact that, as I have already said, for SFTP operation it is enough just to perform:
sudo aptitude install openssh-server
That will lead to the installation and launch of the server, as well as open, by default, port 22. Making a connection to which, for example
Filezilla , you can access the file system of a remote computer / server using the
ENCRYPTED protocol.
But as I have already hinted, the “default” settings do not suit us.
Therefore, open the OpenSSH server configuration file
sudo mcedit 1 /etc/ssh/sshd_config
and change / add something there.
Find the
Subsystem
option and give it the following view:
Subsystem sftp internal-sftp
Plus we add the following options:
Match User test
ChrootDirectory %h
ForceCommand internal-sftp
Now restart OpenSSH
sudo service ssh restart
and seems to be ready.
Game over?
-
NO!As you probably already guessed, users who have system
2 accounts will have the right to log into the system using the SFTP protocol. Therefore, it is necessary to create an account under which file manipulations will be performed. Since the
Match User test
was written above, it is necessary to create a user account test.
adduser test
A user is created, a password is set, the default home directory is /home/test
...
Now you can try to connect to the server and transfer files. Pre logging in to watch the process ...
tail -f /var/log/auth.log
timestamp host sshd[2558]: Accepted password for test from IP_ port 59667 ssh2
timestamp host sshd[2558]: pam_unix(sshd:session): session opened for user test by (uid=0)
timestamp host sshd[2596]: fatal: bad ownership or modes for chroot directory "/home/test"
timestamp host sshd[2558]: pam_unix(sshd:session): session closed for user test
As you can see, it is written in the logs:
- the session is open to the test user using UID = 0, that is, the root user ID
- Incorrect property rights for chroot in
/home/test
The thing is that for the
/home/test
directory you need to assign the owner of the root user, which we do:
sudo chown root /home/test
It is connected and observed in the logs:
timestamp host sshd[2630]: Accepted password for test from IP_ port 50152 ssh2
timestamp host sshd[2630]: pam_unix(sshd:session): session opened for user test by (uid=0)
timestamp host sshd[2669]: subsystem request for sftp
Mission completeDetails
In the OpenSSH settings, we described the Match
User test option, which by itself means access for an individual, specific user!
- And if there are many?
The description of each user is at least not kosher ... In short, I want to tell you about the fact that you can use groups of users using the Match
Group .
And then the config may look something like this:
Match Group sites
ChrootDirectory /srv/www%h
ForceCommand internal-sftp
And user accounts in
/etc/passwd
like this:
<output omitted>
site1:x:5000:1000 3 ::/example.com/:/bin/false
site2:x:5001:1000::/example.org/:/bin/false
site3:x:5002:1000::/example.net/:/bin/false
<output omitted>
As you can see from the example, users have a
relative home directory, that is, at the root
/ there are no
/example.com/
directories, etc.
These directories are in
/srv/www/
and OpenSSH should work as follows:
- Add the user's home directory from
/etc/passwd
to
/srv/www
and eventually get
/srv/www/example.com
, etc.
Do not forget that the owner of the directory in which chroot users will be should be root. A group of owners, you must set sites and allow full access.
It is also recommended that / bin / false be set as the user's shell, to prevent the user from accessing the command line.
:
1 - mcedit - .
2 - - : .
3 - 1000 - sites.
Mission Complete & Game Over