by Wayne E Goodrich (Outlaw)
2006-02-11

Many Linux administrators and desktop users need a secure method of shelling into a linux server to do work. So here, I'll illustrate some tips for secure remote access using OpenSSH.

Secure Shell

Secure shell is the most common remote shell utility in use, since it addresses the shortcomings of the older utilities like telnet and rlogin. But left in its default configuration, as shipped by some of the major Linux vendors, it still can be insecure. Here are some ways to make it more secure. OpenSSH is installed and enabled by default in most, if not all all Linux distributions, so we can get right to configuring it for better security.

Disallow direct root login

If secure shell is configured to allow direct login by root, it makes it easy for a bad guy who either brute forces the password or manages to obtain it outright, to get access. It's also generally a good idea to force users to log on as themselves and su to root, to preserve an audit trail. Let's fix that.
Visit the ssh server config file /etc/ssh/sshd_config in your editor of choice and change the line:
Code:
# PermitRootLogin yes
to
Code:
PermitRootLogin no
Make sure to remove the '#' to uncomment. So we've disabled root login. Now we'll disable the older ssh protocol 1.

Disable ssh protocol 1

Doing this requires that ssh clients like PuTTY be changed to use protocol 2. Most Linux ssh clients use either, and will be forced to protocol 2 if the server is configured with 2 only. Let's do that now - change:
Code:
# Protocol 1,2
to
Code:
Protocol 2

Set up public key authentication


If your users have a private key that matches a corresponding public key on the server, you can deny all logins that do not provide such a key. Also, the remote user can use a key agent for some added convenience that will enable them to enter a password once and shell in all day without providing another. The agent handles passing the key that was decrypted using the password. Seeing it in action will clarify the concept.

Let's do it then, first create the user's key pairs. We'll do it with PuTTY and also with the OpenSSH secure shell client in Linux. Grab Pageant and PuTTYgen from here, and fire up PuTTYgen to generate a key pair. Select ssh2 dsa key and the length of key. Then generate the key. Save the private key and copy and paste the public half to notepad. You want to highlight and paste the Public key for pasting into OpenSSH authorized_keys file: The key needs to be one long string when pasted into notepad.

Now we can make pageant load the key when launched, by providing the path to the private key. Right click on the pageant icon and type in a space and then the path to the private key.
In the Target field, we want the executable ant then the path to the pricate key
Code:
C:\pageant.exe c:\priv.ppk
Test the agent

When you launch pageant, you'll enter the password to decrypt the key and it will remain in memory until you close pageant. Remember to close it when you're through to prevent someone from gaining access to your servers from your station.

But first we need to prepare the remote server for the key authentication. First, we'll work on the account that will be logging in, test it, then configure the ssh server to deny all attempts that do not have a key. In the home directory for the user that will use the key, do the following:

Code:
mkdir .ssh; chmod 755 .ssh
Paste the public key into .ssh/authorized_keys
Code:
chmod 644 .ssh/authorized_keys
If you have'nt already done it, launch the agent and type in your password. Then try to PuTTY into the account that has the keys. If it works without you entering the Linux password, we can move on. If not, there's a step missing. Double check all the steps thus far.

Deny users without keys

Edit /etc/ssh/sshd_config and change the following:
Code:
#PasswordAuthentication yes
to
Code:
PasswordAuthentication no
#ChallengeResponseAuthentication yes
to
Code:
ChallengeResponseAuthentication no
and depending on distribution
Code:
#PAMAuthenticationViaKbdInt yes
to
Code:
PAMAuthenticationViaKbdInt no
Now restart the ssh server the Redhat way.
Code:
service sshd restart
Or, the Debian way
Code:
/etc/init.d/ssh restart
You should now be denied access if you connect and try to login without a key loaded. Try it by closing pageant and attempt login.
You can use agents in Linux too. To do that, generate an ssh key pair and run the ssh agent with that key. As a user, do the following, entering passwords and accepting default filenames:
Code:
ssh-keygen -t dsa
Paste id_dsa.pub into the .ssh/authorized_keys on the user's account on remote server. Copy it over, and:
Code:
cat id_dsa.pub > .ssh/authorized_keys; chmod 644 .ssh/authorized_keys
Now we'll launch the ssh agent and load the id_dsa key, using the password
Code:
ssh-add
You'll be prompted for your password

Test it all out

Test logging into the server now. If it works, you now have a more secure ssh setup. A couple things about PuTTY and forwarding agents. In Linux, the site wide client ssh config file, /etc/ssh/ssh_config has an option called ForwardAgent. When set to yes, it allows one more consecutive connection using the loaded agent key. As in - ssh host1 then from there - ssh host2 without password, provided host2 is set up with the proper configuraton for pub key auth and users' public keys. In PuTTY, check off the forward agent option.

Now we can shell over to as many servers as we set up keys for, with the balance of security and convenience. Make sure to train your users to close the agent when they're through working. A nice side benefit of this setup is the ability to run commands distributed among a group of similarly configured servers.