"The Linux Gazette...making Linux just a little more fun!"

FTP Login as 'root' --- Don't!

From Henry C. White on Fri, 30 Oct 1998

Hi, I would like to ftp to my linux PC and login as root. When I have tried this I get an access denied. Please help me in how to configure to allow this. I an runnung linux RedHat 5.1.
Thanks
Henry White

Most FTP daemons (the server software to which your ftp client connects) check the /etc/ftpusers file for a list of users that are NOT allowed to access the system via FTP. This file normally includes a list of all (or most) of the "psuedo-users" on the system.

(psuedo-users is a term to describe all those accounts in your /etc/passwd file that don't correspond to real users at your site).

Another check which is made by most FTP daemons is to scan the /etc/shells file for one that corresponds to that of the user who is attempting to login. Normally the /etc/shells file is a list of all of the valid 'login' shells on the system. If I want to prevent a group of users from accessing normal shell and FTP services on a system I can change their shell to something like /bin/false, or /usr/local/bin/nologin (presuming that I write such a program). Then I just make sure that this program is not listed in /etc/shells, and the user will be denied FTP access. (Their login via telnet would still be allowed, but a proper (true binary) /bin/false will just immediately exit, and one would presumably write /usr/local/bin/nologin to write an error message and exit.

If I want to have some accounts that are only allowed access via FTP (and not given normal shell accounts) I have to do a few things. First I set their login shell (as listed in the last field of the /etc/passwd file) to /usr/bin/passwd (if I want them to be able to set and change their own passwords), or I create a link from /bin/false to /usr/local/bin/ftponly. Then I add one or both of those to /etc/shells.

If you add a new shell to the system (someone writes a niftysh -- that you've just got to have) then you should add it's full path name to the /etc/shells list.

This technique, for limiting an account to FTP only actually requires more work than I've described. If I stopped at this point a user could create a .rhosts file in their home directory and run interactive shell commands via the r* tools. The user could also create .forward and/or .procmailrc files that would allow them to execute arbitrary commands on my systems (including a 'chsh' command to change their shell to bash, csh, etc).

So, I usually use the wuftpd (Washinton University FTP deamon) "guestgroup" features. This is controlled by declaring one or more groups (entries in /etc/group) to be "guestgroup"s in your /etc/ftpaccess file. /etc/ftpaccess is used by wuftpd (and I think Beroftpd, a derivative therefrom). Then I add the "ftponly" users to that group (cleverly named "ftponly" in most cases), and change their "home" directory to point to some place under a chroot jail, using a clever/hackish syntax like:

joeftp:*:1234:3456:Joe FTPOnly Dude:/home/ftponly/./home/joe:/bin/passwd

... note the /./ to demarque the end of the "chroot" jail (a standard FTP "home directory tree" with its own .../bin, .../etc/, and .../dev directories). When Joe Dude logs in (via FTP) he'll be chroot()'d to /home/ftponly and chdir()'d to .../home/joe under that.

Normally we won't allow Joe to own .../home/joe, and we won't allow write access to that "home" directory. We can create an incoming directory below that if necessary.

If our need to create these "FTP only" accounts is such that we must not chroot() the client --- we can just chown the user's home directory (to 'root') and remove write access to it. This will prevent the creation of those various "magic files" like .rhosts, .ssh/*, .forward, .procmail, .klogin, etc.

There are other approaches to these issues.

With PAM (Pluggable Authentication Modules), which has been the default set of libraries for the whole suite of Red Hat authentication programs for the last couple of versions of that distribution, you can configure each service to look into a file like /etc/ftpusers (any file you like) --- and limit each user's access to each service. You can also limit access based on time of day, day of week, terminal and/or source address of the connection, require one-time-passwords, etc. Unfortunately, this isn't well documented, yet.

(I've been raising dust on the PAM list recently --- since they've been hovering at "version 0.6" for over a year. Some of them seem to think that version numbers don't matter at all --- that it's just "marketing fluff" --- I think that the integration of the suite and the "official release" is crucial to it's eventual adoption by other distribution maintainers, and admins/users).

Another approach is to just disable all of the "other" services. That's great when you're setting up a dedicated ftp server.

You could also go in and manually hack the sources to all of the services that you do need, to add the additional checks and the enforcement of your policies. That's precisely the problem that the PAM project has sought to solve.

Yet another approach is to replace your FTP daemon. For example the shareware/commercial 'ncftpd' allows you considerable control over these things. It's the product I'd recommend for high volume FTP servers (https://www.ncftp.com).

Back to your original question. You can probably enable 'root' access via FTP. However, I don't recommend it. You'd really be much better off using 'ssh' (the 'secure' rsh, with 'scp' instead of 'rcp', etc). The best bet is to use 'rsync' over 'ssh' --- to distribute files as 'root' to the systems you're trying to administer.

(The only sane reason to want to send files to or get them from a system "as root" is for remote administration).

Copyright © 1998, James T. Dennis
Published in The Linux Gazette Issue 35 December 1998

			office	largedisk	links	yamaha	magickeys
			passwd	ftproot	pvtmail	netware	crypto
			relay	project	bootmethod	sysadmin	ipscript
loopfs	mrtg	slimscan	rpm	modutil	libc	dell	remoteroot