diff --git a/modules/resources/solution_raspberrypi.md b/modules/resources/solution_raspberrypi.md index f239889..f01fe5f 100644 --- a/modules/resources/solution_raspberrypi.md +++ b/modules/resources/solution_raspberrypi.md @@ -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.