From: Kevin Taylor <firstname.lastname@example.org>
Subject: Observations and tips to increasing entropy in OpenSSH
These are some observations I made about running OpenSSH (mainly
on IRIX, but it has other applications). I thought this would be
useful for other admins.
We were experiencing some issues with OpenSSH on our larger servers,
where we would receive a message saying "Not enough entropy
in RNG". These were IRIX machines, which do not come with a
RNG device like Linux, so we were becoming concerned with users'
ability to use ssh as more and more connections were being made.
After some poking around, I noticed a file called "ssh_prng_cmds"
which is installed in the 'etc' directory of the OpenSSH
installation (wherever you put it). Inside this file, are listings
of several UNIX commands that OpenSSH will execute to gather more
entropy for its RNG.
For example (taken from first few lines of ssh_prng_cmds)
# entropy gathering commands
# Format is: "program-name args" path rate
# The "rate" represents the number of bits of usuable entropy per
# byte of command output. Be conservative.
# $Id: ssh_prng_cmds.in,v 1.6 2001/02/09 01:55:36 djm Exp $
"ls -alni /var/spool/lpd" undef 0.04
"ls -alni /var/adm" /sbin/ls 0.04
"ls -alni /var/mail" /sbin/ls 0.04
"ls -alni /var/adm/SYSLOG" undef 0.04
"ls -alni /var/mail" undef 0.04
"ls -alni /proc" /sbin/ls 0.04
The only problem is that this file is not thoroughly documented. There's
some, but not lots.
Basically, the stuff inside the quotes is the command that's
executed, and the last field of the line is the weight this command
is given to the total entropy gathered. What the difference between
'undef' and the actual command name is I'm not sure.
What we observed in looking through this file on an IRIX system
was that most of the commands were incorrect. Some had bad options
on the commands that caused the command to never execute. Some had
bad paths to commands, etc.
After fixing this up, we haven't come across those entropy
errors.... and I'd swear connections are faster, but don't
have any quantitative benchmarks to prove it. So, I would recommend
that anyone configuring OpenSSH take a look in that file (regardless
of the OS) and just make sure that these commands/paths are functional.
It could save a lot of trouble later.
I hope this information is useful.
Kevin Taylor, Systems Administrator
Science Systems and Applications, Inc., Goddard Space Flight Center
I was just reading the article titled "Redundant Internet
Connections Using Linux" by Seann Herdejurgen in January 2002's
issue. I noticed a minor error in the article, which involves an
issue I was dealing with as recently as last week.
The sentence in error is this: "Passive mode FTP avoids this
problem by transferring all data over TCP port 21." This is
simplistic and incorrect. Port 21 is the control channel, so to
speak. The actual data in a passive FTP situation goes out over
a random high port chosen by the client. The primary difference
between Active and Passive FTP is that the random high ports are
chosen by the client (in case of passive FTP) or the server (in
cases of active FTP). In neither case does data go over port 21.
My reason for submitting this correction is the vast amount of
time I struggled with ipchains and passive FTP. I have a very restrictive
ruleset here that forbids all outbound traffic except that which
is specifically allowed (HTTP, SMTP, DNS, FTP, etc). I had in place
a rule allowing bidirectional outbound traffic on port 21 and another
on port 20. Passive FTP still did not work. Passive FTP worked only
by allowing all packets. After doing so, and logging them, I saw
that the data transfers were happening on random high ports, not
As an aside, due to security implications of allowing passive
FTP through the firewall, we aren't using it anymore. (passive
FTP, that is ... not the firewall, which we still use.
For corroborating documentation, check out the O'Reilly book
"Building Internet Firewalls" (pg 226 deals specifically
with the packet filtering characteristics of FTP, active and passive).
Thanks for your time,
US Investigative Services
You are correct. FTP is a difficult protocol to get through
the firewall. During our testing with iptables prior to publication,
we were unable to get Microsoft's FTP client to work using
active mode FTP. We were able to get Hummingbird's FTP client
to work using passive mode however. I just tested it again with
Hummingbird's FTP client by going to ftp://ftp.redhat.com/
and doing a 'netstat -n' while the connection was open:
C:\Documents and Settings\seann>netstat -n
Proto Local Address Foreign Address State
TCP 10.0.0.2:3389 10.0.0.1:37866 ESTABLISHED
TCP 10.0.0.2:3978 188.8.131.52:21 ESTABLISHED
TCP 10.0.0.2:3979 184.108.40.206:21 ESTABLISHED
TCP 10.0.0.2:3985 220.127.116.11:12125 SYN_SENT
The connection on port 12125 was open for a very brief period (<1
second) while the directory listing was transferred. The following
iptables rule is what allows the return passive-mode FTP traffic:
# ACCEPT return traffic (stateful firewall)
iptables -t filter -A FORWARD -m state --state NEW,ESTABLISHED,RELATED
-i $EXT_IFACE -s ! $INT_NET -j ACCEPT
I know that this doesn't help you because you are running ipchains
instead of iptables. (Note also the we were unable to get the ip_nat_ftp
module to work correctly with the Microsoft FTP client either.)
I no longer have access to any ipchains firewalls to do any
testing for you, but if I recall correctly, you should be able to
use the ip_masq_ftp module to help you masquerade FTP connections
(i.e., modprobe ip_masq_ftp).
The paragraph on FTP was the most difficult for me to write
because it is such a pain to get working through the firewall. It
has been the source of frustration for me as well. I thought about
leaving it out of the article, but I felt that there were too many
people on the Internet using it to leave it out of the article.
I tried my best to do due diligence on the facts before we went
to publication and apologize for the misinformation.
I would highly recommend that you migrate your firewall from
ipchains to iptables. I would be happy to provide assistance to
help you get it up and running because I know for a fact that passive
mode FTP works through it.