Computer Help for the New and Veteran User for Linux

Network & Security Help

  1. SSH Primer. Getting started with SSH (OpenSSH).

Answer: Getting SSH setup isn't hard, but can be a little confusing. I got a little stuck on the ssh_keygen part and the other box wouldn't ask me for the passphrase, so decided to write a little tutorial as I learn cause one I found on the net was either wrong or outdated.

The SSH package I used was OpenSSH 3.5-p1. Just emerge openssh to get the package on both (or more) computers.

If you have NFS working on the computers you are going to SSH to then you might have it setup already part way. SSH uses /etc/hosts.allow and /etc/hosts.deny and /etc/hosts  

SERVER: Computer you want to connect to.
CLIENT: The computer you are on.

SEPERATE CLIENT AND SERVER: The only one you have to set hosts.allow , hosts.deny up on is the Server. The Client only needs the hosts setup with the Server IP Address and name. So if you are doing this then:

On Server:




# IP Address of Client box

On Client:

/etc/hosts    localhost
# Server name (I have two names, but don't need them. One will do) and IP Address    CompaqGentoo Compaq
# Next one is an example entry for another computer over internet.     Moe

BOTH CLIENT AND SERVER: If you might be switching which is the server or client at times then set them both up to act as either. So put these on both computers.




# IP Address of Computer 1 box
# IP Address of Computer 2 box

/etc/hosts    localhost
# Computer names and IP Addresses
# As you can see they can be any names.    CompaqGentoo Compaq    athlonbox.mydomain.lan Athlon # Next one is an example entry for another computer over internet.     Moe

This will setup who can connect to your computers.

I was wondering why I could SSH to my other computer (which is acting as the SSH Server (sshd)) and didn't have it setup for SSHD in the /etc/hosts.allow file. Then tested it. In my /etc/hosts.allow file I had ALL: so it worked. I could have restricted it further with sshd: So I just changed it to sshd, but you could use ALL if want.

Once you have that setup on both computers. You have already decided if you want them to act as seperate server/client or both act as servers/clients. To get the server part working you need to start the Deamon. If you want it to come up at boot then you need to add it to the runlevels with: rc-update add sshd default    The SSHD is the Deamon that runs the Server. I don't use it much so just start it when I want it with: /etc/init.d/sshd start    On the Client you don't have to start anything. But then again, if are setting them up as both so you can log into either one, then start sshd on both when you want to run or as default. Once you have started sshd on the computer you want to act as a server you can test the connection out.

How to connect, for these examples I use Compaq Computer as my Server (the one I connect TO). If you have a user home on the other computer you can use that because by default SSH will try to connect as the user you are currently, so this would work: ssh Compaq , if you had a home folder on the server you could also type ssh decibels@Compaq. If you don't have a user home on the other computer either make one or you will have to connect as another user. If you connect as another user you will have to know the password for that user. So lets say you have user doug on the other server, you would use: ssh -l doug Compaq , but you could also do like above and leave the -l switch off and type ssh doug@Compaq. You would then just like before, be prompted for a password, but doug's password.

Since here is where you are most likely to run into some problem if you don't have it setup correctly let us run over a few tips:

  1. If it won't connect, try adding the -v for verbose. It will show you a lot more during the connection attempt.

  2. If the /etc/hosts is not setup correctly on the Client, you would get response: ssh: Compaq: Name or service not known

  3. If the /etc/hosts.allow is not setup correctly on the Server, you could get response: ssh_exchange_identification: Connection closed by remote host

  4. If the SSHD (server deamon) is not running on the Server you would get or there is a firewall preventing connection: ssh: connect to host Compaq port 22: Connection refused

    Note: If you don't want to bother with setting the iptables up to allow ssh entry. I have found that as long as the rules are setting to allow established connection to persist, that you can start the iptables again once you have connected. So in Gentoo it would be: Connect with ssh to the server with iptables (firewall) stopped. Once logged in, if you know the root password, then: /etc/init.d/iptables start. If you don't have someone at the other end to stop the firewall, you will have to get around to putting in the rules to allow the ssh connection. Unless your really paranoid, this will only leave you momentarily vunerable. The password send over ssh is encrypted so no problem there, you would be vunerable if at all during the time the firewall was stopped.

  5. Also, if you create a new user on the Server, make sure the user was create with a shell like /bin/bash available or it won't work either. You more than likely will get: Permission denied, please try again.

Solve any problems you have connecting. Once you can connect to the /home folder you want. The first attempt will bring up this response:

The authenticity of host 'compaq (' can't be established.
RSA key fingerprint is 8c:7a:94:81:02:37:f2:ec:a9:c6:01:43:b2:87:8b:6d.
Are you sure you want to continue connecting (yes/no)?

Answer 'yes' then you will be told this:

Warning: Permanently added 'compaq,' (RSA) to the list of known hosts.
doug@compaq's password:

If you enter the password correctly you will be told your connected and be in the /home folder of that user on the Server. So after the first connection established, then type exit or logout

Now to create a key for better security. That way if someone cracked you password they could get in from anywhere. With a key that would be harder cause the key is on your machine, so they would have to be on your machine also or be able to duplicate the key.

Setting up the SSH RSA or DSA Keys. There are a few confusing items on setting up the keys on the internet, so I had to search for the correct info. When looking for such information, going straight to the source sometimes is the best thing. From the OpenSSH website:

   1. There are two versions of keys: Version 1 and 2. Which do you have and how do you find out. To start off, to create a key you use ssh-keygen command. Use the -t switch with it to specify the type. There are 3 values you can use.

  1. rsa1 for protocol version 1.

  2. rsa or dsa for protocol version 2.

   2. How do you know which version you are using or want to make sure you have the one you want?

  1. Version 1 will show identity and files in your HOME/.ssh folder.

  2. Version 2 will show id_dsa and files in your HOME/.ssh folder, if you make a DSA key.

  3. Version 2 will show id_rsa and files in your HOME/.ssh folder, if you make a RSA key.

   3. Some people think you must create a 'authorized_keys2' file for version 2 and 'authorized_keys' for version one.

  1. Not according the what I have done or according to OpenSSH website. All you have to do is: The contents of this file should be added to HOME/.ssh/authorized_keys on all machines where the user wishes to log in using public key authentication. Straight from the source boys.

  2. Now I don't know if this applies if you have version 1 and version 2 keys on the same Server. Maybe when version 2 first came out it was a way of keeping straight which version you were using. But I would think that people would only use one or the other version.

Now the big question. Do I have to use a KEY? Actually, NO. You don't have to use a key. SSH has a default way of handling authentication, by asking for a password. This passing of the password to the server is secure and encrypted so it isn't a security risk. So it is up to you. If you only turn on sshd once in a while and don't leave it on, then maybe you aren't worried about someone getting past the password. If you start sshd at boot, then maybe you should have the extra protection. I only turn mine on once in awhile, but use version 2 keys still.

We're not going to go into great detail on the keys here, just how to generate them and get it to the server. There are some links at the bottom you can follow for more information.

How to create a key: After you have exited the server type in (as USER), ssh-keygen -t dsa   That will give you a version 2 DSA key. If you want RSA, the substitute in rsa for dsa. If you for some reason are connecting to a server using version 1 key then use rsa1.

You will see:

Generating public/private dsa key pair.
Enter file in which to save the key (decibels/.ssh/id_dsa):

Just accept the default is good, hit Enter.

The Passphrase can be anything up to 600 letters (spaces, characters, numbers, symbols). Enter what you want and something you will remember. You will be asked to enter it again. Examples: The dog bit my ear off. or My washer 15 what you say! Entering no passphrase is not a good idea, if you may be connecting to several servers and only want to enter the passphrase once, take a look at the links below and see about ssh-agent and keychain.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Below tells you where you where your identification and public key were saved. Should be where you said above.

Your identification has been saved in /decibels/.ssh/id_dsa.
Your public key has been saved in /decibels/.ssh/

The last line is your key fingerprint

The key fingerprint is:
d9:3d:76:94:18:c6:3b:f2:73:fc:c7:8a:25:84:99:b4 decibels@c2405134-b

Now what to do with the key. You must copy the PUBLIC Key over to the server. So ssh decibels@Compaq again and enter your password. Then copy the key over as authorized_keys to the HOME/USER/.ssh folder, if there isn't a .ssh folder there, then make one (ie. mkdir .ssh). To copy it over to your .ssh folder on the server use: scp ~/.ssh/ decibels@Compaq:~/.ssh/authorized_keys   Then you should see something like this:

decibels@compaq's password:
testscp 100% |*****************************| 605 00:00

Now try and login with SSH again to the Server and you will be asked for a passphrase instead of a password. There is one more thing to do. You need to edit at least one thing on the sshd_config file. Here is why: I have found so far the defaults are good (also, they look like there commented out in the config file, but aren't. They tell you what the defaults are, so if you want to change it then uncomment it and make the change). But, with the passphrase, if you hit return (entering no passphrase) or enter it wrong several times it will then ask you for a PASSWORD. Well, that kind of defeats the purpose of putting a passphrase in for better protection. So as root, edit the /etc/ssh/sshd_config file. Uncomment and change to no:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no     change to no and uncomment.
#PermitEmptyPasswords no

Then when you do not know the passphrase or don't enter one and hit return you will be denied access and not be asked for a password. Like so:

Permission denied (publickey,keyboard-interactive).

One little last thing. You used the SCP command to copy the key over to your home folder. Let's say you want to download a large file from your brothers computer across the country. Add his IP Address to your /etc/hosts file, then give it a name. Something like: brother

Doesn't really matter as long as the IP Address is correct. Have him start the sshd and put the file in his home folder. Let's say your brothers home folder is called 'rick' . Then to get the file (don't start ssh and login. You don't have to). Just:

scp -C rick@brother:filename  ~/

You could also use a period . instead of the ~/ for your home folder if your in it. The file will come to you. If you want to send a file to him the same way, then just put the filename on your side between the scp and rick@brother . The -C isn't needed, it is for compression though and might download faster if it can compress it.

Tunneling VNC thru SSH or Running X Remotely (X11forwarding) If you want to tunnel VNC thru SSH which is much more secure, then you need to enable X Forwarding. Same goes if you just want to use X11 on SSH and not use VNC. Note though, I have done this and it does seem slower than just forwarding X with SSH or just using VNC by itself, even with compression, even on my LAN. Just X11Forwarding though seems fine. I would use TightVNC also, it has a command ( -via ) that will automatically start the ssh for tunneling. Works great. Give the guy a big hand and maybe a donation.

Server: Edit the /etc/ssh/sshd_config file. Uncomment the default and change to yes:

X11Forwarding yes

Client: Edit the /etc/ssh/ssh_config file. Uncomment the default and change to yes:

X11Forwarding yes

Log in via SSH to the Server and issue a /etc/init.d/sshd restart to restart the server. Then log off and back on and you will notice that you have a line saying it is creating a new authority file.

/usr/X11R6/bin/xauth: creating new authority file /home/Compaq/decibels/.Xauthority

X11Forward with SSH: Now you can run X programs on the remote server. I put the Gentoo Filemanager on there. Logged on and ran: gentoo . Gentoo FileManager pops up in a seperate window.

Tunneling VNC (TightVNC) thru SSH: To do this issue command:

vncviewer -compresslevel 9 -quality 5 -truecolour -encodings "copyrect tight hextile" -via Compaq :0 This is the breakdown of what I am using here:

-compresslevel ---> 1-9 level of compression. Says don't use 0. Also higher compression make the server CPU work harder, so play with this setting to achieve the best for the connection.
-quality       ---> 0-9 . Note: 0 doesn't mean the quality will be unacceptable.
-truecolour    ---> Try to use TrueColor.
-encodings     ---> different compression methods to encode screen updates, in order of preference. Read the man page or documentation for more info. Still playing with the best for over the net.
-via           ---> Automatically create encrypted TCP tunnel to the gateway machine before connection, connect to the host through that tunnel (TightVNC-specific). Just put the name of the host (server) in there. I am using my cheapy Compaq computer that I have listed in /etc/hosts. You could put an IP Address to the computer also instead. If you want to connect to another computer that you don't have an account on but know the users password than do it like this: username@Host So if my Compaq had a user named Joe. I would use: Joe@Compaq . And finally, the display number. Notice that there is a space between the Host and Display number, which in this instance is 0. You have to use the display number of the server. I usually use krfb so will can have the other person see what I am doing and it always uses 0 by default.

Using the Gentoo LiveCD to CHROOT and fix a system remotely with SSH. Let's say your friends computer is borked and you are going to try and fix it, but he/she cannot boot to the system. You could put the Gentoo LiveCD in have them do a few things then get in to try and fix it.

What you need them to do:

  1. Make a root password. When they get to the prompt on the LiveCD enter: passwd then enter a password and tell you the password.
  2. Add your ip address and a alias to the /etc/hosts file: see at top of primer. Enter: nano /etc/hosts
  3. Uncomment a line in /etc/ssh/sshd_config to allow root logins: nano -w /etc/ssh/sshd_config. Then uncomment this line: #PermitRootLogin yes.
  4. If they are new to Linux, make sure they save the files. With nano: Ctrl o is save, Ctrl x is exit.
  5. Start the ssh daemon: /etc/init.d/sshd start

What you need to do:

  1. Enter their ip address in your /etc/hosts file if not already. Since there isn't a key now you will have to make one or just go in without one, I do. There system is borked anyway. I usually make a new entry in the hosts file like: ip_address_numbers    name
  2. Then: ssh root@name .
  3. If you mess up and screw up the password, you might have to go in an modify the name in /etc/hosts to try again. Just add a number after it save it and try again, like: name1 or name2.
  4. If your going in without a key, you will have to type in 'yes' several times.
  5. Then you can use cfdisk or fdisk to find out what their partitions are, if they don't know, mount them and bind /proc from the cd to the root partition, chroot over. Just like in the install guide for Gentoo if you forget. Once here you can rebuild the kernel, run lilo,...

I have done this several times off the Gentoo LiveCD to rescue a system.


OpenSSH Key Management, Part1 by Daniel Robbins
OpenSSH Key Management, Part2 by Daniel Robbins
OpenSSH Key Management, Part3 by Daniel Robbins
OpenSSH HomePage
ssh_config and sshd_config Options


Valid XHTML 1.0!