waldek
/
linux_course_doc
1
0
Fork 0
Code Issues 2 Pull Requests Projects Releases Wiki Activity

completes the sftp solutions

This commit is contained in:
waldek 2021-04-20 19:09:20 +02:00
parent fe46f6a2a2
commit 91cfa57082
1 changed files with 94 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
modules/resources/solution_raspberrypi.md
View File

@ -252,20 +252,112 @@ done
## Setting up the fileserver
The concept of a fileserver is about as old as the the world wide web, email, newsgroups etc.
It's main purpose in life is to offer a place to store and retrieve large files.
The Debian repositories where you download all your packages from is contactable over the FTP protocol.
There are multiple implementations available, some plain, some secure, some less secure.
We'll have a look at the two most common solutions to host and transfer files.
To use the FTP protocol we can install any FTP tool we find.
A good candidate is `filezilla` which you can find in the Debian repositories, or online if you want to use it on Windows.
### FTP
A quick [google](https://likegeeks.com/ftp-server-linux/) tells us `vsftpd` is a popular *FileTransferProtocol* server.
As expected you can find it in the main Debian repositories.
You know how to install it by now!
```bash
sudo apt search vsftpd
```
You know how to install it by now!
To know *where* to configure the server we can look at the `man vsftpd` pages.
Scroll all the way to the bottom to see which files it uses to configure itself.
The configuration file itself is very *verbose* and should explain itself.
### SFTP
TODO
Even without installing any additional server, we can offer our users a way to download, and upload, files to our server.
When you install `openssh-server`, and pay attention to the installation dialog, you'll see it will also install an additional package called `openssh-sftp-server`
This in itself is enough to have an SFTP server up and running.
Done!
It does raise the question of security.
When installing the `vsftpd` package your users can *only* upload and download files but when you install an ssh server they can also get shell access!
This might not be the desired behaviour for all your users.
Luckily we can change the server configuration to modify it to our requirements.
How will we find *which* configuration file we need to change *where*?
`man sshd` should do the trick.
Navigate to to end of the manual and you'll see a huge list of files the server uses to configure itself.
Why `sshd` and not `ssh` you ask?
Well, `ssh` is the **client** you use to connect to the `sshd` **server** and thet are to different *programs*.
Remember that `ssh` was installed on your Linux machine even before installing `openssh-server`!
I can think of two ways to limit the shell access for specific users.
The first one should ring a bell.
As we define our default shell in the `/etc/passwd` file to be `/bin/bash`, we can also change this for specific users to `/usr/sbin/nologin`.
This will block those users from getting an actual shell when sshing into the machine but SFTP should still work.
There are multiple downsides to this solution, some of which we'll investigate further later one, but the main one I see from a beginner point of view is that it requires a customisation for each account we want to block.
As all users we want to block are part of a group, either *red* or *blue* there should be a way to restrict access on a group based level no?
It's the last lines of the configuration file that point out some interesting features.
```bash
# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
```
Remember that the `#` are comments.
These settings point out that we can add different rules for different users, and probably groups as well.
So, if you trust all people in the *blue* group, you can add a rule to match all users in the *red* group and restrict them to only sftp login and no shell access.
With this in mind, what would adding the following to the configuration file do?
```bash
Match Group blue
ForceCommand internal-sftp
```
But the users can still walk around the entire file system, which is not always a good idea.
Using the keywords **sftp**, **chroot**, **group** in [google](https://googlethatforyou.com?q=sftp%20chroot%20group) lists us the [arch](https://wiki.archlinux.org/index.php/SFTP_chroot) wiki which is *always* a solid place to inform ourselves.
Try to have get this set up as an additional exersise!
### Taking changes to configuration files into account
When make these changes to the configuration files you probably noticed they are not applied immidiatly.
So when are they taken into account then?
Most servers we'll install onto our various machines run as [daemons](https://en.wikipedia.org/wiki/Daemon_(computing)) in the background.
They listen on for an incoming client connection on a port, do whatever the client requests of them and go back to sleep when there are no tasks for them to perform.
They might have internal tasks scheduled but we'll set this aside for the moment.
As with most things Linux, configuration is done by a text file and *most* daemons will read their corresponding configuration files upon startup.
Think of the .bashrc file, which is read every time a new shell is started.
Once they know how to behave, from reading their configuration file, they will act accordingly.
This raises the question, how do you *restart* a running server?
The system responsible for launching most daemons on our Debian installions, and also our Raspberry PI's, is called **systemd**.
The thee most used commands you need to know are as follows.
How do to *start* a service, how to *stop* one and how to *check* if one is running properly.
For system daemons, such as `sshd` or most webservers, you need administrator powers to interact with them.
```bash
sudo systemctl start sshd.service
sudo systemctl stop sshd.service
sudo systemctl status sshd.service
```
These three commands will go a long way but there are other handy ones you can try out.
I advise you to use *tab-completion* as much as possible as it will help you to construct the proper commands.
Especially at the beginning of your Linux journey because it takes some time to rememeber specific service names.
Have a look at all the base commands of `systemctl` and you'll notice quite a few interesting things.
For example, it can be used to reboot or shutdown your computer as well!
For those who want to digg deeper into systemd itself I advise you to have a browse in it's configuration directory.
You'll find it at `/etc/systemd` and the manpages `man systemd` are also very helpfull, but a bit verbose.
We will have a deeper look at the internals of systemd later throughout the course.