|
What follows is the man page for sftpd.
sftpd runs in the background and services SafeTP clients.
sftpd [ options ]
sftpd is a daemon process. When SafeTP clients connect to a SafeTP server, it is sftpd that responds. sftpd, in turn, connects to ftpd to do the real FTP work.
sftpd is normally run from inetd. Inetd is configured by /etc/services and /etc/inetd.conf.
sftpd has an installation script. In the source tree, it is called sc/install.pl. The installation script is designed to be edited before use (to specify site-specific parameters), and contains many comments to guide the process.
General options
- -v
- Prints the version number for sftpd.
- -h
- Prints a usage summary. The usage summary produced by -h is always the most up-to-date, relative to, say, this HTML file.
- -ydirectory
- Specifies the working directory. The encryption keys are found in this directory.
Control Channel
- -s
- This flag must be specified when sftpd is run by inetd. It tells sftpd to use standard input as the control connection, rather than creating a socket itself.
- -p[ADDR:]N
- Specifies the port to listen to. This option is only useful when sftpd is not run from inetd. (I.e., the -s switch is not specified.)
When the ADDR is provided, sftpd listens only to that interface, rather than listening to all interfaces. It must be an IP address of a network interface on the machine where sftpd is running. Additional information and some examples are in interfaces.txt.
When the ADDR is provided, sftpd will contact
ftpd on at the specified address, instead of contacting the ftpd
on the same machine that sftpd is running on.
PLEASE NOTE: The traffic between sftpd and
ftpd is unencrypted. Ordinarily that is not a problem since it never
hits the network. But if you supply a nonlocal address with -f, the
traffic will go over some network. That network should be secured by some other
means, such as a physically secure internal LAN or an encrypted VPN.
This is useful for servers behind firewalls, where the firewall can
be told to pass those ports on to the machine running sftpd. (See also the
-i flag.)
You can specify the mask as decimal or, with a leading "0x", hexadecimal. For example, to log just errors with timestamps, say -m0x81. The default is 0xbf (everything logged). The logging behavior of version 1.40 is 0x1f.
- 1 (0x01) - Errors - exceptions, usage errors, etc.
- 2 (0x02) - Warnings - things that suggest there is a problem.
- 4 (0x04) - Control channel connections and disconnections
- 8 (0x08) - Handoffs and dropdowns for compatibility
- 16 (0x10) - Debugging output - if -d is specified then this flag must also be set to see the output.
- 32 (0x20) - USER - log usernames.
- 128 (0x80) - Timestamp - when set, this flag causes each log output to include the date, time, and process id.
If ftpd is configured to disallow third-party transfers,
users will see a message such as "500 You've GOT to be joking" or "425 Possible
PASV port theft, cannot open data connection." when they attempt to transfer
files. The -3 switch disables the optimization, thereby pacifying
ftpd.
You can use a sequence like this to determine if your ftpd is so configured:
% ftp localhost 220 richter FTP server ready. Name (localhost:scott): 331 Password required for scott. Password: 230 User scott logged in. ftp> quote port 4,4,4,4,4,4 200 PORT command successful. <-- no need for -3 or 500 You've GOT to be joking. <-- must specify -3Starting with version 1.10, sftpd will automatically detect this condition for active (PORT) transfers, and will work around it. However, it does not detect this problem for passive (PASV) transfers, so -3 may need to be specified in some circumstances.
However, if the server is behind a Network Address Translation (NAT)
firewall, the client will see a different IP than the server believes itself to
be, and report this as a possible security violation. To work around this, use
the -i switch to specify the IP address the client expects to see.
This flag also affects the address specified in the reply to the PASV command. This means it can be used with -r to allow clients to talk to a server behind a firewall (appropriately configured).
This can be useful because ftpd can then directly see the IP
address of the user, and possibly apply admission and flow control based on
user and IP address.
/etc/services
/etc/services maps service names into port numbers, and typically needs entries for safetp and raw-ftp. The safetp port is where sftpd will listen for incoming connections, and the raw-ftp port is where sftpd will contact ftpd, the normal (unencrypted) Unix ftp daemon.# example entries in /etc/services ftp 21/tcp safetp raw-ftp 351/tcpTypically, sftpd should be installed on port 21 (the usual FTP port), and ftpd should listen to another port in the protected range (<1024), such as 351.If it is undesirable to have sftpd listen to 21, port 353 is the suggested alternative.
/etc/inetd.conf
/etc/inetd.conf maps service names to daemon executables. inetd reads this file when it starts-up, and whenever it receives the HUP signal.# example /etc/inetd.conf excerpt # svc type prot wait? user executable command-line w/argv[0] safetp stream tcp nowait safetp /home/safetp/sftpd sftpd -f351 -s -y/home/safetp raw-ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -t0
Who runs as root
sftpd does not have to run as root. For enhanced protection against possible bugs in sftpd, it is preferable to run as an ordinary user, with privileges only to read and write the directory containing the cryptographic keys.ftpd, because it must potentially access any user's home directory, must run as root.
inetd, because it must listen to protected (<1024) ports, and spawn servers running as arbitrary users, must run as root.
kftpd (Kerberos' ftpd), if you're using Kerberos compatibility, must run as root for the same reason that ftpd does, plus it must access sensitive Kerberos keys.
Encryption
Encryption is used to provide two security services: authentication and confidentiality.Server authentication is provided via DSA (Digital Signature Algorithm) public-key signatures. The server has a public and a private DSA key. Clients usually receive the server's public key during the first contact, trusting that the first contact is authentic, and record this public key in a local database. Subsequent connections are authenticated when the server proves it knows the corresponding private key.
Confidentiality is bootstrapped via ElGamal public-key encryption. Clients generate ElGamal keys locally, and transmit their public keys when they connect to a server. The server encrypts the master session key with the client's public key; the client is then the only party that can decrypt it.
Message-level authentication is provided by an HMAC (Hashed Message Authentication Code) using SHA (Secure Hash Algorithm) as the hash function, for which the keys are derived from the master session key.
Message-level confidentiality (including confidentiality of the user's password) is provided by Triple-DES (Data Encryption Standard), for which the keys are derived from the master session key.
Key Management
The DSA private key, and the random seed file, are stored on disk in plaintext (unencrypted).Compromise (unauthorized read or write) of either file can lead to a compromise of user's passwords. It is therefore essential that file permissions be set properly, and that these files not be transmitted via an insecure network protocol such as NFS (Network File System).
Various additional key protection measures have been considered, such as encrypting with a fixed (compile-time) Triple-DES key, passwords entered at boot time, etc. However, these measures are either insufficient or too inconvenient for users, and therefore have not been employed.
sftpc, SafeTP
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007