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.
- Prints the version number for sftpd.
- Prints a usage summary. The usage summary produced by -h is always the most up-to-date, relative to, say, this HTML file.
- Specifies the working directory. The encryption keys are found in this directory.
- 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.
- 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.
- Specifies the port on which to contact ftpd. This option overrides the raw-ftp entry of /etc/services.
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.
- Require data encryption to be used for all file transfers. This option implies -3 (force data relay) and -9 (disallow unencrypted connections).
- Restrict the range of ports used for passive-mode transfers to between low and high (inclusive). E.g., -r40000-40999.
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.)
- (lowercase L)
Log to file filename instead of stdout or syslog.
- Normally, when the -s switch is used, logging output is sent to the syslog facility, which is configured by /etc/syslog.conf. This switch tells sftpd to use stdout, instead (unless the -l switch is also present, which overrides -o and sends output to a file).
- Specify the level of debugging output produced. N can be 1 (least) or 3 (most).
Note: Due to a bug in 1.46, this output goes to stderr regardless of the presence of -l, so it won't work if sftpd is run from inetd (because stderr goes to the network connection). Run sftpd from a shell prompt if you're debugging with -d (this applies to -a as well).
- When this flag is set, the ADATs (Authentication DATa) exchanged during authentication will be logged as well.
- Sets which events to log, as a sum of these codes:
- 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.
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.
- This switch disallows unencrypted (RFC 959) FTP connections. By default, sftpd will permit unencrypted connections for backward compatibility. When this compatibility is no longer desired, the -9 switch should be added. (See also Using TCP wrappers.)
- This is like -9, but it allows unencrypted FTP connections for anonymous FTP only.
- Some FTP daemons are compiled to disallow PORT commands (and/or PASV connections) that name some machine other than the client's machine; these are so-called third-party transfers. As a performance optimization, when data-channel encryption is turned off, sftpd uses third-party transfers.
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 -3
Starting 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.
- Instructs sftpd to supply an alternate IP address to the client, in the SafeTP protocol stream. Normally, sftpd sends the IP address of the interface on which it was contacted, and the client verifies this is the same IP it intended to contact.
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).
- Enables Kerberos compatibility. Specify the filename (including path) to the Kerberos ftpd binary.
- (Experimental) Specifies that when dropping down to 959 mode, and the user is anonymous, sftpd should exec(2) ftpd instead of spawning another process and forwarding data to it. filename is the executable to exec(2).
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 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/tcp
Typically, 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 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 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 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.
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.