|
|
Since Fedora Core offers you several ways to move files around your network and from system to system, you will need to pick the method best suited to your environment and the task at hand. To make this decision, you'll need to determine the kinds of files your users move regularly, how your users and fellow administrators prefer to work, and what kind of security your environment requires.
We begin with FTP, because it is the most common file transfer method on the planet. Everyone has access to it, and most users are familiar with t. Unfortunately, FTP is also one of the most insecure services available, and it's annoying to administer in a security conscious environment, especially with client-side firewalls. Still, you should know the FTP basics even if you choose to run a more secure protocol.
In this chapter, we cover configuration and basic administration for vsftpd, the FTP daemon included with Fedora Core. We describe common clients, and offer some hints on keeping it as secure as you can. Though the protocol itself is insecure, the current version of vsftpd has some security enhancements that make it the lesser evil if you must run this dangerous legacy protocol.
For general system-wide file transfers, OpenSSH's scp and sftp client programs, for the sshd server-side service, can't be beat. They are fully encrypted, run over a single port (22) that is easy to configure for firewalls, and permit you to read or write files anywhere on the system. For users, file transfer based on SSH's scp and sftp offers a number of options, including command line and graphical user interface (GUI) clients.
The OpenSSH protocol suite includes scp, a secure replacement for the old rcp (remote copy) command. sftp, as the name implies, is a secure FTP subsystem of the sshd daemon. Both are fully integrated with Fedora Core's GUI environment. If you allow trusted client systems, such as administrative desktop, access to your systems, then you can use these tools together with key-based authentication. Key-based authentication allows you to have a login-free GUI environment and enjoy remote browser-style access to SSH resources.
| Caution |
Whenever you implement key-based authentication, or any other form of password-free authentication, you effectively remove the need for a username/password login and its associated security. Some workplaces may frown on this security compromise, or even ban it outright. Before you enable such a feature, be sure it's okay for you to do so. |
SSH-based logins and file transfers via scp and sftp offer great flexibility. With scp, users can transfer files to any part of the system where they have existing privileges. They use the ordinary system accounts and passwords, plus server public/private keys, to authenticate their presence, and the existing file system security, such as permissions and group settings, remains in place.
However, scp's system user flexibility can be a disadvantage. The user needs to exist on your system, with a real username and password. You may not want to enable everyone who needs your files, with such privileges. You must also grant valid login shell access to anyone who uses scp on your system, including a /bin/bash setting in the /etc/password file. Therefore, scp-based file transfer mechanisms are usually best suited for trusted users and administrators, rather than for random people who might want a publicly available file from one of your machines. That said, scp is a command-line utility, so it is probably more suited to "power users" than your average desktop user. (For a browser-based tool see the User Clients section later, which describes Konqueror. This KDE tool supports scp-aware URLs, and there's even a Windows-based client.) This makes scp a snap for users of any ability.
The sftp client also uses the SSH daemon sshd with the sftp-server subservice. It also requires a user shell login. This would be a good overall solution, but the client sftp is neither user friendly nor feature rich. With that warning, you may still prefer sftp to other pure FTP client/server options if your users prefer the traditional interface. Like its cousin scp, sftp can also be used in GUI mode through KDE's Konqueror.
| Note |
Remember that SSH, scp, and sftp access have the same security risks as local login access unless you use a shell replacement such as scponly (see Using SCP section later in this chapter). |
Don't have root privileges? Can't create new users and change their passwords? Just trying to grant access to web users who want to publish content? What to do? FTP's not a real solution. Perhaps WebDAV is the solution for you. WebDAV is a flexible client/server protocol that offers file access without requiring you to give actual system user access to remote clients. It even offers version tracking and file locking so that groups of users can work on the same files.
The advantage of WebDAV is that you don't need to investigate external users and add them to the system. WebDAV is an Apache module that uses Apache-based web users, and which, when fully configured and enabled, allows web-based read/write access to files on your system-even with secure SSL, when configured properly. When you run WebDAV with Apache, it will use the standard security settings that you defined for Apache and atop the file system's own security permissions. Users see only the files for which you give them web logins to see. Additionally, since they're restricted to the system account apache, they have less opportunity to run local exploits in an attempt to gain root privileges.
Fresh out of the box, WebDAV is almost ready to go. You need to add only a few minor configurations to get it started. That said, you will need to do some work if you want to implement WebDAV with discrete Apache-based user-level logins and have a reasonable level of user authentication over a secure SSL-based connection. It's not an overly difficult task, however, and we show you how to do it in the WebDAV section of this chapter.
|
|