Linux - How To Generate Public-private Key Pairs And Secure Web Browsing Tips

SSH is an important tool in Linux / UNIX and an amazing piece of software. It's one of the top 2 or 3 things that an experienced Linux / UNIX system administrator uses every single day.

People use SSH to connect to their home machines from work and to their servers from both work and home.

People use SSH in backup scripts.

People use SSH for lots of other things.

 

There is some interesting history about SSH - it was originally developed by some company and the original versions were actually open-sourced, and then they closed it up at some point but then some other developers took the last open source version and created a new open source release which was then later picked up by all the OpenBSD guys and turned into OpenSSH, which is the actual piece of software that we all use (ssh being one of the tools that comes with OpenSSH).

 

Basically, SSH is a secure replacement for telnet. It lets you network in remotely to machines from other machines (either across a local network or through the Internet), so you can access a server that is sitting across the room as easily as you can access a server that is on the other side of the world, or you can access your workstation that is sitting in the basement of your house from your laptop while you're sitting upstairs.

 

It's very secure both in the connection as well as of course in the transmission of the data back and forth. I'm hesitant to say it's totally secure, knowing what I know about another technology called IPSec. SSH encrypts the data at the TCP level. IPSec, as the name implies, encrypts the data at one level below in the OSI model, the IP level, which makes it more secure than SSH.

 

SSH is so essential that every distribution comes with it. I would be really surprised if there was any distribution that didn't.

So you can open up a terminal and type:

man ssh

and find some information about SSH.

The SSH configuration files are in /etc/ssh typically. There are two files in there:

ssh_config (the configuration file for the SSH client)

sshd_config (the configuration file for the SSH daemon / server)

 

How you start, stop or restart SSH usually depends on the distribution, but in most of them you would type at the command prompt as root - or by prepending sudo:

sudo /etc/init.d/sshd (start|stop|restart|status)

So how do you use it?

Let's come up with a hypothetical scenario.

Let's say you have a Linux server in the basement, and let's say the machine is called "server" and then let's say you have a laptop, and you want to be able to connect to your server from your laptop, and let's say your server has two users defined on it: root (obviously) and a regular user called joe.

Let's say the laptop runs Linux and also has users root and joe.

So you have the same users on both machines.

You need to start the SSH daemon on the server machine, then, from the laptop, open up a terminal and simply type:

ssh server

That's all you have to do to start with.

Now a couple of things are going on here.

First of all, by not using a user name in the command, SSH assumes that you are going to try to ssh in as the same user that you are logged in as on the laptop.

So if you are logged in to the laptop as joe, you will be ssh'ing into the server as joe. You don't need to include that because it's the same user.

If you want to log into the server machine as a user other than the one you are logged in as on the client side (root, for example), you would simply type:

ssh root@server

And then the other thing that's going on here is using the word "server". That's the machine name of the computer you want to connect to, and that's assuming that on your network you can find that name. You can always edit your /etc/hosts file and put the IP address of the machine in there and associate it with the string of characters "server", as another way to connect the IP with the name.

You can also use an IP address in the ssh command, so you could also do:

ssh 192.168.1.50

if that is your server's internal IP address.

 

When you first try to ssh into the server from the laptop, you will see on the laptop screen, in your terminal, some text that prompts you to accept the fingerprint of the machine you are trying to connect to.

Basically, the laptop is going to "save the fingerprint" of the server that you are connecting to. That way in the future it can recognize that it's the same machine, the idea being that this way if some other machine is pretending to act as your server and doesn't have the same fingerprint, the ssh client will immediately warn you that the fingerprints don't match.

That fingerprint gets added to a file called known_hosts on the laptop, in a hidden directory called .ssh in your home directory. That hidden .ssh directory is where all of your ssh-related user files are kept.

 

At this point ssh will ask you for the password of the user joe on the server machine, you type it in and you're in.

 

That's it - very easy, very secure (the whole thing is encrypted from the beginning to the end, the connection itself where you type the password is encrypted all the way along the way).

 

Something else that you can do with SSH is you can use a facility / command called "secure copy" or scp. It acts just like the cp command (the Linux copy command), except the copying process is taking place in a secure manner.

 

To give an example, let's say you have a file called file1.txt on your laptop, and you want to copy it over to joe's home directory on the server. On the laptop you would open up a terminal and type:

scp file1.txt server:file1.txt

Basically, it's the same convention as with cp - you enter the command name, and then the first argument is the name of the file you're copying, and the second argument is the destination. Technically, the destination is the fully qualified file name (with the full path prepended to it), so you would really type server:/home/joe/file1.txt (and of course you can use the ~ character instead of /home/joe).

That will copy file1.txt from the laptop over to the server, using scp, which is basically secure copy over SSH.

 

That's fairly easy and straightforward, but what I would encourage you to check into and adopt is the concept of public and private keys with SSH. There is a lot of information out there about the whole idea of cryptography using public and private keys, so I won't get into it in very much detail. Basically, you create a private key and a public key that kind of fit together and work together to "unlock the secret" (unlock the e-mail in the case of GPG or unlock the connection in the case of SSH). It's a way to make a connection without using passwords and it will only work if you have both the private and the public key together - they have to fit together and you can't figure out the private key from having the public key. The public key is supposed to be out there, given away, put on other machines, given to other users (in the case of GPG) etc... and you keep the private key to yourself.

 

The idea of using public and private keys is really great because it does 2 things.

One is that it's more secure than using a password, simply because passwords can be compromised more easily than you can imagine, unless you are really good at remembering a really long random alphanumeric password. Public and private keys really can't be compromised. I'm sure theoretically of course anything is crackable, but in practice, these types of public and private keys have not yet been cracked, so it's very, very secure, much more secure than using passwords.

The other benefit of using public and private keys is that it makes the SSH connection completely seamless. In our previous example, we had to enter joe's password on the server machine, but with keys you don't need to enter passwords. To accomplish that, and supposing we are logging in as another user (different from the one we are logged in as on the client side), we are going to create a key pair on the client machine. In the terminal, we would type:

ssh-keygen -t rsa

This will create 2 files in the .ssh directory: id_rsa and id_rsa.pub, with id_rsa.pub obviously being the public key.

So now that we have both the private and the public key on the laptop, the idea is that we need to get that public key over onto the server somehow, because when we connect to the server, we will have the private key on the laptop and the public key on the server, the two will match together, and our session will be authenticated, and we can come right in without any password.

It is very easy to copy a key over: you go into the .ssh directory on the laptop, and you type:

scp id_rsa.pub server:/home/joe/.ssh/.

and that would just copy the file over to the server.

And there is still another step.

You now need to ssh into the server and cd to the .ssh directory:

ssh joe@servercd .ssh

... and so joe is in the hidden .ssh directory, where that id_rsa.pub file now resides. Look for a file called authorized_keys, and if it's not there, type the following:

touch authorized_keys

That authorized_keys file is going to contain all the public keys of the users who are connecting to the server, but now there is nothing in it yet, so type the following:

cat id_rsa.pub >> authorized_keys

and what this command is doing is it's taking the contents of the id_rsa.pub file and appending it to the bottom of the authorized_keys file.

Make absolutely sure that you use two "greater-than" signs - you don't want to overwrite the contents of the authorized_keys file, should any keys have previously been stored in it.

At this point, joe should be able to open up a new terminal and type:

ssh joe@server

and he should be logged in right away without having to enter any password.

 

Because it doesn't ask for any passwords, this is actually very handy because it opens up a whole new world of possibilities for securely automating administrative stuff. You can kind of see now some of the things you can do with it: scripts that do automated backups over SSH, business application interface file transfers ... there are all different kinds of things that can be done when you have these public and private keys.

 

But obviously the important thing is that you don't want to lose your private key that is stored on the laptop - that is the real bottom line security issue.

 

That, in a nutshell, is basically the way to use ssh with public and private keys. I will describe the configuration and security stuff further down below, but there is one little neat trick with ssh - one of the other switches for the ssh command is "-D", and that stands for "dynamic". What that does is that, if you put a port number after it, it will let you sort of tunnel an SSH connection to a local port. It specifies a local "dynamic" application-level port forwarding. You can use it as a web proxy. An example of this is the following:

ssh joe@server -D 8080

from a terminal on the laptop, and you're connected. Now, what you can do with a browser like FireFox or Konqueror is you can go into the advanced preferences in the section where you have the option to manually set the proxy server, go down to the SOCKS proxy configuration line, and in the first box enter localhost, and then in the port box enter 8080, and then confirm / save it.

The next time FireFox is going out to browse a web page, it is going to be tunneling its web browsing through SSH. You can actually verify this with one of those sites that shows you your IP address, like http://www.ipchicken.com/ ... what I've done is I've opened up FireFox, gone to ipchicken, looked at my IP address, then I've done this ssh thing with the "-D 8080" option, changed the proxy settings in the browser, refreshed the ipchicken page and my IP address had changed, because I'm now browsing through the server, through the remote machine. It's very handy if you're in places like hotspots, where you may be concerned about people sniffing or whatever is being tracked through your web browsing - you can just connect to another machine over SSH and pull down this dynamic port to your local machine on 8080, change your browser's proxy settings, after which your browsing will go through your encrypted SSH session - very slick. There is a FireFox extension called SwitchProxy ( http://forums.xisto.com/no_longer_exists/ ) which lets you create "proxy profiles" so you can have one without this SOCKS setting, for just normal browsing when you're at home and you're not worried about invasion of privacy, and then one with the 8080 proxy SOCKS setting for when you're wanting to do this SSH tunneling thing.

 

Some basic security things with SSH that I would recommend:

One thing I would do is go into the /etc/ssh directory and then open up for editing the sshd_config file (again, this is the configuration file for the SSH daemon), so this would be on the server machine, not the laptop, because you want to make the security changes on the machine that is going to be offering up SSH. The first thing you want to do is change the default port from its default of 22 - that's very simple to do.

It's amazing - someone I know had a web server and they had the SSH listening port set to 22 for one single day before he got around to changing the default port (he had everything set up with passwords so he wasn't worried about anyone actually getting in) but at the end of that day he was checking the logs with LogWatch, which is a great little utility that parses through your system logs and you can set it up to e-mail you a daily log of everything that had been going on with the server, and it listed all the SSH attempts, and he said it must have been like a thousand in that one single day, and it was all of course script kiddie scripts and bots, but it was amazing because it was showing you the attempted user names, and it just went through the alphabet, but it's pretty frightening actually that they would try all these different random names that were in this script and see what works and I guess that if they find one that connects, then they'll just start doing a dictionary attack on the passwords.

 

So, anyway, what I would do is definitely change the default port from 22 to just some random port number - pick a high number (you know, 11500 or something), and of course, whatever port you end up using, if you are going to connect from the outside world to your machine, don't forget about your firewall and your NAT router. You will need to set up a port forwarding rule to forward whatever port it is to the machine that's going to be serving up the SSH server (just like with any service that you've got running behind your firewall, if you want to get to it from the outside, you have to forward that port to that machine).

 

A couple of other tweaks to the sshd_config file:

I would change the protocol from 2,1 to just 2 - that's because SSH protocol 1 is slightly less secure. Most things that I've come across suggest changing that to 2 only.

I would also disable root logins (you will see a line in there somewhere that needs to be set to

PermitRootLogin   no

it's usually either set to yes or the line is commented out, which also gives it a default meaning of yes). And if it's yes, it means the root account on the server could ssh in - you don't want to do that, just from a security standpoint. You want to limit it to just regular users, and then, once you've connected in through ssh, if you need to do something that requires root privileges, just su to root or do the sudo thing - that way someone would have to get through two levels to get to a root level of authorization, they would have to go through SSH with a regular user, and they would also have to know your root password. So disabling root logins is a good idea.

The last thing I want to mention is somewhat dangerous. Once you get your public and private keys set up, if you want, look through this sshd_config file and you will see a couple of lines in there about disabling passwords entirely - meaning it will only look for keys. SSH by default will first look for public-private key combinations, and then it will ask you for passwords, if it doesn't find the keys. So you can set it up to just take keys only, and that's pretty secure because using a public-private key combination is better than using a password, but that also means that if you lose your private key you can't get in (at least remotely) - you would have to go sit in front of the server and log on from the physical console and change it back to allow passwords to be able to ssh in. But that's an option to keep in mind.

 

That, in a nutshell, is SSH. There is a lot more you can do with it. You can for example forward X sessions, meaning you can run graphical applications over SSH.

 

If you're using Windows and need to SSH into a Linux / UNIX box, your first option is to use the command line tool ssh.exe that comes with cygwin, as a second option look for an open source program called PuTTY, which is a full-blown SSH client with the ability to create key pairs, and it can also deal with pre-existing pairs.

I really hate it when I see people using SSH as a SOCKS proxy like this without telling people that tunneling TCP over TCP is a bad idea. You have 2 layers on top of each other which both provide their own error correction and message integrity, and this can lead to all sorts of problems, and will cause cumulative degradation of the link's bandwidth if the link is anything less than perfect (i.e., over a wireless network where packets CAN be lost).

 

The -D flag to ssh is at best a temporary fix for not having one's VPN working while they fix it, but should NEVER be relied upon to tunnel any substantial amount of data.

I don't think using ssh is going to be easy for most people (which are accustomed to Windows). Usually, I just recommend VNC.xboxrulz