Objectives
To describe file sharing and some of its uses
To define NFS, FTP, FTPS, SFTP, VSFTP, and SAMBA
How to install and configure an SFTPS
How to install and configure an NFS server to share files to Linux and Unix hosts
How to install and configure a SAMBA server to share files to Windows and Linux hosts
To use Midnight Commander as a multi-protocol file sharing client
Introduction
Sharing files has always been one of the main features of networks. Although networks today can do so much more, file sharing1 is still a staple of many networks. The idea is to make files that would otherwise be inaccessible to anyone else but the creator, available on some sort of central server so that others – those people we choose – can also access the same files.
Does this sound familiar? It should, especially if you use a service like Google Drive, DropBox, OneDrive, or any of several others.
Apress, the publisher of this series of books, has a Google Drive set up for all three books, each with several folders such as First Draft, Ready for Technical Edit, Author review, and more. When I finish a chapter, I upload to the First Draft folder. Later, after it has been reviewed by my development and technical editors, I download the annotated chapter file from the Ready for Author Review folder and make my revisions. Eventually the chapters go to the Ready for Production folder from where they are downloaded for processing into the production files that will be used to print this book or to create an ebook of it.
Of course, we are scattered around the world. I am in Raleigh, North Carolina; Klaatu, my Technical Editor, is in New Zealand; Nancy Chen, my Development Editor, is in New York City; Louise Corrigan, my Senior Editor, is in London, UK; production is in India and the Philippines; and so on. Yet we all have instant access to the same newly uploaded or revised files. This is a very well-defined workflow designed around shared folders and the files they contain. It is based on the simple concept of sharing files between hosts on a network.
Many organizations have a need to share files and find using their own servers to do so a better option. After all, the saying, “The cloud is just someone else’s computer,” is true. Using someone else’s computers on the Internet – regardless of what the marketing department names it – places the responsibility for the security and integrity of your data firmly on someone else’s network and their security precautions – none of which you have control over and for which you will be unable to get a detailed technical description.
There are many ways to share files such as NFS, HTTP, SAMBA, and FTP, or FTPS (Secure FTP), and VSFTP (Very Secure FTP). Although SCP (Secure CoPy), which is part of SSH which we covered in Chapter 5 of this volume, can be used for secure file transfers, it is not a file sharing tool. If you have SSH access to a remote computer, you can transfer any files to which you have access between those computers.
The Fedora online documentation2 contains information in the System Administration Guide about SAMBA, FTP, and VSFTP.
File sharing use cases
Downloading files – This type of transaction is one way downloading only. For example, the ISO image files you downloaded from the Fedora download site and the files you can download from the Apress GitHub web site that are a part of this course. Files can be stored on hosts within the local network or on the Internet.
File downloads can use several protocols, including FTP, FTP over SSL/TLS (FTPS), and SSH File Transfer Protocol (SFTP). Tools like FTP (File Transfer Protocol), SFTP (Simple File Transfer Protocol), wget, and even your web browser can be used to download files. Graphical tools like FileZilla can also be used to download files using many protocols. We will look at FTP and HTTP for downloading files from a central location.
Shared access – This type of sharing tends to be about sharing local network access to files for reference purposes. For example, we may all need access to an organizational email and telephone directory. We can open the file for reading and obtain the information we need from the document. We will use NFS (Network File System) and SAMBA for this type of access. Tools like FTP, the SAMBA client, and SSH File Transfer Protocol (SFTP) can be used to download files for local access.
In this type of use case, files are usually updated by one person working with a local copy of the file and then uploaded or transferred to the directory from which it will be downloaded or viewed.
Simple collaboration – In this type of use case, one user at a time can access the file in its shared location to make changes to it. We can use tools such as NFS (Network File System) and SAMBA for this type of access.
Team collaboration – Working on the same shared files – sometimes simultaneously – can be a powerful collaborative tool. Google Drive is an example of this type of sharing. We will not be setting up this type of collaborative file sharing in this course, but there are many commercial tools3 available that can facilitate collaboration like this.
Preparation
We will need to create a place that we can use to share files from during many of these experiments. So we need to do a little preparation. All FTP services including VSFTP use the /var/ftp directory, and we will add files to that directory after we install VSFTP in Experiment 13-2.
Experiment 13-1
Perform this experiment as the root user on StudentVM2. In this experiment, we create a directory named “/var/shared” for a mount point and a small logical volume to mount there to contain the data.
We will use this directory and its contents for several experiments using different file sharing tools.
As a last bit of preparation, open a root terminal session on StudentVM1 and use tcpdump to monitor the data stream on enp0s3. Place the terminal session in a place on the desktop where it can be seen while performing the rest of these experiments. Be sure to monitor the data stream in this terminal session.
FTP and FTPS
FTP (File Transfer Protocol)4 is an old and insecure method for sharing files. This lack of security is because the data transfer stream is not encrypted and so any data transferred may be easily read if intercepted. Because of its lack of security, FTP has been upgraded with a newer, secure version, FTPS.5 FTPS merely adds a security layer over FTP and is called FTP over SSL (Secure Socket Layer). With FTPS, one can do the same things as with FTP but in a more secure manner.
Fedora does provide an FTP server written in Java. This is not the historical Washington University FTP server, wu-ftpd. Fedora does not provide either a recent version of the wu-ftpd server or a version of an FTPS server, so we will not cover those.
VSFTP
Fedora does provide version 3.0.3 of the VSFTP (Very Secure FTP)6 server for Fedora 29 and 30. This is the most recent version as of July 2015. VSFTP is the primary FTP server provided with current Fedora releases although it is not installed by default. VSFTP, like other FTP services, provides the ability for FTP clients to download files from a server. It is not a collaboration service.
VSFTP is more secure because it provides encryption using SSL and it provides significant protection from privilege escalation. Developed from scratch by Chris Evans with security in mind, VSFTP minimizes the use of elevated privileges and uses unprivileged threads for most tasks. You can read the details at the web site in footnote 6.
VSFTP scales up very nicely compared to other FTP servers. One user quoted on the VSFTP web site says that they have a single VSFTP server running and that over a 24-hour period served 2.6 TeraBytes of data with more than 1,500 concurrent users at times. VSFTP, like other FTP servers, does allow anonymous downloads as well as logged in FTP users with passwords.
Installation and preparation of VSFTP
So let’s install and configure VSFTP.
Experiment 13-2
For now, turn off iptables on StudentVM2. This is so we can configure and test VSFTP without the firewall getting in the way. FTP servers of all types have special needs for firewalls. Taking this out of the equation for now simplifies our initial setup and configuration.
VSFTP is configured using the file, /etc/vsftpd/vsftpd.conf. This file is well commented, so I suggest you read it to understand what can be configured with it.
The default configuration is designed to listen to IPV6 only,7 but it will work for us on IPV4 with only a couple changes. Near the bottom of the file, locate and change listen=NO to listen=YES. This allows vsftp to listen on IPv4. Then turn off IPv6 by changing listen_ipv6=YES to listen_ipv6=NO.
The FTP client
Now that the server is configured, we can install the FTP client on StudentVM1 and then test file downloads. When doing downloads, the files are downloaded to the PWD that was in effect when you started the FTP client, unless you specify a different download directory.
Experiment 13-3
This is a listing of the home directory for the student user on the remote host, StudentVM2. This is the default action when doing a login on a remote host. For now, let’s just go with this and download a file to our account on StudentVM2.
We now know that the VSFTP server is working, but we still have a few bits to work out.
Firewall configuration for FTP
We still need to reactivate our firewall and configure it to allow FTP services through it.
Before we do that, let’s look at how FTP protocols work in order to understand the problem it generates for configuring the firewall. FTP has two modes that can be used for file transfer: active and passive. These two modes work a bit differently, and the difference is important to SysAdmins and the configuration of the firewall. The web site Slacksite.com8 has an excellent explanation of active vs. passive FTP connections and the issues had by each. The Fedora documentation9 has a good explanation of VSFTP and other file sharing tools.
Active mode
- 1.
The FTP client initiates a connection to the server from a randomly selected, high-numbered, unprivileged10 TCP port – we will use port number 1547 for this explanation – to the destination port number 21 on the server. Port 1547 is the control port for the client, and port 21 is the server’s FTP control port. The client sends the command port 1547 to the server to indicate the number of the control port.
- 2.
The server acknowledges this by sending an ACK reply to the client from port 21 to port 1547.
- 3.
The server now initiates a data connection from its port 20 to port 1548 on the client. The protocol always assumes that the data port is one higher than the control port. This step is the cause of the problem because the server initiates a connection to the client.
- 4.
If the server can reach port 1548 and initiate the connection, the client sends an ACK to the server.
These two lines work together to prevent connections from the outside world being made to the local host – whether server or client. If any other host attempts to open a connection to our client host, StudentVM1, the first line of the INPUT chain will not be matched so the rest of the rules in the INPUT chain are checked. Because no rule matches port 1548, the last rule in this chain rejects the attempted connection. This is why we get “No route to host” error messages, as you will see in the next experiment.
The ports that the client can use for the command and data connections are randomly selected from the range 1024 to 65536. This means we would need to open up all of those ports which creates a severe vulnerability and opens our host up to attack.
Passive mode
In passive mode, FTP works a bit differently as client initiates all of the connections. This means that the “state related, established” rule in our firewall would have a record of the connection and allow the server’s response packet through. We can also specify a much-limited range of non-privileged ports for use by FTP when making the data connections.
- 1.
The FTP client initiates a connection to the server from a randomly selected, high-numbered, unprivileged TCP port within the specified range – we will use port number 4048 for this explanation – to the destination port number 21 on the server. Port 4048 is the control port for the client, and port 21 is the server’s FTP control port. The client sends the PASV (passive) command to the server. Note that the control port number does not need to be within the defined range and the client would not know that range in any event.
- 2.
The server acknowledges this by sending an ACK reply to the client from port 21 to port 4048. The reply from the server contains the number of the data port from the defined range so that the client will know where to listen for the data stream. We will use port 65248 for the data connection.
- 3.
The client now initiates a data connection from its port 4049, the data port, to port 65248 on the server.
- 4.
If the client can reach port 65248 and initiate the connection, the server sends an ACK to the client and the data transfer can begin.
If the server is expected to handle very large amounts of FTP traffic, the size of the range of ports defined on the VSFTP server will need to be much larger than we have defined here. The key is that we can control this range and create firewall rules on the server to accommodate this.
Setting the firewall rules
Now that we know that the client establishes both the control and data connections to the FTP server, we can create a much more restrictive set of firewall rules. This is aided by the fact that we can control the range of ports used by the server to which send the data.
Experiment 13-4
We need to configure our firewall for FTP, and this gets a bit complex because of the way that the FTP protocols work.
In active mode, VSFTP uses the standard TCP ports for FTP, 20 and 21, but we are using passive mode which only requires port 21 on the privileged port range. We need to open our firewall to those two ports. Port 20 is for data transfer and port 21 is for command transfer. As root on StudentVM2, add entries for that in the firewall.
But there is still a problem because we get an error with this. The “No route to host” error indicates a firewall problem. The reason for this, as we have seen, is that the FTP protocol uses random high TCP ports as part of its connection and we need to open a wide range of ports on the server, StudentVM2, in order to allow these communication channels.
As the student user on StudentVM1, use FTP to connect to StudentVM2 again. Use the ls command to verify that the FTP connection is now working as it should.
Statefulness prevents crackers from accessing our server through the high-numbered open ports. If the client has not initiated the connection to the FTP server, and some random host from the Internet attempts to initiate a connection to our server, even on those now open ports, it will be unable to do so. This is because our server did not initiate the connection and there is no record of a connection so this new connection attempt is rejected.
Anonymous FTP access
When logged in to a remote host using a valid account, such as student, the user has access to every directory and file on that host that they would if logged in locally. This is a major security issue if we were to give out accounts to just anyone. We need a way to limit FTP access.
Anonymous FTP access is the tool that can help with that. This is the type of access most of us are familiar with when we download files from a remote FTP server. It is called anonymous because anyone accessing the share files can do so without a unique account on the server. All that is required to access an anonymous FTP site is a generic username. Most FTP servers use “anonymous” or “ftp” for the username. No password is required. But this also opens up our public FTP directory to access by everyone on the Internet.
Experiment 13-5
We need to alter the vsftpd.conf file to allow anonymous FTP access.
As root on StudentVM2, edit vsftpd.conf. Find the statement anonymous_enable=NO and change it to anonymous_enable=YES. Then restart the VSFTPD service.
Notice that the VSFTP server logs us into the /var/ftp directory. Download one of the files from there and verify that it was transferred to your PWD.
Close the FTP connection.
Securing VSFTP with encryption
The final bit of security we can use with VSFTP is to encrypt the data while it is being transferred. For this, we need to create a certificate that can be used with FTP. We have already created a certificate for email and this will be similar.
Experiment 13-6
Start this experiment as the root user on StudentVM2.
But the command line FTP client does not support encryption. So is this encryption useless from the command line? Just wait.
Leave the VSFTP server running because we will use it in another experiment later in this chapter.
We now have the server set up to support encryption. The problem is that the Linux command-line ftp program does not support encryption. This means that using the FTP client from the command line is still not secure. This is one of the issues with FTP. There is a command line solution that we will explore later in this chapter.
NFS
The Network File System (NFS) was created by Sun Microsystems to share disk resources and the files they contain among many hosts. NFS is based upon the version of the RPC11 (Remote Procedure Call) protocol developed by Sun.
One advantage of NFS as a means to share files is that the client hosts can mount the shares in the same way as they would any local filesystem. This means that files do not need to be downloaded; they can be accessed directly on the server by file managers and modified remotely by application programs. This is simple collaboration in that only a single user at a time should modify the file, although it may be simultaneously viewed by multiple users. NFS does not provide a locking mechanism to prevent multiple users from simultaneously editing files and overwriting each other’s changes.
This section guides you through the tasks of exporting a filesystem and mounting an NFS remote filesystem.
NFS server
The NFS server is designed to share filesystems of the host acting as a server to a network so that NFS clients can mount the shared filesystems and access the files contained in them. The question of where in the filesystem structure to place filesystems that are to be exported has different answers. Some SysAdmins place them at the root (/) of the filesystem, while others add them to a mount point in /var. For these experiments, we will place them in /var.
Experiment 13-7
The results on my VM show that these packages are already installed. If not, do so now.
The rw option means to share it as read/write; the sync option means that the directory should be synced after changes are made and before other read requests are fulfilled. This helps to ensure that the most recent version of altered or new files are available as soon as the changes are made. The all_squash option changes the shared versions of files to the anonymous user ownership of nobody.nobody. The ownership in the shared directory on the server does not change, only the apparent ownership at the client end.
Note that the status ports are likely to change when the server reboots. You should be prepared for that in a production environment.
Add the necessary lines to your IPTables rule set to allow NFS and RPC access to your studentvm1 host. All of these rules are for RPC and NFS-related ports. Be sure you add IPTables rules for both TCP and UDP protocols where required.
The following command line program will generate the rules we need to add to our firewall, but it will not change the running rule set. We could do that but then we would have to save the active rule set to the /etc/sysconfig/iptables file. That would overwrite any comment lines we might have added to the saved rule set. We will generate the new rules to STDOUT, save them as a separate file, import them into the iptables file, and then use iptables-restore to “restore” the iptables file into the active rule set.
You could enter the CLI program all on one line, but that would be a very long line. Entering it on separate lines makes it easier to read and understand.
Pressing the Enter key after the “; do” in the first line tells the Bash shell that there are more lines to come. The greater than sign (>) prompts you for the next line of input. Press the Enter key after each line and you will be prompted for another line. No part of the command line program is executed until the terminating done statement is entered. At that time, the entire CLI program is run.
The NFS server is now properly configured.
NFS client
Now we can connect to the NFS share from the client, StudentVM1.
Experiment 13-8
Use the mount command on StudentVM1 to verify that the remote filesystem has been mounted. List the contents of /mnt to verify that the files are there as they should be.
Unmount the /shared directory.
Cleanup
Let’s do a little cleanup before we move on to SAMBA.
Experiment 13-9
Perform this experiment as root.
Unmount the NFS on all hosts where it has been mounted. On your studentvm2 host, run the command exportfs -uav to unexport all exported filesystems. Unmount /shared on your studentvm2 host.
Stop the RPC and NFS services. We did not enable them, so they should not start on boot.
This completes cleanup of NFS.
SAMBA
The Samba12 file sharing service provides a way to share files located on a Linux server with Windows systems. SAMBA is based on the Server Message Block (SMB) protocols. Originally developed by IBM, Microsoft used SMB as the primary protocol in their networking services. SMB is now known as Common Internet File System (CIFS).
SAMBA is the Linux implementation of the CIFS protocol. CIFS provides multiuser remote access and file locking to prevent multiple users from simultaneously altering the file and overwriting previous changes.
We will create a scenario in which we want to use SAMBA to share some files with Windows computers. Of course, Linux systems can also be SAMBA clients so that will make our testing easy since we do not have Windows computer from which to test in our virtual network.
Experiment 13-10
Create a directory /acs which will be the shared directory. Create or copy a few files into the /acs directory so that they can be shared. I copied some files from my /root directory, which will be different from the ones in your root directory, and then generated a few additional text files using a Bash program. But not too many – no more than a dozen more files would be good.
Make /etc/samba the PWD. The smb.conf.example file contains comments and examples describing how to configure SAMBA to share various resources such as public and private directories, printers, and home directories. Read through this file to get an idea what is possible with SAMBA.
137
138
139
445
I suggest doing this by adding the rules in the iptables file and then “restoring” the revised file.
You should also ensure that these services start on boot in a production environment, but it is not required for this experiment.
We now have the basics working.
Now that SAMBA is working, let’s make a few additions to the smb.conf file. Our basic installation has caused SAMBA to use the local hosts hostname for the workgroup name and that may be incorrect. We may want to use the name of an existing workgroup or create one with a more meaningful name. We can add that information and also add some additional security to our SAMBA installation.
Experiment 13-11
We have renamed the workgroup and added a bit more information to the server string. We also added the [global] stanza identifier to positively identify the global section of the file. Lastly, we specified the internal network interface on which SAMBA should listen. This enhances security by limiting the sources from which SAMBA clients can connect. We could also limit connections to specific hosts.
This looks good, but there is an error that I ran into and I suspect that you did, too. Internet searches discovered many references to this and similar errors but I never found a solution to it. This does not seem to affect the remaining experiments, so you can safely ignore this message.
Using the SAMBA client
Linux has a SAMBA client that allows us to connect with a Linux server using SAMBA to share directories, as well as providing client access to Windows systems that have shared directories.
Experiment 13-12
We have a number of commands available in this remote SAMBA session. Use the help command to view them and help <commandname> to get more information about the individual commands.
In another terminal session as the student user on StudentVM1, list the contents of the home directory. The file you downloaded should be there.
Using the smbclient in this way is much like using FTP. We have a view into a shared directory and the files it contains and we can perform a few operations including a download. We also have the ability to mount a SAMBA share on a mount point. This gives us much more flexible functionality because the shared directory becomes part of the filesystem.
Experiment 13-13
Start this experiment as the root user on StudentVM1. Verify that the cifs-utils package is installed. If it is not, install it now.
Edit one of the files you created in an earlier experiment. This illustrates that the mounted SAMBA share works just as any other mounted filesystem.
We could have created a new mount point and added it to the fstab file, but this works just as well for our current purposes. Leave SAMBA running for the next experiment.
Midnight Commander
We have already explored the use of Midnight Commander as a file manager. It is also an excellent client for FTP, SFTP, SMB (CIFS), and SSH. It can be used with those protocols to connect to remote hosts in one panel and to copy files from and between the remote and local hosts. It can be used to display the content of remote files and to delete them.
SSH is a powerful tool, and when used in conjunction with a file manager like Midnight Commander (MC), the pair can be used as a simple and easy file sharing system using a protocol called FISH. The advantage of this is that it uses tools we have already installed and requires no additional configuration.
This is also the most secure method I know for sharing files. The login or key-based authentication sequence is encrypted as are all data transfers. This is not just the default configuration; it is the only way in which SSH works. There is not a choice about using authentication and beginning to end encryption so it cannot be bypassed.
The FISH protocol was developed by Pavel Machek in 1998 specifically for Midnight Commander. FISH stands for “Files transferred over Shell protocol.” However, MC also connects with servers using FTP, SFTP, and SAMBA, so it is very versatile. I have found it needs no special configuration, unlike some other clients.
Experiment 13-14
Perform this experiment as the student user on StudentVM1. In this experiment, we will connect to the server using various file sharing protocols.
Select the FTP link to connect with the VSFTP server in standard FTP mode
Using Midnight Commander to access a remote host with FTP
The student user’s home directory on the local host is in the left panel, and the anonymous FTP directory on StudentVM2 is shown in the right panel of Midnight Commander
Copy files between the directories. Can you do it from the local host to the server?
To exit the connection to the server, enter the cd command. This takes you back to the student user’s home directory on the local host.
Now use the SFTP menu item to connect to the server. The only difference in making the connection is that you need to enter the password for the student user on the server. The connection is then opened with the root directory (/) as the PWD. Make /var/shared the PWD. We are not entering this directory using NFS, but rather SFTP.
Experiment with this SFTP environment for a bit. Download a file or two to your home directory. Then try uploading files to various directories on the server, such as /var/shared, your home directory, and the /acs directory. When finished, you can again use the cd command with no arguments to exit from the remote connection.
Now connect to the server using the Shell link option. Use this link to perform the same tasks as with the previous links.
Midnight Commander and SAMBA
Despite the fact that MC looks like it should support connected to SAMBA shares – the man page and the MC Help facility both say it can be done and how – I cannot get it to work. This is true even when the smbclient command works properly as in Experiment 13-12.
After some extensive Internet searches, I found that there is a bug13 reported on this problem and that fixes are to be included in a “future” release. So we will skip any testing of MC with SAMBA shares.
Apache web server
We can also download files using the Apache web server we created in Chapter 10. This requires only a little additional work and no changes to the Apache configuration. Apache is like FTP, a tool for downloading files. It does not provide any collaborative functionality.
Experiment 13-15
In this experiment, we will add some files to the Apache download directory and test the results. As the root user on StudentVM2 ensure that Apache, httpd, is running. If not, start it.
Using the Apache web server to share files displays a sortable index
Right click a couple files and select Save link as from the pop-up menu to download them. The default directory for downloads is ~/Downloads. Look for the downloaded files there.
We also have a couple command-line tools, wget and curl, to use for downloading files from web sites. Let’s look first at wget which should already be installed. We touched on the wget command briefly in Volume 1, Chapter 12, and we installed and used it to download companion files for this course from the Apress Git repository.
The curl utility can use regular expressions such as sets to download multiple files for many protocols. The curl tool supports all of the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, and TFTP. It can also handle user IDs and passwords, as well as certificates. As a result, it can be used in a great many situations where a single downloading solution is desirable, such as in scripts. It is an excellent tool for use in scripted automation.
So we have discovered that wget can use file globs but not REGEXes like sets when downloading FTP. It cannot use any form of glob or REGEX with HTTPD. The curl utility can use REGEXes but not file globs – at least on the protocols we have tested.
The wget and curl man pages have good descriptions and examples of their many features.
Chapter summary
This chapter has shown us some tools for sharing files on a file server. We used FTP, SAMBA, and NFS on StudentVM2 to share directories with users on StudentVM1. FTP in any form, SAMBA, and NFS all require some nontrivial setup to work in a nonsecure mode. Even more work is required to provide a secure environment on those that support it.
We have also seen that tools we already have available, SSH and Midnight Commander can work together to provide a very powerful, secure, and flexible yet easy-to-use file sharing solution that just works. Midnight Commander can be used without SSH to access FTP sites and with SSL to access VSFTP sites. MC can also be used with SSH to connect to a shell session on a remote host, one which one has a user account. We have also explored wget and curl as command line tools for downloading files with HTTPD and FTP protocols. The curl utility can download using many different types of protocols and it can use regular expressions to do so.
There are a lot of options available to us to share files as well as to use for downloading those files. We have not covered all of them, but the ones we did cover should give you a good start.
Exercises
- 1.
Monitor the packet data stream on StudentVM1 as you use FTP to connect to the VSFTP server. Examine the resulting TCP conversation and identify the components of the FTP initiation sequence.
- 2.
As root on your student host, mount the NFS export on /mnt. Change the PWD to the stuff subdirectory and verify that the files you copied to it are there.
- 3.
Attempt to add a new file. What message do you get?
- 4.
Create mount new point and an entry in the fstab for the ACS share created on StudentVM1 and mount the filesystem as a test. Reboot StudentVM1 and verify that /acs is mounted during startup.
- 5.
Monitor the packet data stream on StudentVM1 as you use Midnight Commander as the student user on StudentVM1 to connect to StudentVM2 using various methods. Use FTP, SFTP, a shell link, and an SMB link. Observe which of these connections are encrypted and which are not.
- 6.
Configure the VSFTP server to allow anonymous uploads.
- 7.
Use Midnight Commander to copy files from the student account on StudentVM1 to the VSFTP server.
- 8.
Why did you not need a user ID and password in Experiment 13-14 when using Midnight Commander to connect to the server using a shell link?
- 9.
What directory is the PWD when you open a shell link to the server?
- 10.
Use wget to download some files from our FTP server.
Be sure to shut down all file sharing client and server tools and services after completing these exercises.