Sunday, November 4, 2007

HOWTO: setup sshd_config and ssh clients

Overview
SSH is integral in having a secure network. I love it and use it everywhere I can. There are a few things that can be done to make your setup easier to use and a bit more secure.

This setup was done using Fedora Linux version 3-7. Since openssh is a common package, this howto can be done one just about anything it runs on.

Disclaimer
I am, nor will I ever consider my self a security expert. Please ensure you understand these commands before using them. If you do find a hole or mistake, please leave me a note.

SSHD
The sshd daemon is the core to SSH. It is controlled using a config file /etc/ssh/sshd_config This file has many params. The following are a few that you should consider changing.

Force all clients to connect using version 2 and not 1.
Protocol 2

Narrow the list of users that can connect. If your network is small enough, list the users in an AllowUsers directive.
AllowGroups users
AllowUsers uuklanger smgeller
DenyGroups root
DenyUsers root

Lock down as much as you can here. You would be surprized how many differnt ways hackers try to get in. By telling sshd to only allow certain groups and users, you may prevent a hacker from getting in via a default account installed by some package you installed.

SSH Client
Using ssh is easy. From a prompt just type ssh -X rmnp.inhouse.rockynet.com to login as "you" to a system called rmnp. -X enabled X windows popping. If you need to copy a file, you can use the scp command. For example, scp file.txt rmnp.inhouse.rockynet.com:/tmp will copy the file file.txt in to /tmp on the server.

Once entered, a password prompt will be displayed. The password you use is the password of your account on the server. In this case, my uuklanger password for rmnp. Entering passwords is pretty boring. To get around this, and to increase your security, you can use keys. In the following example, you will see how to create and setup a key for user "uuklanger" on the workstation "tree" that will tell "rmnp" to trust your ssh connections. This assumes that you have never done this before and that the file authorized_keys does not exist.

On the workstation "tree" do the following as yourself (uuklanger in my case):
  1. cd ~/.ssh/
  2. ssh-keygen -t rsa -b 2048
  3. When you get asked for a filename, call it id_rsa
  4. The rest of the prompts, just hit enter.
  5. You will now have two files generated. id_rsa and id_rsa.pub
  6. scp id_rsa.pub uuklanger@rmnp.inhouse.rockynet.com:.ssh/authorized_keys
Done.. Now if you ssh to the server, you will be let right in. In step #6, if it fails, it is possible that you do not have a .ssh directory on the server. If that is the case, connect to the server and then ssh back to your workstation. SSH will create the .ssh directory for with the correct permissions. You can do this manually too.

For step #6, if you already have an authorized_keys file on the server, you will want to transfer id_rsa.pub to the server and then append it to authorized_keys. Otherwise, your file will be overwritten.

Now try to ssh -X rmnp.inhouse.rockynet.com and enjoy the direct access without the pesky password prompt.

Final Thoughts
These steps will help lock down ssh a bit more the the default. If you want to lock it down more, you can turn off passwords all together and rely on keys only. This can be done in the sshd_config file. See the openssh documentation for the steps on how to do this. This is just getting it going. There are tons of cool things that SSH can do on top of the settings done here. There are lots of tricks out there. Enjoy.

Thursday, November 1, 2007

Net App should brace for impact

Jonathan Schwartz's blog is kind of interesting today. I have always like SUN and this blog is one reason why.