Apr 251999

ssh – much more secure than telnet

[Ed. After this article was written, OpenSSH was released.  You should read Installing OpenSSH – less restrictive than ssh instead of this article.]

This article describes how I installed ssh, the Secure SHell.

ssh is free for personal or non-commercial use.  Otherwise, you might have to use ssh2.

Why use ssh?

A telnet session uses clear text in all transmissions.  That means that anyone snooping on the packets as they go between you and the machine can see what you are typing.  That is unlikely and improbable, but it is possible.  But it is important to note that everything you type, including passwords is readable.

On the other hand, ssh encrypts this information and makes the information unreadable.   I won’t say it’s impossible to crack because someone will prove me wrong.  But given current technology, the stuff is secure enough for everyday use.  And if you combine ssh with other common security procedures, such as changing your passwords regularly, things should be a great deal better than just with plain old telnet.

Other ssh resources

The ssh home page:


The ssh FAQ is at


In that FAQ is Where do I get help?


An introduction to ssh is at:


This introduction was published in SunWorld magazine is at:


There is another SunWorld article on ssh configuration at


Installing ssh

I used the port.  And with ports, it’s very easy to install stuff.  It’s mindless-no-thinking stuff.  Someone else has already done all the hard work for you.   For full port installation instructions, please see Getting a FreeBSD Port in the FreeBSD handbook.

The first thing you should do is make sure you set the USA_RESIDENT flag in /etc/make.conf.   I’m in New Zealand, so here’s my entry:

# If you're resident in the USA, this will help various ports to 
# determine whether or not they should attempt to comply with the 
# various U.S. export regulations on certain types of software which 
# do not apply to anyone else in the world.
USA_RESIDENT=           NO

Here’s what I did (remember that I had already installed all the ports):

# cd /usr/ports/security/ssh
# make
# make install

NOTE that ssh2 is not an upgrade of ssh.   You should use ssh2 if the license for ssh does not meet your requirements.  See the ssh2 article for more information.

Starting ssh

ssh actually has two parts to it.  The server (sshd) and the client (ssh).  The first thing you need to do is start sshd so that incoming requests can be answered.  I did it this way:

Then I tried to connect to the machine from itself.  For this example, I have installed ssh on the machine called asb and the user doing this is mike.

# ssh asb
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'asb' added to the list of known hosts.
Creating random seed file ~/.ssh/random_seed.  This may take a while.
mike@asb's password: 
Last login: Sun Apr 25 13:19:24 1999 from yourdomain.net
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
    The Regents of the University of California.  All rights reserved.

Welcome to FreeBSD!

If that’s what you get, then congratulations!  You have ssh running!

You should now try this from other machines and perhaps from a machine outside your network.  Be sure it works from outside your firewall if that is your intention.

Starting sshd at boot time

You will probably want sshd started at boot time.  That’s the normal thing to do.

When you install ssh, it will automagically create sshd.sh in the directory /usr/local/etc/rc.d/.   Files in this directory are special.  For more information about why they are special, see Starting stuff at boot time.  This file contains:

[ -x /usr/local/sbin/sshd ] && /usr/local/sbin/sshd && echo -n ' sshd'

Note: for some unknown reason, my install did not create this file.  I have no idea why.  At least one reader has had the same experience and had to create this file manually.  If you encounter the same problem, please add your comments.  I’d like to hear from you..

Remember to make that file executable. 

$ ls -lt sshd.sh 
-rwxr-x--x  1 root  wheel  32 Apr 25 15:00 sshd.sh

You can achieve those flags with the following command:

$ chmod 751 sshd.sh

Other security walls

I had several minor problems on the way to getting ssh up and running correctly.  These were configuration errors related to my environment and not ssh.   In fact, they were the result of other security walls not letting ssh in.   Once I told those tools about ssh, everything worked.


The following message was displayed when I first tried to connect to my system from outside my network.  This was because my router was not letting the requests in.   So I added port 22 (which ssh uses) to the list of allowed ports.
bash-2.02$ ssh freebsddiary.org
Secure connection to freebsddiary.org refused; reverting to 
                                                     insecure method.
Using rsh. WARNING: Connection will not be encrypted.
freebsddiary.org: Connection refused


Initially, I thought the above problem was my firewall.  It wasn’t.  But the following rule was going to be needed anyway.  So I added it.  I’m using ipfilter.
pass in quick proto tcp from any to any port = ssh 
                                                keep state group 100

to my firewall rules


After allowing my router and my firewall to let me in, I tried again.  But this time it was tcp_wrappers that wasn’t letting me in.
bash-2.02$ ssh freebsddiary.org
Connection closed by foreign host.

So I added the host I was connecting from to my /usr/local/etc/hosts.allow file.


After doing the above, I was able to connect:
bash-2.02$ ssh freebsddiary.org
mike@freebsddiary.org's password: 
Last login: Sun Apr 25 12:43:09 1999 from yourdomain.com
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.

Welcome to FreeBSD!


sshd logs information using syslog.   Here’s the log records which were created during my attempts from above.

This is the server starting up.  You will see that it takes some time to generate a new key.

Apr 25 13:17:54 ns sshd[77603]: log: Server listening on port 22.
Apr 25 13:17:54 ns sshd[77603]: log: Generating 768 bit RSA key.
Apr 25 13:18:48 ns sshd[77603]: log: RSA key generation complete.

This is my first connection from the machine on which ssh was installed.

Apr 25 12:42:48 ns sshd[77483]: log: Connection from 
                                                   port 3703
Apr 25 12:43:09 ns sshd[77483]: log: Password authentication 
                                                   for mike accepted.
Apr 25 12:45:57 ns sshd[77483]: log: Closing connection to

Here’s what happened when I connected from a host which wasn’t permitted by tcp_wrapper rules:

Apr 25 13:07:23 ns sshd[77564]: refused connect from rock.ghis.net

On this one, I forgot about the connection attempt, and it timed out.

Apr 25 13:12:06 ns sshd[77572]: log: Connection from 
                                                          port 967
Apr 25 13:14:54 ns sshd[77572]: fatal: Connection closed by 
                                                        remote host.

This is sshd regenerating the key, which is does from time to time.  See man sshd for more detail.

Apr 25 15:19:33 ns sshd[77603]: log: Generating new 768 bit RSA key.
Apr 25 15:20:19 ns sshd[77603]: log: RSA key generation complete.

ssh clients

I’ve seen several Windows clients which do ssh.
SecureCRT: http://www.vandyke.com/ TTSSH: http://www.zip.com.au/~roca/ttssh.html (also known as Terra Term and is what I used before I needed ssh2) TTSSH with ssh2: http://sleep.mat-yan.jp/~yutaka/windows/index.html (This is what I use) PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty.html SecureShell: http://public.srce.hr/~cigaly/ssh/

See also http://www.freessh.org/ which has a large list of clients (DOS, Windows, Mac, Java, Unix), servers (Windows, Unix), and various other resources.

Tricks with ssh

Thes aren’t actually tricks.  But they are things I wasn’t aware of.  You can do some very powerful things with ssh.  File copying or tape backup/restore are two of the most impressive things.  I haven’t tried the following, but I was given these by a reader who said they worked.  See man ssh for more information.
  • Copy the remote file to a local file.
ssh user@remote.com dd if=remotefilename | dd of=localfilename
  • Backup the the file to your local tape drive /dev/nrst0.
ssh user@remote.com dd if=remotefilename | dd of=/dev/nrst0 
  • This will do a backup from the remote host’s  /dev/wd0s1f device.   It will copy the backup to your local tape drive /dev/nrst0.
ssh root@host dump -0a -f - /dev/wd0s1f | dd of=/dev/nrst0
  • Here is what one reader wrote in with to to tar the contents of the current directory and deposit them as junktest.tar in bill’s home directory!

    tar cf - . | ssh bill@yourmachine.com dd of=junktest.tar

I am told the same things will work with rsh.

  One Response to “ssh – much more secure than telnet”

  1. If you have ssh, you probably have scp, so moving files around is as simple as ‘scp /path/to/localfile user@host:/path/to/remotefile’
    scp user@host:/path/to/remotefile /path/to/localfile

    I am using some of the other stuff you listed to do network backups: very useful.