This article was originally written about RedHat 7.1 which had ipchains as its default firewall. I think I've changed all the references by now. It also refers to lokkit, which is a RedHat and probably Fedora specific tool. Other distributions have their own version of a program to configure your firewall.

This was one of those small aggravating things that took two minutes to fix once I found out how to do it. However, my first few searches on RedHat's site and deja came up blank, so I've put up this article.

With RedHat 7.1, if one accepts the defaults during installation, ssh access is blocked. If one hasn't paid attention during install and just accepted default settings at that time, and later tries to ssh to the box, they won't succed.

As Linux becomes more popular, more inexperienced people try it, so blocking things by default is probably a good idea. (See my above comments about telnet.) The default level of medium security also blocks telnet, ftp, etc.

At any rate, during installation, when you are choosing your level of security, you do have the option of allowing ssh connections. However, once installation is complete, you still aren't able to ssh into the machine without making adjustments.

Now, what if, during install, you just accepted the defaults and then decided you want to allow ssh access? It's probably not installed. One can check this with

rpm -q openssh

If you get back an answer with a version number, you're already partway there. However, if you get something like

package openssh is not installed

it's time to install the various parts.

rpm -q openssh-clients

rpm -q openssh-server

Even if openssh is installed, the two lines above are other necessary parts. Chances are, if you didn't choose it during installation, then you'll need all three of these. They're all on the CDROM in the RedHat/RPMS folder, usually on the first CD. This will all be done as root. Depending upon your need for security and level of paranoia, you may have logged on as a normal user and then done an su to root. If this is the case, you often have to type the full path to a command--this is a good habit anyway.

Installation of the RPMS, through the GUI interface is quite simple--click on the packages and the RPM package manager will run, installing the package. I've found in my edition at least, that usually an error message will pop up, but it seems that it can safely be ignored.

If you prefer, as I do, to do it all through the command line then first, mount the CD

mount /dev/cdrom

In RH7.1 this should automatically mount it as /mnt/cdrom--if you get an error message about there being no mount point, then the lazy man's way is to simply make one.

mkdir cdrom
mount /dev/cdrom cdrom

Then get the exact names of the files you'll want. In this case, I'm assuming that it did automatically mount the CD drive in /mnt/cdrom. If it didn't then substitute the folder we made, cdrom for /mnt/cdrom

We move into the directory that we want.

cd /mnt/cdrom/RedHat/RPMS

We find the packages that we need.

ls openssh*

If you're not used to Linux, case is important, so type these commands using upper and lower case as shown. This will give you the names of the openssh packages. If you are only going to ssh to this box and not from it, then you only need openssh and openssh-server. However, since you're already here, you should install the client as well, since, sooner or later, you'll probably have use for it.

Now to install (The commands I use are my personal habit--other commands will work. I use rpm -Uvh. The U indicates that it should upgrade if there is an earlier version, the v makes it verbose and the h shows progress by hash marks. The asterisk at the end, as you probably know is a wild card, meaning that if there is only one file beginning with openssh the asterisk will simply save me from typing openssh-2.4.75 or whatever the version might be.)

rpm -Uvh openssh*

This will install the all the ssh packages, one by one. If you didn't want to install the openssh-getpass, for example, then you would have to do something like

rpm -Uvh openssh-[version number]
rpm -Uvh openssh-server*

rpm -Uvh openssh-clients*

The next step is the one that I had trouble finding on the web. At a command prompt type


This will launch a graphical configuration editor. (Although it is graphical, it can be run from from a text login. That is, you don't have to start X before running it.) Choose custom. Then, you can select ssh as something to be permitted.

(When you get more experienced, you will probably want to directly edit your ipchains or iptables--that is beyond the scope of this article, but something to keep in mind.)

This firewall configuration tool affects your iptables settings, which, with similarities to a Cisco IOS extended IP access list, filters packets based on various factors.

Restart iptables

/etc/rc.d/init.d/iptables restart

Then start the ssh daemon

/etc/rc.d/init.d/sshd start

One more gotcha. Windows, at least up RC2 of XP, doesn't come with an SSH client. There are free ones out there. One is Putty, which can be downloaded here. (Thanks to Jason Flatt for that one.) Unzip it, click on it, put in the address of the machine you're trying to reach and you're done.

Terraterm used to have a patch for ssh, but I believe the developer stopped working on it--not sure about that, but at any rate, I used to have a link that turned out to not work with ssh2. However, there is a replacement that can be gotten at

The only problem I've ever run into with Terraterm is that sometimes the numeric keypad comes out strangely, especially if one is working with Universe. (It seems that when one logs into Universe, a command is generated.) I fixed that with a quick search on deja. The keyboard.cnf file should be replaced with the following:

[VT editor keypad]
Up=328          ;Up arrow key
Down=336        ;Down arrow key
Right=333       ;Right arrow key
Left=331        ;Left arrow key
Insert=338      ;Insert key
Remove=339      ;Delete key
Prev=329        ;PageUp key
Next=337        ;PageDown key

[VT numeric keypad]

[VT function keys]
Hold=70         ;ScroolLock key
Break=69        ;Pause/Break key
F6=64           ;F6 key
F7=65           ;F7 key
F8=66           ;F8 key
F9=67           ;F9 key
F10=68          ;F10 key
F11=87          ;F11 key
F12=88          ;F12 key
F13=573         ;Shift + F3 key
F14=574         ;Shift + F4 key
Help=575        ;Shift + F5 key
Do=576          ;Shift + F6 key
F17=577         ;Shift + F7 key
F18=578         ;Shift + F8 key
F19=579         ;Shift + F9 key
F20=580         ;Shift + F10 key
UDK6=1088       ;Ctrl + F6 key
UDK7=1089       ;Ctrl + F7 key
UDK8=1090       ;Ctrl + F8 key
UDK9=1091       ;Ctrl + F9 key
UDK10=1092      ;Ctrl + F10 key
UDK11=1111      ;Ctrl + F11 key
UDK12=1112      ;Ctrl + F12 key
UDK13=1597      ;Ctrl + Shift + F3 key
UDK14=1598      ;Ctrl + Shift + F4 key
UDK15=1599      ;Ctrl + Shift + F5 key
UDK16=1600      ;Ctrl + Shift + F6 key
UDK17=1601      ;Ctrl + Shift + F7 key
UDK18=1602      ;Ctrl + Shift + F8 key
UDK19=1603      ;Ctrl + Shift + F9 key
UDK20=1604      ;Ctrl + Shift + F10 key

[X function keys]

[Shortcut keys]
EditCopy=1362   ;Ctrl + Insert
EditPaste=850   ;Shift + Insert
LineUp=840      ;Shift + up-arrow
LineDown=848    ;Shift + down-arrow
PageUp=841      ;Shift + PageUp
PageDown=849    ;Shift + PageDown
BuffTop=1351    ;Ctrl + Home
BuffBottom=1359 ;Ctrl + End
NextWin=1039    ;Ctrl + Tab
PrevWin=1551    ;Ctrl + Shift + Tab

[User keys]

If that seems difficult, you can get a zipped version of the text file here. Just save it and paste into your Terraterm pro folder as keyboard.cnf saying yes when they ask if you want to overwrite the existing one.

One small gotchta with SSH: Using ssh from another Linux box connects as whatever user you are by default. In other words, if I'm on box A as root and ssh to box B, the default would be to connect to box B as root. If I'm user scott on box A and on box B only have an account as scottr, this could also cause a problem.

To avoid this, the syntax is

ssh username@machinename.

Therefore, if I want to connect to the other machine as user scott, and the other machine's IP address is I would type at a command prompt

ssh scott@

You can also run X applications through ssh, which can sometimes be convenient.

(As I'm not at all sure of the security dangers with this, I'll add that I only do that on rare occasions on a closed network. Rather than give the information here, I'll simply say see man xhost on the server machine and man ssh on the client machine.)

Various Problems

At time of writing (late June, 2002) there have been some exploits in SSH and people are advised to upgrade to openssh-3.4. Various distros had minor problems upgrading, so let me go through the things I ran into. (Some of these were problems from upgrading to 3.1 and may or may not still exist)

Also, please note that in most cases, the default will be

ChallengeResponse yes and it is recommended that this be changed to

ChallengeResponse no

Gentoo Linux:
What was happening was that when people upgraded to openssh-3.1, usually through Gentoo's excellent portage system, suddenly, only root could login with ssh. The reason for this was a missing shell entry in /etc/password. When one adds a user in Gentoo, although the new user's shell will default to /bin/bash, it's not specified in /etc/passwd. The fix was to simply add /bin/bash at the end of the entry for the user. (Just imitate the syntax used for root as far as spacing, colons, etc). If, when adding a user, one adds the -s /bin/bash option this problem doesn't occur. For example

adduser -m -s /bin/bash john

(The question was coming up so frequently that they added it to their faq. As with most things in Linux, there are often several ways to do something--their suggested method is to use the usermod command. So, if your user is named john, you would type

usermod -s /bin/bash john

and this will also fix the problem)
Upgrading, through Gentoo's portage, to openssh-3.2 also produced a minor problem. Upon reboot, I would get an error message

Starting local...
/sbin/rc: /mnt/.init.d/softscripts/sshd: Permission denied

I would still, after booting, be able to start sshd with a simple


however, this was annoying. A little checking indicated that the softscripts thing was a link to /etc/init.d/sshd. No one had executable permissions on the script, so I did a chmod to 755 on it. This fixed the problem. (I'm not sure that 755 was ideal, actually, however, it seems to be what the permissions are on most of the things started at boot in /etc/init.d This only happened once--a fresh install installs openssh-3.2 and I haven't had the problem. Upgrading from 3.2 to 3.4 was simply a matter of typing

emerge openssh

and everything went smoothly.

With FreeBSD, if you simply upgraded through ports, everything is put into /usr/local. There is logic behind this--if it were put into /usr/sbin, anytime you do a make world, it can get clobbered. So, after installing from ports, you should make a few changes to /etc/rc.conf. You can just copy over the new /usr/local/sbin/sshd and /usr/local/etc/ssh/sshd_config over to /usr/sbin/ and /etc/ssh respectively, but again, a cvsup and make world will clobber it. The solution was given me by Jonathan Chen and Scott Mitchell. (From posts they made on FreeBSD-questions--I'm mentioning their names here without permission as they were public posts)

Install from ports. First cvsup your ports-supfile, then cd over to /usr/ports/security/openssh-portable. (In general, portable is considered a better choice than /usr/ports/security/openssh.) Make sure that it's version 3.4 (as of time of writing) by doing

head Makefile

This will give the version number. Then, as usual, just type make install to install it.

Edit /etc/rc.conf. Change the sshd_enable="YES" to a "NO". (Or remove it entirely) Otherwise, upon bootup, FreeBSD will run the older /usr/sbin/sshd. Edit your /usr/local/etc/ssh/sshd_config file, as mentioned above, changing the ChallengeResponse line to no. (And uncomment it You may find that this has already been done). Now, enable the new startup script

cd /usr/local/etc/rc.d

Upon reboot, FreeBSD will start the new /usr/local/sbin/sshd daemon.

To start it running right away, I just do

ps ax | grep sshd

I'll get a pid number indicating that /usr/sbin/sshd is running--for example, 17229

kill 17229

Now you're running the new version of openssh. It may complain that there is no /var/empty directory, which is easily remedied by doing

mkdir /var/empty

Interestingly enough, I've found that so long as /usr/sbin/sshd exists, even if a ps ax | grep sshd shows me that /usr/local/sbin/sshd is the daemon running, that a which sshd will give me /usr/sbin/sshd. I assume that's because /usr/sbin/ comes before /usr/local/sbin in the $PATH variable. Also, if I do sshd -V it will give me the old version number. However, if I do something like

mv /usr/sbin/sshd /usr/sbin/sshd.old

doing sshd -V will give me the proper version number.

Actually, the pkg-message gives the answer, changing your path so that /usr/local/sbin comes before /usr/sbin. They also suggest that you leave enable_sshd set to yes and add the line ssh_program="/usr/local/sbin/sshd" in /etc/rc.conf. My way is probably the lazier man's way, however, it seems to me to be slightly more efficient.

Although it's usually a better idea to obey the directives of a pkg-message, in this case, there was some debate about it on FreeBSD-questions--either method will work, I think that the one that I've given is probably easier.

I believe that if you install the openssh-portable there's an option to override the base install version of sshd--however, this might get clobbered when you do a make world, so I prefer the way given above. RedHat:

With RedHat, the default seems to be with md5 passwords rather than pam. Therefore, if you build from source, during configuration, you have to specify
./configure --with-md5-passwords This seems to fix any problems with it. The other issue I ran into with RedHat is that it wanted a user named sshd. So

adduser -s /bin/false sshd


One other convenience of ssh is that it allows you to copy files between computers. This command is called scp, I assume it stands for secure copy. The syntax is quite simple.

scp source destinationmachine:/destinationdirectory.

An example should make that clear. Suppose, on my home network, I have two machines, both with an account named scottro. On machine one, I have a file that I want to copy over to machine two. Machine two's IP address is I want to put the file, which we'll call foo which is in /home/scottro on machine one in the /home/scottro directory on machine two. So, while in /home/scottro on machine one, I type

scp foo

I'll then get the normal request for password etc, the same as if I was simply trying to ssh into machine two. Once I'm authenticated, it will copy the file.

In the same way as mentioned previously, if I'm on in machine one as a different user, who also has a file named foo in his current directory, I could do it thusly

scp foo scottro@

Again, I'm asked for scottro@'s password, and once authenticated, can copy the file. If I want to do it the other way, that is, while on machine one, copy a file in scottro's directory from machine two to my current machine, then it would be (the scottro@ is only necessary if I'm on in machine one as a different user than scottro)

scp scottro@ /home/scottro/

In other words, the syntax is almost the same as the cp command--the change is that we're including another machine and it has the colon after the machine name (but before the file name or directory name on the remote machine, eg

I use /home/scottro to clarify the example--however, if I'm scottro on both machines, and I want to copy file /home/scottro/foo on the remote machine to my home directory on the current machine

scp ~

In other words, using ~ for home works. Actually, you don't even need the the tilde--I could just do

scp .

Hopefully, you could see that the command ends with a period, which represents the current directory. Going the other way, if I'm copying to I could just do (assuming I'm in my home directory on the local machine and want the file to go to my home directory on the remote machine)

scp foo

At any rate, this should be enough to get you started.