trouble.txt

伯克利做的SFTP安全文件传输协议

trouble.txt
Troubleshooting info for the SafeTP server


  +-----------------------------------------------------------+
  |							      |
  | Note: This file is now quite out of date.  The up-to-date |
  | version of this information can be found at:	      |
  |							      |
  |   http://safetp.cs.berkeley.edu/trouble.html	      |
  |							      |
  +-----------------------------------------------------------+


1  "warning: The random seed file is missing.  Creating a new one
now."

Context: Running sftpd or sftpc.  Message is printed to console, or
written to syslog (sftpd only).

Cause: This is printed when the file "randomSeed" is missing (or
cannot be accessed by the logged-in user).  It is normally created
during key generation.

Solution: Run 'makekeys'.  For sftpd (server), follow instructions in
install.txt, manual install, section 1.3.  For sftpc (client), do this:

  % makekeys 1024 0


2  "Exception: Assertion failed: LoadKey for ElGamal/public.key
failed ..."

Context: Running sftpc (from command line).

Cause: The client keys have not been created, or are not accessible.

Solution: Run 'makekeys'.  See above (problem 1).


3  "510 Assertion failed: LoadKey for DSA/public.key failed, ..."

Context: This message may be returned by sftpd, in the FTP protocol
stream, such that the client will see this message.

Cause(1): The DSA keys have not been created.

Solution: Run 'makekeys' (see section 1.3).

Cause(2): The DSA subdirectory is not accessible to sftpd (usually the
safetp user).

Solution: chmod or chown the DSA subdirectory so sftpd will have read
access.

Cause(3): The '-y' switch has been used, its argument may be incorrect
(the argument should be a directory, of which "DSA" is a subdirectory,
and contains the DSA keys).

Solution: Fix the argument to '-y'.  This is in inetd.conf, on the
line where sftpd is listed.


4  "failed to write key to DSA/private.key"

Context: This message is printed to the console by makekeys.

Cause and Solution:  See 3, cause (2).


5  "510 connect: Connection refused (code 146)"

Context: Client tries to connect to server, message is returned in
protocol stream.

Cause(1): The server is misconfigured; this message results from sftpd
trying, and failing, to contact ftpd.  sftpd obtains the port on which
to contact ftpd from /etc/services, querying the name "raw-ftp",
unless it has been set with the "-f" switch.  ftpd is started by
inetd, and should be set to start in response to contact on the
"raw-ftp" port.

Solution: Fix /etc/inetd.conf or /etc/services.

Cause(2): Inetd has not received the HUP signal.

Solution: Send inetd the HUP signal.  (See kill(1) for more info.)


6  "500 You've GOT to be joking."

Context:  Reported by ftpd, and relayed by sftpd, to ftp client, in response
to a PORT protocol command.

Cause:  ftpd is configured to not allow non-reflexive PORT commands
(i.e., third-party transfers; when data encryption is off, sftpd works
by emulating a third-party transfer between ftpd and the client).
Data encryption is off, so sftpd does not intercept PORT commands,
instead letting ftpd and the client communicate directly.

Solution(1):  Enable 3rd-party transfer in ftpd.  This may require a
recompile of ftpd.

Solution(2):  Set the -3 switch for the server, in /etc/inetd.conf.
Remember to HUP inetd to get the change to take effect.  This has the
disadvantage of relaying all data traffic through sftpd (a performance
hit), even when it is not being encrypted.

Solution(3):  Turn on data encryption in the client.  This will force
sftpd to intercept all data transmissions, pacifying ftpd.