Enhanced PHP File Manager

⬆️ Go Up (..)

📊 Server Information

Server:

nginx/1.28.0

System:

Linux 6.8.0-90-generic

PHP Version:

8.4.15

User:

alqudsvolunteers

Directory:

/home/alqudsvolunteers/rootlink/usr/share/doc/proftpd-doc/contrib

Free Space:

81.69 GB

🔧 Quick Actions

✏️ Editing: mod_sftp.html

<!DOCTYPE html>
<html>
<head>
<title>ProFTPD module mod_sftp</title>
</head>

<hr>
<center>
<h2>ProFTPD module <code>mod_sftp</code></h2>
</center>
<hr>

SFTP versus FTPS 
There is a great deal of confusion and misunderstanding surrounding two very
different protocols: SFTP and FTPS.

FTPS stands for "FTP over SSL/TLS". It is the existing FTP protocol,
made to run over an SSL/TLS connection; in this manner, it is very similar to
HTTPS (HTTP over SSL/TLS). In fact, that is where the name "FTPS" comes from.
The <a href="http://www.proftpd.org/docs/contrib/mod_tls.html"><code>mod_tls</code></a> module for ProFTPD implements FTPS. Since FTPS is still FTP, any
FTPS sessions require multiple TCP connections: one TCP connection for the
FTP control channel, and separate TCP connections for each FTP data channel.
The need for these multiple connections is undesirable for many network
administrators, especially those that wish to restrict all protocols to a
single TCP connection which can be passed through firewalls/NAT/router
equipment. The network equipment, now, often inspects the application-level
data in FTP packets in order to dynamically open the necessary firewall rules
for the FTP data channels. However, FTPS encrypts those packets, and thus
the network firewall must resort to using a statically configured range of
ports, or not allow FTPS. There is a third solution: the <code>CCC</code> FTP
command, which clears the FTP control channel of encryption, once the user has
authenticated. Unfortunately, support for the <code>CCC</code> command is not
widespread among FTPS clients and servers; the <code>mod_tls</code> module does
support the <code>CCC</code> command.

By contrast, SFTP refers to "Secure File Transfer Protocol", and is not
related to FTP in any way. SFTP is based on the SSH2 protocol, which uses
binary encoding of messages over a secure channel. Unlike FTP, SSH2 only
uses a single TCP connection, and multiplexes multiple transfers or "channels"
over that single connection. For this reason, many sites prefer SFTP
to FTPS for secure transfer of data.

SSH2 RFCs and SFTP Drafts 
For those wishing to learn more about the SSH2 and SFTP protocols, see:
<ul>
 <li><a href="http://www.faqs.org/rfcs/rfc4250.html">SSH Assigned Numbers (RFC 4250)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4251.html">SSH Architecture (RFC 4251)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4252.html">SSH Authentication (RFC 4252)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4253.html">SSH Transport Layer (RFC 4253)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4254.html">SSH Connection (RFC 4254)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4256.html">SSH Keyboard-Interactive Authentication (RFC 4256)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4335.html">SSH Channel "Break" Extension (RFC 4335)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4344.html">SSH Transport Encryption Modes (RFC 4344)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4345.html">SSH Improved Arcfour Modes (RFC 4345)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4419.html">SSH Diffie-Hellman Group Exchange Protocol (RFC 4419)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4432.html">SSH RSA Key Exchange Protocol (RFC 4432)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc4716.html">SSH Public Key File Format (RFC 4716)</a>
 <li><a href="http://www.vandyke.com/technology/draft-ietf-secsh-filexfer.txt">SFTP Draft</a>
 <li><a href="http://tools.ietf.org/html/draft-ietf-secsh-filexfer-extensions-00">SFTP Extensions Draft</a>
 <li><a href="http://www.faqs.org/rfcs/rfc5656.html">SSH Elliptic Curve Algorithms (RFC 5656)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc6668.html">SSH SHA-2 HMACs (RFC 6668)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc8270.html">SSH Increased Minimum DH Group Size (RFC 8270)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc8308.html">SSH Extension Negotiation (RFC 8308)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc8332.html">Use of RSA Keys with SHA-256 and SHA-512 in the SSH Protocol (RFC 8332)</a>
 <li><a href="http://www.faqs.org/rfcs/rfc8731.html">SSH Key Exchange Method Using Curve25519 and Curve448 (RFC 8731)</a>
</ul>

The <code>mod_sftp</code> module for ProFTPD 
The <code>mod_sftp</code> module implements the SSH2 protocol and its SFTP
subsystem, for secure file transfer over an SSH2 connection. The
<code>mod_sftp</code> module supports:
<ul>
 <li>Public key authentication
 <li>Password authentication (e.g. user authentication via
 <code>mod_sql</code>, <code>mod_ldap</code>, <code>mod_auth_file</code>,
 <code>mod_auth_unix</code>, <code>mod_auth_pam</code>)
 <li>SCP support
 <li>Quotas (via the <code>mod_quotatab</code> module)
 <li>FIPS support (see <a href="#Usage">Usage</a> section)
 <li>Throttled transfers (via <code>TransferRate</code>, and/or the
 <code>mod_shaper</code> module)
 <li>Blacklisted public keys
 <li>Configurable traffic analysis protection
 <li>Passphrase-protected host keys
 <li>SFTP extensions: check-file, copy-file, vendor-id, version-select, posix-rename@openssh.com, statvfs@openssh.com, fstatvfs@openssh.com, hardlink@openssh.com
</ul>
This module supports the SFTP and SCP file transfer protocols; it does
not support shell access.

The <code>mod_sftp</code> module does not currently support:
<ul>
 <li><code>&lt;Anonymous&gt;</code>
 <li><code>ListOptions</code>
 <li><code>MaxRetrieveFileSize</code>
</ul>

The <code>mod_sftp</code> module is contained in the <code>mod_sftp/</code>
directory, is intended for ProFTPD 1.3.3rc1 and later, and is not compiled by
default. Installation instructions are discussed
<a href="#Installation">here</a>.

The most current version of <code>mod_sftp</code> is distributed with the
ProFTPD source code.

This product includes software developed by the OpenSSL Project for use in the
OpenSSL Toolkit (<a href="http://www.openssl.org/">http://www.openssl.org/</a>).
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com).

<h2>Author</h2>

Please contact TJ Saunders &lt;tj at castaglia.org&gt; with any
questions, concerns, or suggestions regarding this module.

<h2>Directives</h2>
<ul>
 <li><a href="#SFTPAcceptEnv">SFTPAcceptEnv</a>
 <li><a href="#SFTPAuthMethods">SFTPAuthMethods</a>
 <li><a href="#SFTPAuthorizedHostKeys">SFTPAuthorizedHostKeys</a>
 <li><a href="#SFTPAuthorizedUserKeys">SFTPAuthorizedUserKeys</a>
 <li><a href="#SFTPCiphers">SFTPCiphers</a>
 <li><a href="#SFTPClientAlive">SFTPClientAlive</a>
 <li><a href="#SFTPClientMatch">SFTPClientMatch</a>
 <li><a href="#SFTPCompression">SFTPCompression</a>
 <li><a href="#SFTPCryptoDevice">SFTPCryptoDevice</a>
 <li><a href="#SFTPDHParamFile">SFTPDHParamFile</a>
 <li><a href="#SFTPDigests">SFTPDigests</a>
 <li><a href="#SFTPDisplayBanner">SFTPDisplayBanner</a>
 <li><a href="#SFTPEngine">SFTPEngine</a>
 <li><a href="#SFTPExtensions">SFTPExtensions</a>
 <li><a href="#SFTPHostKey">SFTPHostKey</a>
 <li><a href="#SFTPHostKeys">SFTPHostKeys</a>
 <li><a href="#SFTPKeyBlacklist">SFTPKeyBlacklist</a>
 <li><a href="#SFTPKeyExchanges">SFTPKeyExchanges</a>
 <li><a href="#SFTPKeyLimits">SFTPKeyLimits</a>
 <li><a href="#SFTPLog">SFTPLog</a>
 <li><a href="#SFTPMaxChannels">SFTPMaxChannels</a>
 <li><a href="#SFTPOptions">SFTPOptions</a>
 <li><a href="#SFTPPassPhraseProvider">SFTPPassPhraseProvider</a>
 <li><a href="#SFTPRekey">SFTPRekey</a>
 <li><a href="#SFTPTrafficPolicy">SFTPTrafficPolicy</a>
</ul>

<hr>
<h3><a name="SFTPAcceptEnv">SFTPAcceptEnv</a></h3>
Syntax: SFTPAcceptEnv env1 ... 
Default: LANG 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.3rc3 and later

The <code>SFTPAcceptEnv</code> directive specifies which environment variables
sent by the client, if any, will be used in the session environment.
Environment variables are specified by name, and may contain the '*' and '?'
wildcard characters. Multiple environment variables may be configured, either
separated by whitespace or spread across multiple <code>SFTPAcceptEnv</code>
directives.

Be warned that some environment variables may have special meaning to
underlying libraries; care should be taken in the use of this directive.

<hr>
<h3><a name="SFTPAuthMethods">SFTPAuthMethods</a></h3>
Syntax: SFTPAuthMethods meth1 ... 
Default: publickey password 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPAuthMethods</code> directive configures the list of available
authentication methods presented to connecting clients. The list of
currently supported methods is:
<ul>
 <li>hostbased
 <li>keyboard-interactive
 <li>password
 <li>publickey
</ul>
In general, there is no need to use this directive unless only one specific
authentication method must be used. Should it be needed, the list of
authentication methods to use is provided as a space-delimited list,
e.g.:
<pre>
 # Offer publickey and keyboard-interactive authentication only
 SFTPAuthMethods publickey keyboard-interactive
</pre>

The hostbased authentication method is only offered to clients if
the <a href="#SFTPAuthorizedHostKeys"><code>SFTPAuthorizedHostKeys</code></a>
directive is configured.

The publickey authentication method is only offered to clients if
the <a href="#SFTPAuthorizedUserKeys"><code>SFTPAuthorizedUserKeys</code></a>
directive is configured.

The keyboard-interactive authentication method is only offered to
clients if the <a href="mod_sftp_pam.html"><code>mod_sftp_pam</code></a>
or <a href="mod_auth_otp.html"><code>mod_auth_otp</code></a> module is present.

As of <code>proftpd-1.3.6rc2</code> and later, you can use the
<code>SFTPAuthMethods</code> directive to configure chains of
methods. An authentication chain is a list of authentication
methods, all of which must succeed in order for login to succeed.
For example, using:
<pre>
 # Require both publickey and password authentication
 SFTPAuthMethods publickey+password
</pre>
Note that order of the methods in a chain is important. In the above
example, the publickey authentication must succeed first, before
password authentication will be offered. If you want require both
publickey and password authentication, but that they can be used in any
order, you can configure multiple chains:
<pre>
 # Require both publickey and password authentication, in any order
 SFTPAuthMethods publickey+password password+publickey
</pre>
As long as any one chain is completed, login will succeed.

You can even require that multiple different keys be used (e.g. a
RSA and a DSA public key, or multiple different RSA/DSA keys) using:
<pre>
 # Require different keys for publickey authentication
 SFTPAuthMethods publickey+publickey
</pre>

<hr>
<h3><a name="SFTPAuthorizedHostKeys">SFTPAuthorizedHostKeys</a></h3>
Syntax: SFTPAuthorizedHostKeys store1 ... 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPAuthorizedHostKeys</code> directive configures the file that
<code>mod_sftp</code> will use during the handling of hostbased authentication
of users. The configured file may contain several public keys in RFC4716
format, in no particular order.

Note that a <code>SFTPAuthorizedHostKeys</code> directive is
required for <code>mod_sftp</code> to handle sessions which want to use
hostbased authentication properly.

Note: In order to use OpenSSH public keys in a
<code>SFTPAuthorizedHostKeys</code>, you must convert them to the
RFC4716 format (see the <a href="#UsageRFC4716Format">Usage</a> section).
This is done using OpenSSH's <code>ssh-keygen</code> tool:
<pre>
 $ ssh-keygen -e -f /path/to/file
</pre>
The output from this command can then be added to the
<code>SFTPAuthorizedHostKeys</code> file.

<hr>
<h3><a name="SFTPAuthorizedUserKeys">SFTPAuthorizedUserKeys</a></h3>
Syntax: SFTPAuthorizedUserKeys store1 ... 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPAuthorizedUserKeys</code> directive configures the file that
<code>mod_sftp</code> will use during the handling of publickey authentication
of users. The configured file may contain several public keys in RFC4716
format, in no particular order.

Example:
<pre>
 SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys
</pre>

Note: In order to use OpenSSH public keys in a
<code>SFTPAuthorizedUserKeys</code>, you must convert them to the
RFC4716 format (see the <a href="#UsageRFC4716Format">Usage</a> section).
This is done using OpenSSH's <code>ssh-keygen</code> tool:
<pre>
 $ ssh-keygen -e -f ~/.ssh/id_rsa.pub
</pre>
The output from this command can then be added to the
<code>SFTPAuthorizedUserKeys</code> file.

The configured path for a file containing authorized keys can use the
<code>%u</code> variable, which will be interpolated with the name of the user
being authenticated. This feature supports having per-user files of authorized
keys that reside in a central location, rather than requiring (or allowing)
users to manage their own authorized keys. For example:
<pre>
 SFTPAuthorizedUserKeys file:/etc/sftp/authorized_keys/%u
</pre>

<hr>
<h3><a name="SFTPCiphers">SFTPCiphers</a></h3>
Syntax: SFTPCiphers algo1 ... 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPCiphers</code> directive is used to specify the list of
cipher algorithms that <code>mod_sftp</code> should use. The current list
of supported cipher algorithms is, in the default order of preference:
<ul>
 <li>aes256-ctr
 <li>aes192-ctr
 <li>aes128-ctr
 <li>aes256-gcm@openssh.com
 <li>aes128-gcm@openssh.com
 <li>aes256-cbc
 <li>aes192-cbc
 <li>aes128-cbc
 <li>cast128-cbc
 <li>3des-ctr
 <li>3des-cbc
</ul>
By default, all of the above cipher algorithms are presented to the client,
in the above order, during the key exchange.

In ProFTPD 1.3.7rc1 and later, the following list of algorithms are
supported, but not presented to clients by default. These
algorithms must be explicitly configured via <code>SFTPCiphers</code>
to be available for use by clients:
<ul>
 <li>blowfish-ctr
 <li>blowfish-cbc
 <li>arcfour256
 <li>arcfour128
</ul>

The "none" cipher (i.e. no encryption) will not be presented to
the client by default; any sites which wish to use "none" will have to
explicitly configure it via <code>SFTPCiphers</code>.

Note that CTR mode ciphers (e.g. the <code>aes128-ctr</code>,
<code>aes192-ctr</code>, and <code>aes256-ctr</code> ciphers) are recommended.
Any CBC mode cipher allows for the possibility of an attack which causes
several bits of plaintext to be leaked; the attack is described
<a href="http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt">here</a>.
This attack is on the SSH2 protocol design itself; any SSH2 implementation
which conforms to the RFCs will have this weakness.

In general, there is no need to use this directive unless only one specific
cipher must be used.

For comparison, the cipher algorithms used by OpenSSH by default are:
<ul>
 <li>aes128-cbc
 <li>3des-cbc
 <li>blowfish-cbc
 <li>cast128-cbc
 <li>arcfour128
 <li>arcfour256
 <li>aes192-cbc
 <li>aes256-cbc
 <li>aes128-ctr
 <li>aes192-ctr
 <li>aes256-ctr
 <li>aes128-gcm@openssh.com
 <li>aes256-gcm@openssh.com
</ul>
Thus if you wanted to configure <code>mod_sftp</code> to present the same
cipher algorithms as OpenSSH, you would use:
<pre>
 # Make mod_sftp present the same ciphers as OpenSSH
 SFTPCiphers aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour128 \
 arcfour256 aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr \
 aes128-gcm@openssh.com aes256-gcm@openssh.com
</pre>

<hr>
<h3><a name="SFTPClientAlive">SFTPClientAlive</a></h3>
Syntax: SFTPClientAlive count interval 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.4rc1 and later

The <code>SFTPClientAlive</code> directive configured <code>mod_sftp</code>
to send messages to a client, through the encrypted channel, to request a
response from the client. If count client alive messages are sent
without receiving any response messages from the client, the client will
be disconnected. The interval indicates how much time, in seconds,
that <code>mod_sftp</code> waits for data from the client before sending a
client alive message.

For example, using:
<pre>
 SFTPClientAlive 3 15
</pre>
will cause an unresponsive client to be disconnected after approximately 45
seconds.

<hr>
<h3><a name="SFTPClientMatch">SFTPClientMatch</a></h3>
Syntax: SFTPClientMatch pattern key1 val1 ... 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPClientMatch</code> directive is used to tune some of the
SSH2/SFTP values based on the connecting client, for better interoperability
with those clients. The pattern parameter specifies a POSIX regular
expression which will be matched against the connecting client's SSH version
banner. If the client's banner version matches pattern, then
the configured keys/values are used for that session.

The currently supported SSH2/SFTP keys which can be tuned via
<code>SFTPClientMatch</code> are:
<ul>
 <li>channelPacketSize 
 The value for this key can be a number, with an optional "KB"
 (kilobytes) suffix.

The default <code>mod_sftp</code> channel packet size is 32KB.
 </li>

<li>channelWindowSize
 The value for this key can be a number, with an optional
 "GB" (gigabytes), "MB" (megabytes), or "KB" (kilobytes) suffix.

The default <code>mod_sftp</code> channel window size is 4GB. Using
 smaller window sizes may be necessary for some clients; larger window
 sizes can help reduce latency for bulk data transfers.
 </li>

<li>sftpCiphers
 The value for this key should be a comma-separated list
 of cipher algorithms, as for the
 <a href="#SFTPCiphers><code>SFTPCiphers</code></a> directive. Use of
 this key automatically enables the <code>PessimisticKexinit</code>
 SFTPOption as well.

Note that this option first appeared in
 <code>proftpd-1.3.8rc4</code>.
 </li>

<li>sftpDigests
 The value for this key should be a comma-separated list
 of digest algorithms, as for the
 <a href="#SFTPDigests><code>SFTPDigests</code></a> directive. Use of
 this key automatically enables the <code>PessimisticKexinit</code>
 SFTPOption as well.

Note that this option first appeared in
 <code>proftpd-1.3.8rc4</code>.
 </li>

<li>sftpHostKeys
 The value for this key should be a comma-separated list
 of host key algorithms, as for the
 <a href="#SFTPHostKeys><code>SFTPHostKeys</code></a> directive. Use of
 this key automatically enables the <code>PessimisticKexinit</code>
 SFTPOption as well.

Note that this option first appeared in
 <code>proftpd-1.3.8rc4</code>.
 </li>

<li>sftpKeyExchanges
 The value for this key should be a comma-separated list
 of key exchange algorithms, as for the
 <a href="#SFTPKeyExchanges"><code>SFTPKeyExchanges</code></a> directive.
 Use of this key automatically enables the
 <code>PessimisticKexinit</code> SFTPOption as well.

Note that this option first appeared in
 <code>proftpd-1.3.8rc4</code>.
 </li>

<li>sftpProtocolVersion
 The value for this key can be a specific version number,
 e.g. "3", or it can be a range such as "1-3". The
 <code>mod_sftp</code> module supports SFTP protocol versions 1-6;
 using any other protocol versions will result in bad configuration.
 </li>

<li>sftpUTF8ProtocolVersion
 The value for this key is a specific version number,
 e.g. "3". The <code>mod_sftp</code> module uses UTF8 encoding
 for handling paths/strings in SFTP messages for protocol version 4 and
 above by default; this key can be used to change the protocol versions for
 which UTF8 encoding is used.

For example, if you set:
<pre>
 SFTPClientMatch .* sftpUTF8ProtocolVersion 1
</pre>
 then <code>mod_sftp</code> will try to use UTF8 for all SFTP protocol
 versions, all clients.

Note: the <code>sftpUTF8ProtocolVersion</code> key requires
 NLS support (i.e. the <code>--enable-nls</code> configure option).
 </li>
</ul>

For example, to make <code>mod_sftp</code> only allow SFTP protocol version 3
to WinSCP clients, you would use:
<pre>
 SFTPClientMatch ".*WinSCP.*" sftpProtocolVersion 3
</pre>
Or for older OpenSSH clients, you may need to use a smaller channel window
size, e.g.:
<pre>
 SFTPClientMatch "^OpenSSH_3\\.*" channelWindowSize 8MB
</pre>

<hr>
<h3><a name="SFTPCompression">SFTPCompression</a></h3>
Syntax: SFTPCompression on|off|delayed 
Default: off 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPCompression</code> directive enables the use of zlib compression
of the payload of SSH2 packets. This can make for smaller packets, but require
more CPU time to compress/uncompress the data.

The delayed parameter tells <code>mod_sftp</code> to support a custom
extension used by OpenSSH, where compression is not actually enabled until
after the client has successfully authenticated.

<hr>
<h3><a name="SFTPCryptoDevice">SFTPCryptoDevice</a></h3>
Syntax: SFTPCryptoDevice driver|"all"|"none" 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPCryptoDevice</code> directive is used to configure
<code>mod_sftp</code> to use an OpenSSL "engine", a cryptographic module
that OpenSSL library can use for accelerated cryptographic support, or
HSM keys, etc.

To use all of the engines compiled into OpenSSL, use:
<pre>
 SFTPCryptoDevice all
</pre>
OpenSSL will find, from the list of supported engines, the first one
usable, if any. If no usable engines are found, OpenSSL will default to
its normal software implementation. If a specific engine is desired as
the default engine to use, specify the engine name, e.g.:
<pre>
 SFTPCryptoDevice chil
</pre>

The OpenSSL command
<pre>
 openssl engine
</pre>
may be used to list all of the engine drivers supported by OpenSSL.

<hr>
<h3><a name="SFTPDHParamFile">SFTPDHParamFile</a></h3>
Syntax: SFTPDHParamFile path 
Default: dhparams.pem 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPDHParamFile</code> directive is used to configure the path
to a file containing pre-computed Diffie-Hellman (DH) group parameters.
These parameters will be used by <code>mod_sftp</code> when handling the
Diffie-Hellman group exchange (see RFC 4419) portion of the key exchange.

The <code>SFTPDHParamFile</code> is produced using OpenSSL, which uses
PEM encodings of PKCS#3 <code>DHparam</code> structures. It is similar in
nature to OpenSSH's <code>moduli(5)</code> file.

The <code>mod_sftp</code> source code comes with a <code>dhparams.pem</code>
file which should be sufficient. If for any reason you find that you
need to generate your own <code>SFTPDHParamFile</code>, use one of the
following OpenSSL commands to create this file:
<pre>
 # openssl dhparam -outform PEM -2 nbits >> dhparams.pem
 # openssl dhparam -outform PEM -5 nbits >> dhparams.pem
</pre>
Using either <code>-2</code> or <code>-5</code> as the generator is fine.
The nbits value used should vary between 1024 and 8192, inclusive.
Beware: this process is quite slow, and CPU/memory intensive!

<hr>
<h3><a name="SFTPDigests">SFTPDigests</a></h3>
Syntax: SFTPDigests algo1 ... 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPDigests</code> directive is used to specify the list of
MAC digest algorithms that <code>mod_sftp</code> should use. The current list
of supported MAC algorithms is:
<ul>
 <li>hmac-sha2-256
 <li>hmac-sha2-256-etm@openssh.com
 <li>hmac-sha2-512
 <li>hmac-sha2-512-etm@openssh.com
 <li>hmac-sha1
 <li>hmac-sha1-etm@openssh.com
 <li>hmac-sha1-96
 <li>hmac-sha1-96-etm@openssh.com
 <li>umac-64@openssh.com
 <li>umac-64-etm@openssh.com
 <li>umac-128@openssh.com
 <li>umac-128-etm@openssh.com
</ul>
By default, all of the above MAC algorithms are presented to the client,
in the above order, during the key exchange. Note that some algorithms
(e.g. the SHA256 and SHA512 algorithms) may not be supported by
the version of OpenSSL used; this will be automatically detected.

The following list of algorithms are supported, but not
presented to clients by default. These algorithms must be explicitly
configured via <code>SFTPDigests</code> to be available for use by clients:
<ul>
 <li>hmac-md5
 <li>hmac-md5-etm@openssh.com
 <li>hmac-md5-96
 <li>hmac-ripemd160
</ul>

The "none" MAC (i.e. no MAC) will not be presented to the client
by default; any sites which wish to use "none" will have to explicitly
configure it via <code>SFTPDigests</code>.

In general, there is no need to use this directive unless only one specific
MAC algorithm must be used.

For comparison, the MAC algorithms used by OpenSSH (depending on the version)
by default are:
<ul>
 <li>hmac-md5
 <li>hmac-md5-etm@openssh.com
 <li>hmac-sha1
 <li>hmac-sha1-etm@openssh.com
 <li>hmac-sha2-256
 <li>hmac-sha2-256-etm@openssh.com
 <li>hmac-sha2-512
 <li>hmac-sha2-512-etm@openssh.com
 <li>hmac-ripemd160
 <li>hmac-sha1-96
 <li>hmac-md5-96
 <li>umac-64@openssh.com
 <li>umac-64-etm@openssh.com
 <li>umac-128@openssh.com
 <li>umac-128-etm@openssh.com
</ul>
Thus if you wanted to configure <code>mod_sftp</code> to present the same
MAC algorithms as OpenSSH, you would use:
<pre>
 # Make mod_sftp present the MAC ciphers as OpenSSH
 SFTPDigests hmac-md5 hmac-sha1 hmac-sha2-256 hmac-sha2-512 \
 hmac-ripemd160 hmac-sha1-96 hmac-md5-96 umac-64@openssh.com \
 umac-128@openssh.com
</pre>

<hr>
<h3><a name="SFTPDisplayBanner">SFTPDisplayBanner</a></h3>
Syntax: SFTPDisplayBanner path 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPDisplayBanner</code> directive is used to configure the path
of a file which will be sent to the client prior to authentication. Such
files are often used to sent terms of use or other such policy terms to
connecting clients.

See the <a href="../howto/DisplayFiles.html">Display files</a> howto for
more information on the variables that can be used in an
<code>SFTPDisplayBanner</code> file.

<hr>
<h3><a name="SFTPEngine">SFTPEngine</a></h3>
Syntax: SFTPEngine on|off 
Default: off 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPEngine</code> directive toggles the use of the SSH2/SFTP protocols
engine (e.g. <code>mod_sftp</code>). This is usually used inside a
<code>&lt;VirtualHost&gt;</code> section to enable SFTP sessions for a
particular virtual host. By default <code>mod_sftp</code> is disabled for both
the main server and all configured virtual hosts.

<hr>
<h3><a name="SFTPExtensions">SFTPExtensions</a></h3>
Syntax: SFTPExtensions ext1 ... extN 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.3rc3 and later

The <code>SFTPExtensions</code> directive can be used to enable/disable
support for the various SFTP extensions supported by <code>mod_sftp</code>.
The extension names used for the <code>SFTPExtensions</code> directive are:
<ul>
 <li>checkFile
 <li>copyFile
 <li>fsync
 <li>hardlink
 <li>homeDirectory
 <li>posixRename
 <li>spaceAvailable
 <li>statvfs
 <li>vendorID
 <li>versionSelect
 <li>xattr
</ul>
All extensions except <code>vendorID</code> and
<code>xattr</code> are enabled by default.

To enable an extension, preface the extension name with a '+' (plus) character;
to disable the extension, use a '-' (minus) character prefix. For example:
<pre>
 # Allow the copy-file extension, but not version-select
 SFTPExtensions +copyFile -versionSelect
</pre>

<hr>
<h3><a name="SFTPHostKey">SFTPHostKey</a></h3>
Syntax: SFTPHostKey file|agent:/path|"NoRSA"|"NoDSA"|"NoECDSA" 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPHostKey</code> directive configures the path to a host key file.
The <code>mod_sftp</code> module uses the keys thus configured as part of
the SSH2 key exchange process.

Note that the <code>SFTPHostKey</code> directive is required. You
can use either an RSA key, a DSA key, and/or ECDSA keys. These should be the
exact same host key files as used by your SSH2 server, e.g.:
<pre>
 SFTPHostKey /etc/ssh_host_dsa_key
 SFTPHostKey /etc/ssh_host_rsa_key
 SFTPHostKey /etc/ssh_host_ecdsa_key
 SFTPHostKey /etc/ssh_host_ed25519_key
</pre>
or the equivalents in the <code>/usr/local/etc/</code> directory. Using
different host keys between your SSH2 server and <code>mod_sftp</code> will
only cause confusion and problems for any SFTP clients. Most SFTP clients
will assume that the host uses the same keys for SSH2 and SFTP; after all,
it is the same host (even the same port), just different services.
Thus having different host keys for an SSH2 server and <code>mod_sftp</code>
will cause clients to constantly switch the host keys they record for the
same host (and cause confusion for users).

The <code>SFTPHostKey</code> directive, as of <code>proftpd-1.3.5rc1</code>
and later, can also be used to load host keys from an SSH agent such as
OpenSSH's <code>ssh-agent</code>. For example:
<pre>
 # Load all of the keys from the ssh-agent configured for server use
 SFTPHostKey agent:%{env:SSH_AUTH_SOCK}
</pre>
Using an SSH agent for storing host keys allows for configurations where
the host keys are not stored on files on the server system, e.g.
the keys can be loaded into the SSH agent from a PKCS#11 token.

The <code>SFTPHostKey</code> directive, as of <code>proftpd-1.3.6rc1</code>
and later, can be used to disable host keys configured via
<code>&lt;Global&gt;</code>. For example, if you have a global RSA key that
you wish to disable in all vhosts, you might use the "NoRSA" flag, e.g.:
<pre>
 &lt;Global&gt;
 SFTPHostKey /path/to/ssh_rsa_host_key
 ...
 &lt;/Global&gt;

&lt;VirtualHost a.b.c.d&gt;
    ...
    # Configure our per-vhost DSA host key
    SFTPHostKey /path/to/ssh_dsa_host_key

# ...and disable the global RSA host key
 SFTPHostKey NoRSA
 ...
 &lt;/VirtualHost&gt;
</pre>

OpenSSH started using an OpenSSH-specific private key format in version 7.8.
ProFTPD did not support reading this OpenSSH-specific format until 1.3.7. Thus
if you need to use SSH hostkeys in the OpenSSH-specific private key format
with ProFTPD prior to 1.3.7, you will need to convert those private keys to
the more conventional PEM format that <code>mod_sftp</code> supported. If
your <code>SFTPHostKey</code> file starts with:
<pre>
-----BEGIN OPENSSH PRIVATE KEY-----
</pre>
then it is using the OpenSSH-specific private key format. To convert this
private key to a PEM private key, use e.g.:
<pre>
$ cp /etc/ssh/ssh_host_rsa_key /etc/proftpd/ssh_host_rsa_key
$ ssh-keygen -p -f /etc/proftpd/ssh_host_rsa_key -m PEM
</pre>
Note that you cannot use the <code>-e</code> option for this:
<pre>
$ ssh-keygen -e -f /etc/ssh/ssh_host_rsa_key -m PEM > /etc/proftpd/ssh_host_rsa_key
</pre>
Since that "exports" the corresponding public key, not the
private key as you would want for a hostkey.

<hr>
<h3><a name="SFTPHostKeys">SFTPHostKeys</a></h3>
Syntax: SFTPHostKeys algo1 ... 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.8rc4 and later

The <code>SFTPHostKeys</code> directive is used to specify the list of host
key algorithms that <code>mod_sftp</code> should use. The current list
of supported host key algorithms is:
<ul>
 <li>ssh-ed448
 <li>ssh-ed25519
 <li>ecdsa-sha2-nistp256
 <li>ecdsa-sha2-nistp384
 <li>ecdsa-sha2-nistp521
 <li>rsa-sha2-512
 <li>rsa-sha2-256
 <li>ssh-rsa
 <li>ssh-dss
</ul>
By default, all of the above host key algorithms are presented to the
client, in the above order, during the key exchange, assuming that
a suitable <code>SFTPHostKey</code> file for that algorithm has been provided.

In general, there is no need to use this directive unless specific host keys
algorithm must be used (or avoided).

<hr>
<h3><a name="SFTPKeyBlacklist">SFTPKeyBlacklist</a></h3>
Syntax: SFTPKeyBlacklist "none"|path 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPKeyBlacklist</code> directive configures the path to
a specially formatted dictionary of known weak public keys. This key
blacklist, and the code for using it, was primarily developed by
Dmitry V. Levin under sponsorship by
<a href="http://www.civicactions.com">CivicActions</a>. For the original
posting, and further information, see:
<pre>
 <a href="http://www.openwall.com/lists/oss-security/2008/05/27/3">http://www.openwall.com/lists/oss-security/2008/05/27/3</a>
</pre>

These known weak public keys arose because of a vulnerability in the OpenSSL
packages distributed by Debian:
<pre>
 <a href="http://www.debian.org/security/2008/dsa-1571">http://www.debian.org/security/2008/dsa-1571</a>
</pre>

The <code>mod_sftp</code> source code comes with a <code>blacklist.dat</code>
file which should be sufficient. If for any reason you find that you
need to generate your own <code>SFTPDKeyBlacklist</code>, use the
<code>blacklist-encode</code> program mentioned in the above URLs.

<hr>
<h3><a name="SFTPKeyExchanges">SFTPKeyExchanges</a></h3>
Syntax: SFTPKeyExchanges algo1 ... 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPKeyExchanges</code> directive is used to specify the list of
key exchange algorithms that <code>mod_sftp</code> should use. The current list
of supported key exchange algorithms is:
<ul>
 <li>curve448-sha512
 <li>curve25519-sha256
 <li>ecdh-sha2-nistp521
 <li>ecdh-sha2-nistp384
 <li>ecdh-sha2-nistp256
 <li>diffie-hellman-group18-sha512
 <li>diffie-hellman-group16-sha512
 <li>diffie-hellman-group14-sha256
 <li>diffie-hellman-group-exchange-sha256
 <li>diffie-hellman-group-exchange-sha1
 <li>diffie-hellman-group14-sha1
 <li>diffie-hellman-group1-sha1
 <li>rsa1024-sha1
</ul>
By default, all of the above key exchange algorithms except
<code>diffie-hellman-group1-sha1</code> are presented to the client, in
the above order, during the key exchange.

Note that the <code>diffie-hellman-group1-sha1</code> key exchange
algorithm uses a weak hardcoded Diffie-Hellman group, and thus is not
enabled by default. To enable this key exchange algorithm, you must
configure the <code>SFTPKeyExchanges</code> list to explicitly include
this algorithm, or use the following in your configuration:
<pre>
 SFTPOptions AllowWeakDH
</pre>

Note that the <code>curve448-sha512</code> key exchange algorithm
requires an Ed448 SSH host key. To generate such a key, use:
<pre>
 openssl genpkey -out /etc/ssh/ssh_host_ed448_key -algorithm ED448
</pre>

In general, there is no need to use this directive unless only one specific
key exchange algorithm must be used.

<hr>
<h3><a name="SFTPKeyLimits">SFTPKeyLimits</a></h3>
Syntax: SFTPKeyLimits limit1 ... 
Default: MinimumRSASize 768 MinimumDSASize 384 MinimumECSize 160None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.6rc3 and later

The <code>SFTPKeyLimits</code> directive is used to configure limits on the
sizes of keys (in terms of bits), both host keys and user keys.
The currently supported limits are:
<ul>
 <li><code>MinimumDSASize</code>
 <li><code>MinimumECSize</code>
 <li><code>MinimumRSASize</code>
</ul>

Examples:
<pre>
 # Require at least 1024-bit RSA keys; leave other default limits alone
 SFTPKeyLimits MinimumRSASize 1024

# Require at least 256-bit EC keys, and remove other default limits
 SFTPKeyLimits MinimumECSize 256 MinimumDSASize 0 MinimumRSASize 0
</pre>

<hr>
<h3><a name="SFTPLog">SFTPLog</a></h3>
Syntax: SFTPLog file|"none" 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPLog</code> directive is used to specify a log file for
<code>mod_sftp</code>'s reporting on a per-server basis. The file
parameter given must be the full path to the file to use for logging.

Note that this path must not be to a world-writable directory and,
unless <code>AllowLogSymlinks</code> is explicitly set to on
(generally a bad idea), the path must not be a symbolic link.

<hr>
<h3><a name="SFTPMaxChannels">SFTPMaxChannels</a></h3>
Syntax: SFTPMaxChannels count 
Default: 10 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPMaxChannels</code> directive is used to configure the maximum
number of simultaneously open channels permitted for a client. The
default value is 10.

A malicious client might try to abuse the server's resources by opening
an large number of SSH2 channels and then not using them. Most well-behaved
SSH2 clients only ever open one channel.

<hr>
<h3><a name="SFTPOptions">SFTPOptions</a></h3>
Syntax: SFTPOptions opt1 ... 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPOptions</code> directive is used to configure various optional
behavior of <code>mod_sftp</code>.

For example:
<pre>
 SFTPOptions IgnoreSFTPUploadPerms IgnoreSCPUploadPerms PessimisticKexinit
</pre>

The currently implemented options are:
<ul>
 <li><code>AllowInsecureLogin</code> 
 
 By default, <code>mod_sftp</code> will not allow password or
 keyboard-interactive authentication if either the 'none' cipher
 or MAC/digest is selected. (These must be explicitly allowed via
 <code>SFTPCiphers</code> and <code>SFTPDigests</code> as well.) However,
 some sites may deliberately wish to allow such logins, as for e.g.
 performance testing. To allow such logins/sessions, then, use this option.

Note that this option first appeared in
 <code>proftpd-1.3.5</code>.
 </li>

<li><code>AllowWeakDH</code> 
 
 The <code>mod_sftp</code> will not use Diffie-Hellman groups of less
 than 2048 bits, due to <a href="https://www.weakdh.org">weaknesses</a>
 that can downgrade the security of an SSH session. If for any reason
 your SFTP/SCP clients require smaller Diffie-Hellman groups, then
 use this option.

Note that this option first appeared in
 <code>proftpd-1.3.6rc1</code>.
 </li>

<li><code>IgnoreFIFOs</code>
 
 By default, <code>mod_sftp</code> allows uploading and downloading of FIFOs,
 just as if they were regular files. However, in some cases this can lead
 to "hangs" on the SFTP/SCP client end, especially when the FIFO
 reader/writer processes are not running at the time. Thus to tell
 <code>mod_sftp</code> to ignore/reject requests to read from/write to FIFOs,
 for both SFTP and SCP, use this option.

Note that this option first appeared in
 <code>proftpd-1.3.6rc3</code>.
 </li>

<li><code>IgnoreSCPUploadPerms</code> 
 
 When an SCP client uploads a file, the desired permissions on the file
 are sent to the server as part of the upload. (This is different from
 FTP, which does not include the file permissions in an upload.)
 If you need more FTP-like functionality for any reason and wish to
 have <code>mod_sftp</code> silently ignore any permissions sent by the
 SCP client, use this option.
 </li>

<li><code>IgnoreSCPUploadTimes</code> 
 
 Use this option to have <code>mod_sftp</code> silently ignore any
 timestamps sent by SCP clients as part of the upload.

Note that this option first appeared in
 <code>proftpd-1.3.5rc4</code>.
 </li>

<li><code>IgnoreSFTPSetExtendedAttributes</code> 
 
 Use this option to have <code>mod_sftp</code> silently ignore any
 extended attributes sent by SFTP clients via the <code>SETSTAT</code> or
 <code>FSETSTAT</code> SFTP requests.

Note that this option first appeared in
 <code>proftpd-1.3.6rc3</code>.
 </li>

<li><code>IgnoreSFTPSetOwners</code> 
 
 Use this option to have <code>mod_sftp</code> silently ignore any
 ownership changes sent by SFTP clients via the <code>SETSTAT</code> or
 <code>FSETSTAT</code> SFTP requests; these are equivalent to
 an FTP <code>SITE CHGRP</code> command.

Note that this option first appeared in
 <code>proftpd-1.3.5rc1</code>.
 </li>

<li><code>IgnoreSFTPSetPerms</code> 
 
 Use this option to have <code>mod_sftp</code> silently ignore any
 permissions sent by SFTP clients via the <code>SETSTAT</code> or
 <code>FSETSTAT</code> SFTP requests; these are equivalent to
 an FTP <code>SITE CHMOD</code> command.

Note that this option first appeared in
 <code>proftpd-1.3.4rc2</code>.
 </li>

<li><code>IgnoreSFTPSetTimes</code> 
 
 Use this option to have <code>mod_sftp</code> silently ignore any
 timestamps sent by SFTP clients via the <code>SETSTAT</code> or
 <code>FSETSTAT</code> SFTP requests; these are equivalent to
 an FTP <code>SITE UTIMES</code> command.

Note that this option first appeared in
 <code>proftpd-1.3.4rc4</code>.
 </li>

<li><code>IgnoreSFTPUploadExtendedAttributes</code> 
 
 When an SFTP client uploads a file or creates a directory, the desired
 extended attributes ("xattrs") on the path are sent to the server as part
 of the upload. (This is different from FTP, which does not include
 the file attributes in an upload.) If you need more FTP-like functionality
 for any reason and wish to have <code>mod_sftp</code> silently ignore any
 extended attributes sent by the SFTP client, use this option.

Note that this option first appeared in
 <code>proftpd-1.3.6rc3</code>.
 </li>

<li><code>IgnoreSFTPUploadPerms</code> 
 
 When an SFTP client uploads a file or creates a directory, the desired
 permissions on the path are sent to the server as part of the upload.
 (This is different from FTP, which does not include the file
 permissions in an upload.) If you need more FTP-like functionality for any
 reason and wish to have <code>mod_sftp</code> silently ignore any
 permissions sent by the SFTP client, use this option.
 </li>

<li><code>IncludeSFTPTimes</code> 
 
 Some SFTP clients (e.g. the Rebex SFTP library) do not implement
 SFTP protocol versions 4+ well, and do not request the
 access/modify time attributes but expect/assume that those
 time attributes will be present in the <code>STAT</code> responses.
 Use this option to tell <code>mod_sftp</code> to always include the
 access and modify time attributes in <code>STAT</code> responses for
 clients using SFTP protocol version 4 and higher.

Note that this option first appeared in
 <code>proftpd-1.3.7rc1</code>.
 </li>

<li><code>InsecureHostKeyPerms</code> 
 
 When this option is used, <code>mod_sftp</code> will ignore insecure
 permissions (i.e. group- or world-readable) on
 <code>SFTPHostKey</code> files. This option should appear before
 any <code>SFTPHostKey</code> directives in the configuration, as hostkey
 permissions are checked at configuration parse time.

Note that this option first appeared in
 <code>proftpd-1.3.6rc1</code>.
 </li>

<li><code>MatchKeySubject</code> 
 
 When this option is used, if public key authentication is used, the
 <code>mod_sftp</code> module will check if the public key has a "Subject"
 header. If so, that the value of that header must match the
 name of the authenticating user/host.

Note that this option first appeared in
 <code>proftpd-1.3.4rc1</code>.
 </li>

<li><code>NoExtensionNegotiation</code> 
 
 By default, <code>mod_sftp</code> will offer/support the SSH extension
 negotiation, defined by
 <a href="https://tools.ietf.org/html/rfc8308">RFC 8308</a>. Use this
 option to disable support for extension negotiations.

Note that this option first appeared in
 <code>proftpd-1.3.7rc4</code>.
 </li>

<li><code>NoHostkeyRotation</code> 
 
 By default, <code>mod_sftp</code> will offer/support the OpenSSH
 hostkey rotation extensions, "hostkeys-00@openssh.com" and
 "hostkeys-prove-00@openssh.com". Use this option to disable support for
 these custom OpenSSH extensions.

Note that this option first appeared in
 <code>proftpd-1.3.8rc3</code>.
 </li>

<li><code>OldProtocolCompat</code> 
 
 Older clients identity their protocol versions as "1.99", rather than as
 "2.0". By default, <code>mod_sftp</code> will refuse to handle connections
 from such clients. To enable compatibility with these clients (which
 tend to be derived from ssh.com/Tectia code), use this option.

Note that this option automatically enables the
 <code>PessimisticKexinit</code> SFTPOption as well.

Note that this option first appeared in
 <code>proftpd-1.3.4rc1</code>.
 </li>

<li><code>PessimisticKexinit</code> 
 
 As described <a href="#SFTPTelnetBanner">here</a>, the <code>mod_sftp</code>
 module tries to reduce the connection latency by optimistically sending
 the <code>KEXINIT</code> key exchange message. However, some SSH clients
 cannot handle this behavior. Use this option to disable the optimistic
 sending of the <code>KEXINIT</code> message.

Note that this option first appeared in
 <code>proftpd-1.3.4rc1</code>.
 </li>
</ul>

<hr>
<h3><a name="SFTPPassPhraseProvider">SFTPPassPhraseProvider</a></h3>
Syntax: SFTPPassPhraseProvider path 
Default: None 
Context: server config 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPPassPhraseProvider</code> directive is used to specify an
external program which will be called, when <code>mod_sftp</code> starts up,
for each encrypted host key file. The program will be invoked with two
command-line arguments, passed on <code>stdin</code> to the program:
<pre>
 servername:portnumber file
</pre>
where <code>servername:portnumber</code> indicates the
server using that encrypted certificate key, and file indicates the
host key file in question. The program then must print the corresponding
passphrase for the key to <code>stdout</code>.

The intent is that this external program can perform any security checks
necessary, to make sure that the system is not compromised by an attacker,
and only when these checks pass successfully will the passphrase be provided.
These security checks, and the way the passphrase is determined, can be as
complex as you like.

Example:
<pre>
 SFTPPassPhraseProvider /etc/ftpd/sftp/get-passphrase
</pre>

<hr>
<h3><a name="SFTPRekey">SFTPRekey</a></h3>
Syntax: SFTPRekey "none"|"required" [[interval bytes] timeout] 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPRekey</code> directive configures the session rekey policy
used by the <code>mod_sftp</code> module. When an SSH2 client connects,
there is an initial exchange of hostkey, cipher, digest, and compression
algorithms, followed by sharing of information which leads to the calculation
of shared session keys. These keys are used in the various algorithms.
The exchange of algorithms and calculation of new session keys can happen
at any time during the SSH2 session; this is known as "rekeying".

By default, <code>mod_sftp</code> will only require rekeying when
the packet sequence number (for sent or received SSH2 packets) reaches
a rather high limit. The digest algorithm used, for example, might begin
to leak cryptographically sensitive information if used for too many
packets (see RFC 4344). Outside of these sequence number limits, however,
<code>mod_sftp</code> will not attempt to initiate rekeying.

To prevent <code>mod_sftp</code> from attempting rekeying, use:
<pre>
 SFTPRekey none
</pre>
Note that disabling rekeying altogether is a Very Bad Idea. While rekeying 
can cause delays in the SSH2 session, it is intended to guard against certain
attacks. You should therefore only disable rekeying for certain
SSH2 clients which cannot support rekeying. Please report those clients
(including the client version) to the mod_sftp maintainer, so that that
client can be added to the list of known clients which cannot handle rekeying.

To require rekeying, simply use:
<pre>
 SFTPRekey required
</pre>
With this parameter, <code>mod_sftp</code> will default to requiring a rekey
within 1 hour (3600 seconds) or after 2GB of data sent or received,
whichever happens first. There will be no timeout once a rekeying has been
requested.

However, administrators wishing to use different rekey intervals or rekey
byte limits can use the optional interval (in seconds) and
bytes (in MB) parameters, e.g.:
<pre>
 # Require rekeying after 30 minutes, or 4 GB
 SFTPRekey required 1800 4096
</pre>

Finally, the paranoid administrator may wish to set a timeout, in seconds,
in which a client must complete a session rekeying, otherwise the
client will be disconnected. This would look like:
<pre>
 # Require rekeying after 30 minutes, or 4 GB. If the rekeying is not
 # completed within 5 minutes of a rekey request, disconnect the client.
 SFTPRekey required 1800 4096 300
</pre>
Note that normally such rekey timeouts are not necessary.

<hr>
<h3><a name="SFTPTrafficPolicy">SFTPTrafficPolicy</a></h3>
Syntax: SFTPTrafficPolicy policy 
Default: None 
Context: server config, <code>&lt;VirtualHost&gt;</code>, <code>&lt;Global&gt;</code> 
Module: mod_sftp 
Compatibility: 1.3.2rc2 and later

The <code>SFTPTrafficPolicy</code> directive is used to configure a measure
of protection against traffic analysis attacks. Such attacks use the number
of packets sent, the size of the packets, and the timing of the packets to try
to gain information about the nature of the data being transmitted.

The SSH2 protocol includes a particular message, <code>SSH_MSG_IGNORE</code>,
which all implementations (both clients and servers) must handle by
dropping on the floor. Implementations, like <code>mod_sftp</code>, can
use these messages to add random data to the session in the hopes of making
such traffic analyses more difficult.

The <code>SFTPTrafficPolicy</code> directive supports the following range
of policies; the chances columns list the probability that
<code>mod_sftp</code> will send an <code>SSH_MSG_IGNORE</code> message.

<table border=1 summary="SFTP Traffic Policies">
 <tr>
 <td>Policy Name</td>
 <td>Chances</td>
 <td>Checks</td>
 </tr>

<tr>
 <td>"none"</td>
 <td>Never</td>
 <td>Never</td>
 </tr>

<tr>
 <td>"low"</td>
 <td>1 in 1000</td>
 <td>Every 5 seconds</td>
 </tr>

<tr>
 <td>"medium"</td>
 <td>1 in 100</td>
 <td>Every 5 seconds</td>
 </tr>

<tr>
 <td>"high"</td>
 <td>1 in 10</td>
 <td>Every second</td>
 </tr>

<tr>
 <td>"paranoid"</td>
 <td>Always</td>
 <td>Every second</td>
 </tr>
</table>

The default <code>SFTPTrafficPolicy</code> setting is "none".

However, if a client negotiates the use of a CBC cipher, then a
defensive traffic policy will automatically be used.
<a href="http://www.faqs.org/rfcs/rfc4251.html">RFC 4251</a>, Section 9.3.1,
specifically mentions the insertion of <code>SSH_MSG_IGNORE</code> messages as
a way of mitigating the "Rogaway" attack on CBC ciphers. In order to disable
this automatic mitigation behavior, you must explicitly configure
a <code>SFTPTrafficPolicy</code> setting in your configuration, e.g.
<pre>
 # Disable any automatic protection when CBC ciphers are used
 SFTPTrafficPolicy none
</pre>
Note that this is not recommended!

<hr>
<h2><a name="Installation">Installation</a></h2>
The <code>mod_sftp</code> module is distributed with ProFTPD. For including
<code>mod_sftp</code> as a statically linked module, use:
<pre>
 $ ./configure --enable-openssl --with-modules=mod_sftp ...
</pre>
Alternatively, <code>mod_sftp</code> can be built as a DSO module:
<pre>
 $ ./configure --enable-dso --enable-openssl --with-shared=mod_sftp ...
</pre>
Then follow the usual steps:
<pre>
 $ make
 $ make install
</pre>
Note that if the <code>libsodium</code> library is available,
<code>mod_sftp</code> will auto-detect this, which enables other supported
algorithms. You can ensure that <code>mod_sftp</code> compiles with the
<code>libsodium</code> library like so:
<pre>
 $ ./configure --enable-openssl --with-modules=mod_sftp ... \
 --with-includes=/path/to/libsodium/include \
 --with-libraries=/path/to/libsodium/lib
</pre>

<hr>
<h2><a name="Usage">Usage</a></h2>

Access Controls for SFTP Requests 
Some of the requests supported by SFTP have FTP command equivalents. Other
requests in SFTP have no FTP command equivalent. This makes the use of
<code>&lt;Limit&gt;</code> sections for access controls in <code>mod_sftp</code>
a little interesting.

First, the familiar territory. The following shows the
<code>&lt;Limit&gt;</code> sections for FTP commands (just as for normal FTP
sessions) which are honored by <code>mod_sftp</code>:
<ul>
 <li><code>&lt;Limit DELE&gt;</code> 
 Applies to the <code>REMOVE</code> SFTP request
 </li>

<li><code>&lt;Limit MKD XMKD&gt;</code> 
 Applies to the <code>MKDIR</code> SFTP request
 </li>

<li><code>&lt;Limit MLSD&gt;</code> 
 Applies to the <code>OPENDIR</code> SFTP request
 </li>

<li><code>&lt;Limit LIST NLST&gt;</code> 
 Applies to the <code>READDIR</code> SFTP request, resulting in an
 empty directory listing.
 </li>

<li><code>&lt;Limit RETR&gt;</code> 
 Applies to the <code>READ</code> SFTP request
 </li>

<li><code>&lt;Limit RNFR RNTO&gt;</code> 
 Applies to the <code>RENAME</code> SFTP request
 </li>

<li><code>&lt;Limit RMD XRMD&gt;</code> 
 Applies to the <code>RMDIR</code> SFTP request
 </li>

<li><code>&lt;Limit STOR&gt;</code> 
 Applies to the <code>WRITE</code> SFTP request
 </li>

<li><code>&lt;Limit SITE_CHGRP&gt;</code> 
 Applies to the <code>SETSTAT</code> and <code>FSETSTAT</code> SFTP
 requests when they change file ownership
 </li>

<li><code>&lt;Limit SITE_CHMOD&gt;</code> 
 Applies to the <code>SETSTAT</code> and <code>FSETSTAT</code> SFTP
 requests when they change file permissions
 </li>
</ul>
Thus you can see that <code>mod_sftp</code> will reuse much of your existing
<code>&lt;Limit&gt;</code>-based access controls for SFTP sessions.

For those SFTP requests which have no direct FTP equivalents elsewhere in
<code>proftpd</code>, the <code>mod_sftp</code> module supports some
slightly different <code>&lt;Limit&gt;</code> sections. Note that
the following does not apply to FTP sessions, nor does it imply
that FTP supports these commands:
<ul>
 <li><code>&lt;Limit FSTAT&gt;</code> 
 Applies to the <code>FSTAT</code> SFTP request
 </li>

<li><code>&lt;Limit LSTAT&gt;</code> 
 Applies to the <code>LSTAT</code> SFTP request
 </li>

<li><code>&lt;Limit LOCK&gt;</code> 
 Applies to the <code>LOCK</code> and <code>UNLOCK</code> SFTP requests
 </li>

<li><code>&lt;Limit OPEN&gt;</code> 
 Applies to the <code>OPEN</code> SFTP request
 </li>

<li><code>&lt;Limit READLINK&gt;</code> 
 Applies to the <code>READLINK</code> SFTP request
 </li>

<li><code>&lt;Limit SETSTAT&gt;</code> 
 Applies to the <code>FSETSTAT</code> and <code>SETSTAT</code> SFTP requests
 </li>

<li><code>&lt;Limit STAT&gt;</code> 
 Applies to the <code>STAT</code> SFTP request
 </li>

<li><code>&lt;Limit SYMLINK&gt;</code> 
 Applies to the <code>LINK</code> and <code>SYMLINK</code> SFTP requests
 </li>
</ul>
Not all versions of SFTP support all of these requests; the <code>LOCK</code>
and <code>UNLOCK</code> requests, for example, appear only in later versions
of the SFTP protocol.

What about the <code>READ</code> and <code>WRITE</code> command groups?
<ul>
 <li><code>&lt;Limit READ&gt;</code> 
 Applies to the <code>SYMLINK</code> and <code>READ</code> SFTP requests
 </li>

<li><code>&lt;Limit WRITE&gt;</code> 
 Applies to the <code>LOCK</code>, <code>SETSTAT</code>,
 <code>SYMLINK</code>, and <code>WRITE</code> SFTP requests
 </li>
</ul>

<a name="EnvironmentVariables">
Environment Variables 
The <code>mod_sftp</code> module will set the following environment
variables whenever an SSH2 client connects:
<ul>
 <li><code>SFTP</code>
 <li><code>SFTP_LIBRARY_VERSION</code>
 <li><code>SSH_CONNECTION</code>
</ul>
In addition, the following environment variables will be set (with appropriate
values), once the client has successfully exchanged keys with
<code>mod_sftp</code>:
<ul>
 <li><code>SFTP_CLIENT_BANNER</code>
 <li><code>SFTP_CLIENT_CIPHER_ALGO</code>
 <li><code>SFTP_CLIENT_COMPRESSION_ALGO</code>
 <li><code>SFTP_CLIENT_MAC_ALGO</code>
 <li><code>SFTP_SERVER_CIPHER_ALGO</code>
 <li><code>SFTP_SERVER_COMPRESSION_ALGO</code>
 <li><code>SFTP_SERVER_MAC_ALGO</code>
</ul>
When a client attempts to use publickey authentication, the following variables
may be set:
<ul>
 <li><code>SFTP_USER_AUTH_METHOD</code>
 <li><code>SFTP_USER_PUBLICKEY_ALGO</code>
 <li><code>SFTP_USER_PUBLICKEY_FINGERPRINT</code>
 <li><code>SFTP_USER_PUBLICKEY_FINGERPRINT_ALGO</code>
</ul>
Note that the above variables may be present even if the user was
authenticated by a mechanism other than publickey authentication. This
is intentional; the logs may be used to help troubleshoot failed
authentication attempts, as well as successful authentications.

These values are also available in the <code>session.notes</code> table,
under keys of the names above. These note variables are intended for
informational purposes, e.g. <code>ExtendedLog</code> or
<code>SQLLog</code> directives via the <code>%{note:...}</code> syntax.

<a name="UsageRFC4716Format">
SSH2 Public Key Formats 
SSH2 uses public keys for authentication and message protection. The very
popular OpenSSH server uses a particular file format for storing public
keys in files. However, that format is not portable; it uses a format very
specific to OpenSSH. Thus the <code>mod_sftp</code> module uses a different
format for public keys, specifically, the format specified in
<a href="http://www.faqs.org/rfcs/rfc4716.html">RFC 4716</a>. The hope
is that this format is more interoperable with other SSH2/SFTP implementations.

This means that if you wish to use your OpenSSH public keys with the
<code>mod_sftp</code> module, you will need to convert them from OpenSSH's
format to the RFC4716 format. Fortunately, this is supported by
OpenSSH's <code>ssh-keygen</code> utility, e.g.:
<pre>
 $ ssh-keygen -e -f ~/.ssh/id_rsa.pub
</pre>
The output from this command can be added to the
<code>SFTPAuthorizedUserKeys</code> used by <code>mod_sftp</code>.

Note that the RFC4716 format is not to be used with the
<code>SFTPHostKey</code> directive. Even though OpenSSH's host keys have
".pub" public equivalents, host keys are different from the per-user keys
that are used for authentication.

<a name="ClientIssues"></a>
Known Client Issues 
The following lists some of the various client interoperability issues that
have been encountered, and how to address them.

SSH Channel Window Sizes 
Some SFTP client implementations do not support the large SSH channel window
size that the <code>mod_sftp</code> module uses by default. These clients
include:
<ul>
 <li><a href="http://www.ipswitch.com/WS_FTP">WS_FTP Pro</a>
 <li>OpenSSH 3.0 and older
 <li><a href="http://www.axway.com">Axway</a>
</ul>
This <a href="#SFTPBadWindowSize">FAQ</a> describes the configuration to use
for such clients.

SSH Protocol Version 
If you are using an old ssh.com client, or perhaps a client which derives
from the ssh.com (or Tectia) code, you may see the following error in the
<code>SFTPLog</code> when trying to connect to <code>mod_sftp</code>:
<pre>
 Bad protocol version 'SSH-1.99-3.2.9.1 SSH Secure Shell (non-commercial)' from x.x.x.x
</pre>
To support such clients in <code>mod_sftp</code>, use
<a href="#SFTPOptions"><code>SFTPOptions</code></a> to enable compatibility with
older protocol versions, e.g.:
<pre>
 # Support old ssh.com/Tectia clients
 SFTPOptions OldProtocolCompat
</pre>

SFTP Protocol Versions 
Some SFTP clients do not properly handle some of the newer SFTP protocol
versions. These clients include:
<ul>
 <li><a href="http://winscp.net/">WinSCP</a>
 <li><a href="http://www.cuteftp.com/products/ftp_clients.aspx">CuteFTP</a>
</ul>
For these clients, use a
<a href="#SFTPClientMatch"><code>SFTPClientMatch</code></a> rule to restrict
the SFTP protocol versions offered by the <code>mod_sftp</code> module,
e.g.:
<pre>
 # Only support SFTP protocol version 1 through 3 for WinSCP and CuteFTP
 SFTPClientMatch WinSCP|ClientSftp sftpProtocolVersion 1-3
</pre>

<code>KEXINIT</code> Optimization 
Some SFTP clients do not like this
<a href="#SFTPTelnetBanner">KEXINIT optimization</a> that the
<code>mod_sftp</code> module uses. These clients include:
<ul>
 <li><code>Net::SSH::Perl</code>, <code>Net::SFTP</code> Perl modules
 <li><a href="http://www.enterprisedt.com/products/edtftpj/">edtFTPj</a>
</ul>
For these clients, use this configuration to disable the optimization:
<pre>
 # Disable the KEXINIT optimization at the cost of latency
 SFTPOptions PessimisticKexinit
</pre>

Cipher Implementations 
Some SFTP clients (most notably the SecureBlackBox libraries) do not implement
the <code>blowfish-ctr</code> cipher correctly. If your site needs to
support such clients, then you will need to use the
<a href="#SFTPCiphers"><code>SFTPCiphers</code></a> directive to configure
a list of ciphers which does not include <code>blowfish-ctr</code>.
Clients with this bug will show up in the <code>SFTPLog</code> with this
log message:
<pre>
 client sent buggy/malicious packet payload length, ignoring
</pre>
However, this log message can also be caused by other factors. It
is the combination of this error message, and the negotiation of
the <code>blowfish-ctr</code> cipher, that indicates the use of these
buggy clients.

<a name="ClientMatches"></a>
Recommended <code>SFTPClientMatch</code> Settings 
Based on the above client issues, the following is the recommended list of
configurations -- contributed by the <a href="https://forums.proftpd.org/smf/index.php/topic,4616.0/all.html">ProFTPD community</a> -- to use as workarounds
for all of the clients' known issues:
<pre>
&lt;IfModule mod_sftp.c&gt;
 &lt;Global&gt;
 # The default values used by mod_sftp are:
 # channelPacketSize 32KB
 # channelWindowSize 4GB
 # sftpProtocolVersion 1-6

# Axway (SSH-2.0-XFB.Gateway Unix)
    SFTPClientMatch .*Axway channelWindowSize 1GB
    SFTPClientMatch ".*XFB.*" channelWindowSize 1GB

# CoreFTP LE (free version 2.2)
    SFTPClientMatch CoreFTP channelWindowSize 1GB

# CuteFTPPro8
    SFTPClientMatch ".*ClientSftp" sftpProtocolVersion 3

# Network Automation (SSH-2.0-EldoS.SSHBlackbox.3)
    # http://www.networkautomation.com/
    SFTPClientMatch ".*EldoS.SSHBlackbox.3.*" channelWindowSize 1GB sftpProtocolVersion 3

# GlobalScape FTP application (SSH2 client 'GSSFTP1.0') - (needs v2)
    # http://www.globalscape.com/downloads/
    # GoAnywhere (SSH-2.0-1.0)
    # http://www.goanywheremft.com/products
    SFTPClientMatch "1.0" channelWindowSize 1GB sftpProtocolVersion 2

# JaSFtp (SSH-2.0-J2SSH_Maverick_1.2.10_Sterling Commerce)
    # http://www.hiteksoftware.com/jasf/
    SFTPClientMatch ".*J2SSH_Maverick.*" channelWindowSize 1GB

# JSch - Java Secure Channel (SSH-2.0-JSCH-0.1.39)
    # http://www.jcraft.com/jsch/
    SFTPClientMatch "JSCH.*" channelWindowSize 1GB

# Robo-FTP (SSH-2.0-WeOnlyDo)
    # http://www.robo-ftp.com/
    SFTPClientMatch ".*WeOnlyDo.*" channelWindowSize 1GB sftpProtocolVersion 3

# SecureBlackbox (SSH-2.0-SecureBlackbox.7)
    # http://www.eldos.com/sbb/download-release.php
    SFTPClientMatch ".*SecureBlackbox.*" sftpProtocolVersion 3

# SecureFX - SSH2 client 'SecureFX_2_2_5_225 SecureFX'
    # http://www.vandyke.com/products/securefx/
    SFTPClientMatch "SecureFX.*" sftpProtocolVersion 3

# SSH-2.0-1.30
    SFTPClientMatch "1.30" channelPacketSize 16KB channelWindowSize 256MB

# SSH-2.0-Sun_SSH_1.0.1
    SFTPClientMatch ".*Sun_SSH.*" channelWindowSize 1GB

# SSH-2.0-SharpSSH-1.1.1.13-JSCH-0.1.28
    SFTPClientMatch ".*SharpSSH.*" channelWindowSize 256MB

# WinSCP
    SFTPClientMatch ".*WinSCP.*" sftpProtocolVersion 3

# WS_FTP
    SFTPClientMatch ".*WS_FTP.*" channelWindowSize 1GB

# /n Software BizTalk SFTP Receive (SSH-2.0-IP*Works! SSH Client v8.0)
 # http://www.nsoftware.com/products/biztalk/adapters/sftp.aspx
 SFTPClientMatch ".*IP.Works.*" channelWindowSize 1GB
 &lt;/Global&gt;
&lt;/IfModule&gt;
</pre>

FIPS Compliance 
FIPS stands for "Federal Information Processing Standard", and refers to
a series of information processing standards issued and used by the US
government. When speaking of FIPS and cryptographic software, the pertinent
standard in particular is
<a href="http://en.wikipedia.org/wiki/FIPS_140">FIPS-140</a>.

How then would you build OpenSSL and <code>mod_sftp</code>, and use them
such that <code>mod_sftp</code> would be FIPS-compliant? Using OpenSSL in
FIPS mode requires quite a few steps. First, you would configure
<code>proftpd</code> to use the <code>mod_sftp</code> module as normal,
assuming your OpenSSL installation has been compiled with FIPS support:
<pre>
 ./configure --enable-openssl --with-modules=mod_sftp ...
</pre>

Compiling <code>proftpd</code> requires the following, for FIPS support
to work properly:
<pre>
 make CC=/path/to/openssl/bin/fipsld FIPSLD_CC=gcc
</pre>
The <code>FIPSLD_CC</code> variable should point to your normal C compiler,
e.g. <code>gcc</code>. The use of this <code>fipsld</code> program
is mandatory. The FIPS standard requires that the linking process
happen a very specific way, involving verification of calculated and expected
checksums of compiled code, etc. The OpenSSL packages with FIPS
support supply this <code>fipsld</code> program which will link the compiled
code according to the FIPS specifications. If you do not use
<code>fipsld</code>, then attempts to use OpenSSL in FIPS mode will fail.
For example, you would see the following if starting a <code>proftpd</code>
daemon which has not been linked using <code>fipsld</code> while requesting
use of FIPS:
<pre>
 - mod_sftp/0.0: unable to use FIPS mode: (unknown)
 - Fatal: unable to load module 'mod_sftp.c': Operation not permitted
</pre>

Now, assuming you have compiled and installed your <code>proftpd</code>
properly, e.g.:
<pre>
 make CC=/path/to/openssl/bin/fipsld FIPSLD_CC=gcc
 make CC=/path/to/openssl/bin/fipsld FIPSLD_CC=gcc install
</pre>
you will now be ready to start <code>proftpd</code>.

In order for FIPS mode to be effective, OpenSSL must be told to run in FIPS
mode from the very beginning. The <code>mod_sftp</code> module initializes the
OpenSSL library when the <code>mod_sftp</code> module is loaded, before the
<code>proftpd.conf</code> file is parsed. Thus the requesting of FIPS mode
cannot be done via a setting in <code>proftpd.conf</code>. (Annoying,
I know.)

Instead, you must use the -D command-line parameter when starting
<code>proftpd</code> (see the docs for the <code>&lt;IfDefine&gt;</code> and
<code>Define</code> directives) to define a specific variable, which the
<code>mod_sftp</code> module will look for. Specifically, you will need to
start <code>proftpd</code> like thus:
<pre>
 /path/to/proftpd -DSFTP_USE_FIPS ...
</pre>
This will define the <code>SFTP_USE_FIPS</code> variable; this tells
<code>mod_sftp</code> to initialize OpenSSL using FIPS mode. When this works,
you will see the following when <code>proftpd</code> starts up:
<pre>
 - mod_sftp/0.0: FIPS mode enabled
</pre>

When <code>mod_sftp</code> detects that OpenSSL has been configured for FIPS
mode, it will refuse to advertise support for the following cipher algorithms:
<ul>
 <li><code>arcfour128</code>
 <li><code>arcfour256</code>
 <li><code>blowfish-cbc</code>
 <li><code>blowfish-ctr</code>
 <li><code>cast128-cbc</code>
</ul>
and for the following digest algorithms:
<ul>
 <li><code>hmac-md5</code>
 <li><code>hmac-md5-96</code>
 <li><code>hmac-ripemd160</code>
</ul>
as these algorithms are not compliant with the FIPS specification.

For additional reading on OpenSSL and FIPS, see:
<pre>
 <a href="http://www.openssl.org/docs/fips/SecurityPolicy-1.1.1.pdf">http://www.openssl.org/docs/fips/SecurityPolicy-1.1.1.pdf</a>
 <a href="http://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf">http://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf</a>
</pre>

Example Configuration 
When using <code>mod_sftp</code> to handle SFTP connections, you will want
to create a separate <code>&lt;VirtualHost&gt;</code> section for the
<code>mod_sftp</code> configuration. SSH2 (and thus SFTP) requires a different
port than FTP; in order to listen on different ports, <code>proftpd</code>
requires different <code>&lt;VirtualHost&gt;</code> sections. You can have
multiple <code>&lt;VirtualHost&gt;</code> sections for the same address
(IP address or DNS name), just different <code>Port</code> directives.
<pre>
 &lt;IfModule mod_sftp.c&gt;
 &lt;VirtualHost a.b.c.d&gt;
 SFTPEngine on
 SFTPLog /etc/proftpd/sftp/sftp.log

# Configure the server to listen on the normal SSH2 port, port 22
      Port 22

# Configure the RSA, DSA, and ECDSA host keys, using the same host key
      # files that OpenSSH uses. 
      SFTPHostKey /etc/ssh_host_rsa_key
      SFTPHostKey /etc/ssh_host_dsa_key
      SFTPHostKey /etc/ssh_host_ecdsa_key

# Configure the file used for comparing authorized public keys of users.
      SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys

# Enable compression
      SFTPCompression delayed

# Allow the same number of authentication attempts as OpenSSH.
      #
      # It is recommended that you explicitly configure MaxLoginAttempts
      # for your SSH2/SFTP instance to be higher than the normal
      # MaxLoginAttempts value for FTP, as there are more ways to authenticate
      # using SSH2.
      MaxLoginAttempts 6

&lt;/VirtualHost&gt;
 &lt;/IfModule&gt;
</pre>

Logging 
The <code>mod_sftp</code> module supports different forms of logging. The
main module logging is done via the <code>SFTPLog</code> directive. For
debugging purposes, the module also uses <a href="../howto/Tracing.html">trace logging</a>, via the module-specific log channels:
<ul>
 <li>ssh2
 <li>sftp
 <li>scp
</ul>
Thus for trace logging, to aid in debugging, you would use the following in
your <code>proftpd.conf</code>:
<pre>
 TraceLog /path/to/sftp-trace.log
 Trace scp:20 sftp:20 ssh2:20
</pre>
This trace logging can generate large files; it is intended for debugging
use only, and should be removed from any production configuration.

Suggested Future Features 
The following lists the features I hope to add to <code>mod_sftp</code>,
according to need, demand, inclination, and time:
<ul>
 <li>Look up authorized public keys from LDAP directories
 <li>Honor the <code>MaxTransferPerHost</code>,
 <code>MaxTransfersPerUser</code>, <code>MaxRetrieveFileSize</code>
 directives
</ul>

<a name="FAQ">
Frequently Asked Questions

<a name="SFTPTelnetBanner">
Question: When I telnet to port 22 of other SSH2 servers,
I see the SSH2 version banner displayed, e.g.:
<pre>
 # telnet example.com 22
 Trying 1.2.3.4...
 Connected to example.com.
 Escape character is '^]'.
 SSH-1.99-OpenSSH_5.1
</pre>
However, when I telnet to the port on which <code>mod_sftp</code> is listening,
I see the version banner plus some data which can't be rendered in the terminal.
What is that extra data? 
Answer: The short answer is that <code>mod_sftp</code>
is pre-emptively sending the first key exchange data; it is this data which is
not displayed well.

This pre-emptive sending of the first key exchange message is an optimization.
The SSH2 protocol (and many SSH2 servers) start off doing:
<pre>
 (1) client ------------ connect -------------&gt; server
 (2) client &lt;-------- version banner ---------- server
 (3) client --- client's first key exchange --&gt; server
 (4) client &lt;-- server's first key exchange --- server
</pre>
So you can see that there's some back and forth. The "first key exchange"
messages sent by the client are always the same for that client, likewise the
server always sends the same "first key exchange" message (based on its
configuration). So the above has several TCP packets and ACKs that need to be
sent back and forth.

The <code>mod_sftp</code> module avoids one unnecessary TCP packet+ACK by
sending its version banner and its first key exchange message in the same TCP
packet:
<pre>
 (1) client ------------ connect -------------&gt; server
 (2) client &lt;-- version banner/1st key exch---- server
 (3) client --- client's first key exchange --&gt; server
</pre>
This helps cut down on the latency during startup, since <code>mod_sftp</code>
saves on one TCP round-trip time.

This optimization was added after reading this informative paper on SSH and
SSL/TLS by Peter Gutmann:
<pre>
 <a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf">Performance Characteristics of Application-level Security Protocols</a>
</pre>

<a name="SFTPBadWindowSize">
Question: My SSH2/SFTP client dies when trying to
connect to <code>mod_sftp</code>. The login succeeds, but then the client
is disconnected. The client logs show something like:
<pre>
 ServerMaxPacket(32768) ServerWindow(-1) (from WS_FTP)
</pre>
or
<pre>
 debug1: channel 0: open confirm rwindow -1 rmax 32768 (from OpenSSH_3.0.2p1)
</pre>
Answer: The issue, in short, involves that "-1" value
you see, and the particular client implementation in question. (The example
error above is from an old OpenSSH client.)

The SSH2 protocol specifications say that implementations must encode
the SSH2 channel "window size" as a 32-bit unsigned number. This means that
the maximum window size is effectively 4294967295 (i.e. 2 ^ 32 - 1).
This maximum window size is what <code>mod_sftp</code> uses by default.
However, some client implementations use a signed data type for
holding this value. This means that the value that <code>mod_sftp</code>
sends to the client becomes a negative signed number to the client (the
large value "wraps around" to the negative value), and the client chokes.

As another example, the <a href="http://www.ipswitch.com/WS_FTP">WS_FTP Pro</a>
client has this same problem; in the client, you will see something like
the following error:
<pre>
 Started subsystem "sftp" on channel 0760a2ce
 error 84350000 initializing sftp protocol
 Sending channel close message for channel 0760a2ce
 SSH Transport closed.
</pre>

There are two approaches for handling such cases. You can use the
<a href="#SFTPClientMatch"><code>SFTPClientMatch</code></a> directive to
set a smaller channel window size for that particular client, e.g.:
<pre>
 SFTPClientMatch ".*WS_FTP.*" channelWindowSize 256MB
 SFTPClientMatch ".*Axway" channelWindowSize 256MB
</pre>
or you can use <code>SFTPClientMatch</code> to set a general channel window
size for all clients:
<pre>
 SFTPClientMatch .* channelWindowSize 256MB
</pre>

The larger the channel window size, the better. (Note that the SSH2 channel
window size has absolutely no relation to the TCP window size.)
The smaller this SSH2 channel window size, the more frequently the peer needs
to send a "window size adjustment" SSH2 request (which entails its own TCP
packet and ACK) in order to keep the window size open. The larger the channel
window size, the fewer "window size adjustment" requests the peer has to send,
and thus the fewer TCP packets/ACKs are needed. Since each TCP packet adds
latency, the smaller channel window sizes can increase the latency for data
transfers.

For this reason, my personal recommendation is to only set smaller channel
window sizes for those SSH2/SFTP clients which need it; no need to incur
the additional latency if the client supports the larger window sizes.

<a name="SFTPSubsystem">
Question: Can I configure <code>mod_sftp</code> to be
an OpenSSH subsystem, e.g. by using the following in my
<code>sshd_config</code> file:
<pre>
 Subsystem sftp /usr/local/sbin/proftpd
</pre>
Answer: No. The <code>mod_sftp</code> module cannot
be used as an OpenSSH subsystem because proftpd needs more information about
the session than is provided to OpenSSH subsystems. ProFTPD needs to know all
of the information about the authenticated user, the SSH2 channel IDs being
used for the SFTP/SCP sessions, etc.

<a name="SFTPAndFTP">
Question: How can I configure <code>proftpd</code>
so that it can handle both FTP and SFTP at the same time? 
Answer: The key to doing this is to create a
<code>&lt;VirtualHost&gt;</code> section just for the <code>mod_sftp</code>
configuration, listening on the address and port that you wish, e.g.:
<pre>
 # The FTP configuration
 DefaultAddress a.b.c.d
 Port 21

&lt;IfModule mod_sftp.c&gt;
 &lt;VirtualHost a.b.c.d&gt;
 # The SFTP configuration
 Port 22

SFTPEngine on
 ...
 &lt;/VirtualHost&gt;
 &lt;/IfModule&gt;
</pre>
Note that if you use the above configuration, and you wish to handle
any address requested by incoming connections, use
<code>0.0.0.0</code> as the a.b.c.d IP address. <code>0.0.0.0</code>
is known as the "wildcard address", and indicates that ProFTPD wants to listen
on any/all addresses, on those ports.

<a name="SFTPOnly">
Question: How can I configure <code>proftpd</code>
so that it only accepts SFTP connections (via <code>mod_sftp</code>), and no
FTP connections? 
Answer: Use the following in your
<code>proftpd.conf</code>:
<pre>
 &lt;Limit LOGIN&gt;
 DenyAll
 &lt;/Limit&gt;

&lt;VirtualHost a.b.c.d&gt;
 &lt;Limit LOGIN&gt;
 AllowAll
 &lt;/Limit&gt;

SFTPEngine on
 ...
 &lt;/VirtualHost&gt;
</pre>
The idea is to use the <code>&lt;Limit LOGIN&gt;</code> to deny all logins to
any/all virtual host sections except for the <code>mod_sftp</code>
section.

<a name="SFTPAuthorizedKeyTooLong">
Question: I followed the instructions to convert
my authorized keys from OpenSSH to RFC4716 format, yet I see the following
error in my <code>SFTPLog</code>:
<pre>
 mod_sftp/0.9.7[31050]: line too long (74) on line 1 of 'authorized_keys'
</pre>
What can I do to fix this? 
Answer: OpenSSH's <code>ssh-keygen</code> tool had a
bug where the RFC4716 keys it would generate might not comply to the RFC; see
the <a href="https://bugzilla.mindrot.org/show_bug.cgi?id=1630">OpenSSH bug</a>
filed for this issue.

Chances are that the offending line in the RFC4716 key is a "Comment: " header
that is too long. Simply delete that "Comment: " line; the
<code>mod_sftp</code> ignores this header.

<a name="SFTPAuthorizedKeyFormat">
Question: I generated an SSH key using
<code>ssh-keygen</code>, then added it to my <code>authorized_keys</code> file
using:
<pre>
 $ cat id_rsa.pub >> authorized_keys
</pre>
But logging into <code>mod_sftp</code> still prompts me for my password.
Why? 
Answer: The most likely culprit is that the format
of your <code>authorized_keys</code> file is not what <code>mod_sftp</code>
expects.

Per the <a href="#SFTPAuthorizedUserKeys"><code>SFTPAuthorizedUserKeys</code></a> documentation, <code>mod_sftp</code> expects that the keys be in RFC 4716
format. If your <code>authorized_keys</code> file contains data that looks
like this:
<pre>
 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDN1tCK5uHUGl....
</pre>
rather than looking like this:
<pre>
 ---- BEGIN SSH2 PUBLIC KEY ----
 AAAAB3NzaC1yc2EAAAADAQABAAABAQDN1tCK5uHUGlpxye+KEmB0EIr9zqvMmgyNdWvJBW
 ...
 PZ1+hOi5QECWQYD0BpiWvj
 ---- END SSH2 PUBLIC KEY ----
</pre>
Then the format of some of the keys in your <code>authorized_keys</code> file
is wrong. Make sure that you convert your OpenSSH-generated keys to RFC 4716
format using <code>ssh-keygen</code>, before adding it to your
<code>authorized_keys</code> file, using something like this:
<pre>
 $ ssh-keygen -e -f ~/.ssh/id_rsa.pub >> authorized_keys
</pre>
See the <a href="#UsageRFC4716Format">Usage</a> documentation for more
information.

<a name="SFTPBrokenMaxFileSize">
Question: I'm using the <a href="../modules/mod_xfer.html"><code>MaxStoreFileSize</code></a> directive in my <code>mod_sftp</code>
configuration, but when I upload a file using e.g. OpenSSH's
<code>sftp</code> client, I see the file uploaded past my configured limit. Is
this a bug? 
Answer: No. The <code>mod_sftp</code> module honors
a configured <code>MaxStoreFileSize</code> limit properly. However,
what you see in the SFTP client may not reflect this as you would expect.
Some SFTP clients, like that from OpenSSH, will only reflect the failure
after the entire file has been uploaded:
<pre>
 sftp&gt; put /path/to/file.dat
 Uploading /path/to/file.dat to /file.dat
 /path/to/file.dat 100% 704KB 704.1KB/s 00:00
 Couldn't write to remote file "/file.dat": Failure
</pre>
In the <code>SFTPLog</code> for the above situation, you would most likely
see log messages about the SFTP <code>WRITE</code> requests being rejected:
<pre>
 mod_sftp/0.9.9[32297]: error writing 32768 bytes to '/file.dat': File too large (MaxStoreFileSize 204800 exceeded)
 mod_sftp/0.9.9[32297]: error writing 32768 bytes to '/file.dat': File too large (MaxStoreFileSize 204800 exceeded)
</pre>

There is a discrepancy between what the client shows the user, and what the
server is actually doing. The <code>mod_sftp</code> module, when handling
SFTP uploads, checks the size of the file on disk, after receiving the buffer
of data from the network, but before writing that data to disk. If the
size of the file on disk exceeds the <code>MaxStoreFileSize</code> limit, then
that SFTP <code>WRITE</code> request is denied.

Many SFTP clients will send multiple SFTP <code>WRITE</code> requests
concurrently, optimistically hoping that they will succeed; this makes for
faster SFTP uploads. This is why you might see multiple "File too large"
messages logged by <code>mod_sftp</code>. And it also means that the client
thinks it has sent more data to the server than has actually been
written to disk.

Now, this may lead you to ask "Due to SFTP protocol itself, there is no way to
control the file size uploaded by a client, right?" This is not quite correct.

There's no way for an SFTP server to control how much data the
SFTP client will send. But there is a way to control how much data is
written to disk by the SFTP server; that is what <code>MaxStoreFileSize</code>
does. But this means that the SFTP client may report how much data it sent
over the network, which is not the same as how much data was actually
stored by the SFTP server. Believing what your client shows you, though, is
always suspect, since what the client shows may not actually reflect the
reality of things on the server side of things.

<a name="SFTPPCBCModeAttacks">
Question: Is it true that using CBC mode ciphers in
SSH is insecure? 
Answer: It is true that there are a couple of published
theoretical attacks against the SSH protocol when CBC ciphers are
used, including Rogaway, Wai, and Bellare (see RFC 4251, Section 9.3.1) and
<a href="http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt">"Plaintext Recovery Attacks Against SSH"</a> (CPNI-957037).

However, these attacks can be mitigated by countermeasures in the SSH
implementation. The use of <code>SSH_MSG_IGNORE</code> messages for the
Rogaway attack, and the delayed checking of packet length fields until the MAC
check has passed (and then reading in a random amount of additional data from
the network) to migitate CPNI-957037, are both implemented within the
<code>mod_sftp</code> module as security measures.

<a name="SFTPListOptions">
Question: I am trying to use <code>ListOptions</code>
to change what is displayed for files in my SFTP clients, but it is not working.
Why? 
Answer: Unlike FTP, in SFTP it is the client,
not the server, which determines what to display to the end user.
Thus the <code>ListOptions</code> directive is not honored by
<code>mod_sftp</code>.

<a name="SFTPUploadChmod">
Question: If I use a configuration like this:
<pre>
 &lt;Directory /path/to/upload&gt;
 &lt;Limit WRITE&gt;
 AllowAll
 &lt;/Limit&gt;

&lt;Limit SITE_CHMOD&gt;
 DenyAll
 &lt;/Limit&gt;
 &lt;/Directory&gt;
</pre>
then why do my SFTP uploads fail, when the same configuration allows uploads to succeed using FTP? 
Answer: When a file is uploaded using FTP, the only
parts of the file uploaded are its contents but not the file
metadata (e.g. not the file timestamps or permissions). Separate
FTP commands are used to send the file metadata to the server.

However, the SFTP protocol sends the file metadata as part of the normal upload. In the configuration above, the limit on <code>SITE CHMOD</code>
is being applied to the SFTP upload. If you do not want this, and want
your SFTP uploads to be more like your FTP uploads, then you should use:
<pre>
 SFTPOptions IgnoreSFTPUploadPerms
</pre>
in your <code>mod_sftp</code> configuration.

<a name="SFTPOwner">
Question: I use <code>UserOwner</code> and
<code>GroupOwner</code> in my <code>mod_sftp</code> configuration, but they
are not being applied properly. Is this a bug? 
Answer: No.

By default, the <code>mod_sftp</code> module drops root privileges as soon
as it can, which is just after the user has been authenticated. Without
root privileges, <code>mod_sftp</code> cannot change the ownership of files
uploaded via SFTP/SCP as per <code>UserOwner</code>/<code>GroupOwner</code>
settings.

In ProFTPD 1.3.4rc1, honoring of the <code>UserOwner</code> and
<code>GroupOwner</code> directives was added to the <code>mod_sftp</code>
module. However, you will also need to add the following to your
<code>mod_sftp</code> configuration to make them work properly:
<pre>
 RootRevoke off
</pre>
This explicitly tells the <code>mod_sftp</code> to not drop root
privileges after authentication, and instead to keep them for the duration
of the session.

In addition, if you are on a Linux machine, you may also
need to disable the <a href="../modules/mod_cap.html"><code>mod_cap</code></a>
module, as that can also restrict what can be done with root privileges:
<pre>
 &lt;IfModule mod_cap.c&gt;
 CapabilitiesEngine off
 &lt;/IfModule&gt;
</pre>

<a name="SFTPShell">
Question: Why can't I use <code>ssh</code> to connect
to my proftpd+mod_sftp server? When I try, I see:
<pre>
 # ssh user@host
 Enter passphrase for key '/home/user/.ssh/id_rsa': 
 PTY allocation request failed on channel 0
 shell request failed on channel 0
</pre>
Answer: The <code>mod_sftp</code> module supports
file transfers via SFTP and SCP. It does not support shell access,
which is what the <code>ssh</code> command-line client tries to use. The
above error messages from <code>ssh</code> show that <code>mod_sftp</code>
refused the shell access requests.

<a name="SFTPDirFakeUserGroup">
Question: I am using <code>DirFakeUser</code> and
<code>DirFakeGroup</code> in my <code>mod_sftp</code> configuration, but
they do not work when I run the <code>ls -lh</code> command in the
<code>sftp</code> command-line client. Is this a bug? 
Answer: This is unfortunately an issue with OpenSSH's
<code>sftp</code> command-line client.

The <code>mod_sftp</code> module always sends the same information for an
SFTP directory listing, assuming SFTP protocol version 3 or lower (which is
what OpenSSH uses); see <a href="https://github.com/proftpd/proftpd/blob/master/contrib/mod_sftp/fxp.c#L2801">here</a>. The <code>DirFakeUser</code> and
<code>DirFakeGroup</code> directives will affect the user/group names in that
"longname" string, which is defined for the <code>SSH_FXP_NAME</code> packet
described in <a href="https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-7">draft-ietf-secsh-filexfer-02</a>.

In looking at the OpenSSH 7.9p1 implementation, we can see the issue in its
code. When <code>ls -l</code> is used, the <code>sftp</code> command-line
client will display the "longname" sent by mod_sftp as-is. But when
<code>ls -lh</code> is used, that <code>-h</code> flag causes <code>sftp</code>
to ignore the "longname", and try to use only the UID/GID numeric
values (which are not affected by the
<code>DirFakeUser/DirFakeGroup</code> directives).

<a name="SFTPTectiaHostKey">
Question: When I try to start proftpd with
<code>mod_sftp</code> configured to use my existing host key, it fails with
one of the following error messages:
<pre>
 error reading passphrase for SFTPHostKey 'hostkey': Invalid argument
 error reading passphrase for SFTPHostKey 'hostkey': (unknown)
</pre>
The permissions on my hostkey are fine, and it is not passphrase-protected.
Is this a bug? 
Answer: You are probably trying to use a host key
generated by Tectia's SSH software (or an older <code>ssh.com</code> host key).

The <code>mod_sftp</code> module expects the configured
<code>SFTPHostKey</code> file to be in the same format as used by OpenSSH.
To check the format, run this command:
<pre>
 # grep BEGIN hostkey
</pre>
If you see either of the following lines:
<pre>
 -----BEGIN RSA PRIVATE KEY-----
 -----BEGIN DSA PRIVATE KEY-----
</pre>
then the format should be correct. If instead you see:
<pre>
 ---- BEGIN SSH2 ENCRYPTED PRIVATE KEY ----
</pre>
then the format is incorrect. The above line indicates that your host key
was generated by Tectia (nee <code>ssh.com</code>), and needs to
be converted to a different format.

To convert the format of your Tectia host key, use OpenSSH's
<code>ssh-keygen</code> (not Tectia's <code>ssh-keygen</code>) and
do the following:
<pre>
 # ssh-keygen -i -f hostkey &gt; /path/to/new-file
</pre>
The configure your <code>SFTPHostKey</code> directive with the path to the
new file.

<a name="SFTPOpenSSLVersionMismatch">
Question: When I start <code>proftpd</code>, I
see warnings that look like this:
<pre>
 - mod_sftp/0.9.7: compiled using OpenSSL version 'OpenSSL 0.9.8n 24 Mar 2010' headers, but linked to OpenSSL version 'OpenSSL 0.9.8q 2 Dec 2010' library
</pre>
What does this mean? 
Answer: That is an informational/warning message.

Some systems are badly maintained by their admins (and/or by the packages
installed on the systems), such that the OpenSSL headers can become quite badly
out of sync with the OpenSSL libraries. If this discrepancy becomes bad
enough, you can see strange behavior from OpenSSL, ranging from random behavior
to segfaults. So <code>mod_sftp</code> tries to let the admin know about the
system's mismatched OpenSSL header/library versions.

Usually a minor OpenSSL version difference like the example above is OK,
but it really depends on exactly what changed in OpenSSL, and how.

If you see the above message, it is not a requirement that you recompile
<code>proftpd</code> against the OpenSSL headers of the same version as the
OpenSSL libraries. However, the version discrepancy is a possible
source of trouble.

<a name="SFTPVersionId">
Question: When a client first connects to
<code>mod_sftp</code> and starts the SSH handshake, the client sees that
<code>mod_sftp</code> provides an SSH version identifier like "SSH-2.0-mod_sftp/0.9.8". Is there any way I can tell <code>mod_sftp</code> to hide/change
that version? 
Answer: Yes. As of <code>proftpd-1.3.5rc1</code>,
the <code>mod_sftp</code> module will honor the <a href="../modules/mod_core.html#ServerIdent"><code>ServerIdent</code></a> directive.

For example, to see just "SSH-2.0-mod_sftp", without any <code>mod_sftp</code>
version suffix, use the following within your <code>mod_sftp</code> <code>&lt;VirtualHost&gt;</code>:
<pre>
 # Tell mod_sftp to not reveal its module version in the SSH version
 # identification
 ServerIdent off
</pre>
You can also use <code>ServerIdent</code> to make <code>mod_sftp</code> say
it is something else completely, like this:
<pre>
 # Tell mod_sftp to advertise itself as an OpenSSH server
 ServerIdent on "OpenSSH_5.6p1"
</pre>

<a name="SFTPTrafficPolicyNetworkPerformance">
Question: I notice that when I use some SFTP clients
(e.g. DreamWeaver) with <code>mod_sftp</code>, the network performance
is 5-6 times slower than with other SFTP clients. Using the same SFTP client
against OpenSSH doesn't show the same slowdown. Network tools such as
Wireshark show that <code>mod_sftp</code> is sending 2 TCP packets for each
SFTP request, whereas OpenSSH only sends 1 TCP packet for each SFTP request.
Why is <code>mod_sftp</code> so much slower than OpenSSH, but only for some
SFTP clients? 
Answer: Investigations into this <code>mod_sftp</code>
behavior have shown it to be caused by the
<a href="#SFTPTrafficPolicy"><code>SFTPTrafficPolicy</code></a> behavior,
particularly when the SFTP client negotiates the use of a CBC cipher.

The recommended action to take is to disable the use of CBC ciphers,
which will cause the <code>SFTPTrafficPolicy</code> mitigation to not go
into effect, which keeps the number of SSH messages lower, thus improving
network latency. Thus the change to make for your <code>mod_sftp</code>
configuration is:
<pre>
 # Remove the CBC ciphers from the ciphers we advertise
 SFTPCiphers aes256-ctr aes192-ctr aes128-ctr blowfish-ctr arcfour256 arcfour128 3des-ctr
</pre>

<a name="SFTPLocalisedTimes">
Question: When I use <code>mod_sftp</code> and get
a directory listing, I notice that the timestamps on the files are
localised (e.g. are in French). When I use OpenSSH, the timestamps
are always in English. How I get get <code>mod_sftp</code> to behave like
OpenSSH, and not localise the timestamps? 
Answer: This happens when your <code>proftpd</code>
has been built with the <code>--enable-nls</code> configure option. To
check, use <code>`proftpd -V'</code>:
<pre>
 ...
 Features:
 ...
 + NLS support
 ...
</pre>
This means that <code>proftpd</code> honors any locale-related environment
variables when it starts up. The reason you see localised timestamps
in the directory listings is probably because your environment has something
like <code>LANG=fr_FR.utf8</code>.

To tell <code>proftpd</code> to ignore that environment variable, you need
to use this at the top of your <code>proftpd.conf</code>:
<pre>
 Unsetenv LANG
</pre>

<a name="SFTPVersion6">
Question: My SFTP client wants to use SFTP protocol
version 6, but <code>mod_sftp</code> only accepts protocol version 3. These
docs say that protocol versions 1-6 are supported. Is this a bug? 
Answer: The most likely cause of this behavior is that
your <code>proftpd</code> installation was not compiled with the
<code>--enable-nls</code> configure option. The <code>--enable-nls</code>
configure option is required to enable NLS support, which includes support
for UTF8. SFTP protocol versions 4-6 require UTF8 support, which is why
the <code>--enable-nls</code> configure option is needed.

<a name="SFTPExtraREADs">
Question: Why is my <code>SFTPLog</code> often spammed
with lots of messages that look like:
<pre>
 requested read offset (20480 bytes) greater than size of '/some/path/to.file' (20307 bytes)
</pre>
Is there something wrong with my SFTP client, or my configuration? 
Answer: The short answer is that these extraneous
<code>READ</code> requests are normal, and do not indicate any
problem or issue.

Many SFTP clients try to improve their download speed by issuing many
concurrent <code>READ</code> requests, each request with a different
offset. Thus the client can read multiple "chunks" simultaneously,
and do the reassembly of the "chunks" into the file itself. However, sometimes
these SFTP clients do not necessarily know how many such
<code>READ</code> requests are needed before the end-of-file is reached. So
the SFTP client sends more <code>READ</code>s that might be necessary; the
server will reply with an error if the requested offset is beyond the
end of the file. When this "end of file" reply is received by the SFTP client,
it will know that it is done downloading. On the server side, though, this
behavior results in the above log messages.

<a name="SFTPNotUnderstood">
Question: When I use my SFTP client, I see something
like this when I try to connect to <code>proftpd</code> with
<code>mod_sftp</code>:
<pre>
 500 SSH-2.0-OPENSSH 6.2 not understood
</pre>
Why would this happen? 
Answer: A "500 ... not understood" is an
FTP response, not an SFTP response. This usually happens
when your SFTP client connects to an FTP virtual host/port (versus an SFTP
virtual host/port). So either a) the SFTP client is connecting to
the wrong port on your server, or b) perhaps "SFTPEngine on" is not
set in the virtual host for that port.

<a name="SFTPPTYAllocationFailed">
Question: I try to connect to <code>proftpd</code>
with <code>mod_sftp</code> and the connection fails with an error messages
like "PTY allocation request failed on channel 0" or "Server refused to
allocate pty". What is going wrong? 
Answer: This error message happens when you
try to connect to <code>mod_sftp</code> using an SSH client which wants
a shell session, rather than an SFTP session or an SCP transfer.
The <code>mod_sftp</code> module does not support shell sessions
(unlike OpenSSH). In the <code>SFTPLog</code>, you would see such
connection attempts logged like so:
<pre>
 mod_sftp/0.9.9[6304]: unsupported 'pty-req' channel requested, ignoring
 mod_sftp/0.9.9[6304]: unsupported 'shell' channel requested, ignoring
</pre>

<a name="SFTPDirectorySGID">
Question: When I create a directory via SFTP, in
a directory with the SGID bit set, the created directory does not
have the SGID bit set as expected. How do I fix this? 
Answer: Preserving the SGID bit for a created directory
usually require root privs; the <code>mod_sftp</code> module automatically
drops all root privs. So to get the directory SGID bit functionality,
you will need to use the following in your <code>mod_sftp</code>
<code>&lt;VirtualHost&gt;</code> section:
<pre>
 RootRevoke off
</pre>
In addition, if your <code>proftpd</code> is running on Linux, you may
need to disable the <a href="../modules/mod_cap.html"><code>mod_cap</code></a>
module, or configure it to preserve the SGID bit (e.g. via the
<a href="../modules/mod_cap.html#CapabilitiesSet"><code>CAP_FSETID</code></a>
capability).

<a name="SFTPEd25519">
Question: I see that Ed25519 SSH keys are supported
as of ProFTPD 1.3.7rc3 (see <a href="http://bugs.proftpd.org/show_bug.cgi?id=4221">Bug #4221</a>), but when I try to use one with <code>mod_sftp</code>, my
login fails. The <code>SFTPLog</code> shows this error; why?
<pre>
 USER user1 (Login failed): unsupported public key algorithm 'ssh-ed25519' requested
</pre>
Answer: Support for the Ed25519 algorithm requires
the <a href="https://github.com/jedisct1/libsodium">libsodium</a> library.
You may need to install this library, and recompile ProFTPD with
<code>mod_sftp</code> in order for the library to be detected and used.

<a name="SFTPWarnings">
Question: In my SFTP logs, I see these warnings:
<pre>
 WARNING: unable to read SFTPDHParamFile 'path': Permission denied
 unable to open SFTPKeyBlacklist 'path': Permission denied
</pre>
What can I do to fix this? 
Answer: This indicates that the files are not
readable (usually world-readable) by the users logging in,
or that the directories containing the files are not readable
by the users.

Fortunately <code>mod_sftp</code> will function without issue if it
cannot read either the <code>SFTPDHParamFile</code> or the
<code>SFTPKeyBlacklist</code> files.

<a name="SFTPSHA2">
Question: I see that many sites are phasing out their
use of the SHA-1 algorithm as it is felt to be unsafe. How can I
configure <code>mod_sftp</code> to no longer use SHA-1? 
Answer: The main uses of SHA-1 in <code>mod_sftp</code>
are in the algorithms for MACs (the
<a href="#SFTPDigests"><code>SFTPDigests</code></a> directive) and key exchanges
(the <a href="#SFTPKeyExchanges"><code>SFTPKeyExchanges</code></a> directive).

For <code>SFTPDigests</code>, the algorithms that use SHA-1, and thus
the ones to avoid are:
<ul>
 <li>hmac-sha1
 <li>hmac-sha1-96
 <li>hmac-md5
 <li>hmac-md5-96
</ul>
Then you would want to use something like this in your <code>mod_sftp</code>
configuration:
<pre>
 SFTPDigests \
 umac-128@openssh.com \
 umac-64@openssh.com \
 hmac-sha2-256 \
 hmac-sha2-512
</pre>
Note that some of the algorithms above may not be supported by your version
of <code>mod_sftp</code>.

Similarly, for key exchanges, the algorithms to avoid because they use SHA-1
are:
<ul>
 <li>diffie-hellman-group-exchange-sha1
 <li>diffie-hellman-group14-sha1
 <li>diffie-hellman-group1-sha1
 </li>rsa1024-sha1
</ul>
And to do this, you might use something like this in your configuration:
<pre>
 SFTPKeyExchanges \
 curve448-sha512 \
 curve25519-sha256 \
 ecdh-sha2-nistp521 \
 ecdh-sha2-nistp384 \
 ecdh-sha2-nistp256 \
 diffie-hellman-group18-sha512 \
 diffie-hellman-group16-sha512 \
 diffie-hellman-group14-sha256 \
 diffie-hellman-group-exchange-sha256 \
</pre>

<a name="SFTPOpenSSL1.1.x">
Question: I am using ProFTPD 1.3.5, and I am unable to
use <code>mod_sftp</code>. When I connect, I see these errors in my
<code>SFTPLog</code>:
<pre>
 2017-07-28 22:38:13,904 mod_sftp/0.9.9[24363]: error setting key/IV for aes256-ctr cipher for decryption:
 (1) error:0906D06C:PEM routines:PEM_read_bio:no start line
 (2) error:0607B083:digital envelope routines:EVP_CipherInit_ex:no cipher set
</pre>
Is this a bug? 
Answer: These error messages indicate that you are
using a newer version of OpenSSL, e.g. OpenSSL 1.1.x, than
ProFTPD 1.3.5 can support.

The OpenSSL APIs changed from OpenSSL 1.0.x to OpenSSL
1.1.x, requiring changes in the applications that use OpenSSL (see
<a href="http://bugs.proftpd.org/show_bug.cgi?id=4240">Bug#4240</a>). To
deal with this issue, then, you can hopefully upgrade to ProFTPD 1.3.6 or later,
or downgrade your OpenSSL version to 1.0.x.

</body>
</html>

❌ Cancel

🗂️ Enhanced PHP File Manager

📊 Server Information

🔧 Quick Actions

✏️ Editing: mod_sftp.html

📤 Upload File

📁 Create Folder

📄 Create File

✏️ Rename Item

🗑️ Delete Confirmation