|
|
The Answer Guy 35: FTP Login as 'root' --- Don't!
"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
(http://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
![[ Table Of Contents ]](../../gx/indexnew.gif)
![[ Front Page ]](../../gx/homenew.gif)
![[ Previous Section ]](../../gx/back2.gif)
![[ Next Section ]](../../gx/fwd.gif)
|
![[ Answer Guy Index ]](../../gx/dennis/answernew.gif)
