Securing SSH sessions using public and private keys.

Paul BrownLeave a comment

It’s well known that passwords, regardless of how complex you make them, are the least desirable form of protection for any computer system. They are usually predictable or generated by ‘pseudo’ random generators. Those generators still follow a specific set of instructions to generate the passwords. Not to mention everyone gets pretty worn out with trying to come up with new and better passwords all of the time. Which is why it is inevitable to default to a password you are comfortable with. One that is tried and true and used for nearly everything you have…

So.. What can we do about that?

The complicated, and undoubtedly the most hated, is two-factor authentication. Often relying on a device in your pocket or being able to receive a text message, an email, or now a push notification to an app on your smart phone. While these methods really are more secure they are also overkill in some situations.

The other option is to generate a public and private key pair. This reduces the effort needed to access a remote system but also comes with it’s own inherent security risks.

What exactly is a public and private key pair? It is a set of files that are generated using a hashing function that produces a public key, for encrypting, and a private key, for decrypting. These two files can be used together to ensure that whatever is encrypted with the public key can only be decrypted with the private key to include an SSH session to another computer.

Think of your home and the lock and key for the front door. The lock contains the public key. It is something that everyone can see and can use to secure the house for you. However, once they engage the lock and close the door, yes.. assuming they actually leave the house, they cannot reopen. The lock now needs the private key to be opened again. It is important to note though, that just as a house key can be duplicated so can your private key. So make sure you keep your key safe.

So lets generate a key pair and see how to use them..

The most common way to do this is like this:

ssh-keygen

Yep. That’s all. Unless you want something more secure.. like this:

# Still using RSA which is the default, although it is being phased out
ssh-keygen -t rsa -b 4096

# Using ed25519 the hot new thing
ssh-keygen -t ed25519 

# If you add -a you can increase the strength of the hash
ssh-keygent -t ed25519 -a 50

These will produce a set of files name something like ‘id_rsa’ and ‘id_rsa.pub’ or ‘id_ed25519’ and ‘id_ed25519.pub’.

I’m thinking you can figure out which is public and which is private.

Now that we have the files you will need to place the public key on the host to which you will connect. Typically it should be place at /home/<user>/.ssh/id_ed25519.pub.

It is also recommended to use chmod 0600 id_ed25519.pub to ensure that the file is only readable by the intended user. Most of the time you will get an error if it is not set.

On the host you are connecting from you would place the private key in the same location. SSH knows to look there for both. If it is not there, that is ok. You can use ssh -i <path_to_file> to point it to the right place.

Once the files are placed you can now SSH and not have to use a password and it is a little more secure. This also works with sftp and scp. That is especially useful to automate file transfers. It is possible to reuse the key pair for multiple connections. Just be sure to keep your private key safe.

SSL Encrypted Traffic: Taking A Look Inside

ITChiefLeave a comment

First, what is SSL?

SSL stands for Secure Sockets Layer. It is a method of encryption commonly used with HTTP which is referred to as HTTPS. Almost every website now uses SSL for it’s connections, and if it doesn’t you may not want to visit it.

So, it is somewhat obvious, with it being a method of encryption as to why it is now preferred over HTTP. The not so obvious question though is; can everyone use HTTPS? The answer is yes. All it takes to establish a web server utilizing HTTPS is a certificate.

Certificates can be be created locally (self-signed) or purchased from a trusted third-party Certificate Authority (CA). These certificates can then be applied to the web-server and are used along with their public key to create an encrypted session. This is really a good thing; however, if you are an IT security professional, it causes a problem.

Typically in an organization you have hardware and software designed to protect your network. This technology lets you have visibility of everything going in and out. Prior to using HTTPS when the primary protocol was HTTP everything was in plain-text which made it very easy to inspect, for the good and bad guys. Now that it is all encrypted what do we do?

This is where SSL Inspection comes into play. Most modern security appliances offer the ability to intercept the HTTPS traffic and inspect it. So how does this work? Well, certificates are the key….literally. The security appliance uses its own set of certificates between itself and the client and the servers certificates between itself and the server.

The Pre-Inspection Inspection

The whole process summed up that way seems pretty straight-forward; however, there are some “gotchas.” The first one is that you must make sure that all certificates are validated and trusted. If there are invalid certificates then you open the door for some serious problems. The second, is that you need to know which clients you want to inspect traffic from so that you can install the public key of the security appliance. If your clients do not have a trusted relationship with the appliance no traffic will flow. Lastly, avoid self-signed certificates at all cost. Yes, it is easy and it is free, but the certificates are not publicly trusted and it only causes more trouble. Once your certificates are good to go you can move on to the inspection.

The Inspection

Looking at the image above it is clear that there are not too many steps involved. I will try to do my best to explain it in a bit more detail though.

Lets say you want to search Google for something. You enter the URL into your browser https://google.com and voila your there. What you did not see though was the verification that occurred between the client and server. When you hit enter the browser connected, but not to Google. Instead it connected to your security appliance. Since you should have already installed the public key for the appliance it created an encrypted session. The session was established using the public key to validate the servers private key, and a few other things. We don’t have to dive into that right now though.

But, wait why didn’t we connect to Google? Because the appliance needs the entire packet so it can decrypt it and analyze it. The data contains important data that identifies the application used. In this case it will also contain the exact URL that was requested. Once it has grabbed the data it re-encrypts it and sends it along via the session that it created with Google. With the network speeds we have you would almost never notice this. If you happened to do so, it would only be for a second and you would probably blame the IT guy anyway.