Cover V11, I04



New Messages

From: Kevin Taylor <>

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:,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 port 21.

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,

Jerry Lynde
System Administrator
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 and doing a 'netstat -n' while the connection was open:

C:\Documents and Settings\seann>netstat -n 

Active Connections 

Proto  Local Address          Foreign Address        State
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 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.