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
lokkit
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 ayera.com
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 Find=off Insert=338 ;Insert key Remove=339 ;Delete key Select=off Prev=329 ;PageUp key Next=337 ;PageDown key [VT numeric keypad] PF1=327 PF2=335 PF3=off PF4=off Num0=off Num1=off Num2=off Num3=off Num4=off Num5=off Num6=off Num7=off Num8=off Num9=off NumMinus=off NumComma=off NumPeriod=off NumEnter=off [VT function keys] Hold=70 ;ScroolLock key Print=off 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] XF1=59 XF2=60 XF3=61 XF4=62 XF5=63 [Shortcut keys] EditCopy=1362 ;Ctrl + Insert EditPaste=850 ;Shift + Insert EditPasteCR=off EditCLS=off EditCLB=off ControlOpenTEK=off ControlCloseTEK=off 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 LocalEcho=off [User keys] User1=1077,0,$1F User2=1651,0,$1F User3=309,0,/ User4=55,0,* User5=74,0,- User6=78,0,+ User7=83,0,. User8=284,0,$0D User9=82,0,0 User10=79,0,1 User11=80,0,2 User12=81,0,3 User13=75,0,4 User14=76,0,5 User15=77,0,6 User16=71,0,7 User17=72,0,8 User18=73,0,9
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 192.168.0.100 I would type at a command prompt
ssh scott@192.168.0.100
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.)
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
/usr/sbin/sshd
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.
FreeBSD:
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
mv sshd.sh.sample sshd.sh
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
/usr/local/sbin/sshd
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
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 192.168.1.101. 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 192.168.1.101:/home/scottro
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@192.168.1.101:/home/scottro
Again, I'm asked for scottro@192.168.1.101'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@192.168.1.101:/home/scottro/foo /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 192.168.1.101:/home/scottro
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 192.168.1.101:~/foo ~ |
In other words, using ~ for home works. Actually, you don't even need the the tilde--I could just do
scp 192.168.1.101:foo . |
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 192.168.1.101 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 192.168.1.101: |
At any rate, this should be enough to get you started.