(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

November 7, 2018 Comments closed

Secure Shell: What is SSH?

in Everything Encryption

Secure Shell or SSH is an encryption protocol for securing remote CLI shell access

Recently, a co-worker or two overheard another colleague and myself talking about SSH (Secure Shell) and SSH’ing into one of our new servers. Surely, there was some confusion as here was another IT related acronym is being thrown about. Here we are, weeks, maybe months later (time is hard to keep track of) and I have been asked to elaborate on this topic a little further and answer the question: what is SSH?

So, here is my ode to Secure Shell for those that are unaware of SSH (It will not be any kind of artistic prose.) Many outside of the technology world may not realize how oft-utilized and important SSH and, indeed, shelling is in our everyday technological lives. This article will examine SSH and shelling, in general, and go over some of the technical aspects that encompass SSH and secure shell.

What is a Shell?

You probably know what a shell is. They protect turtles, snails, crabs, etc. from things that may desire their tasty insides. The dastardly spiked blue shell can be thrown to completely mix up the finishing places on the last lap. Or, in the case of candy, they may enhance the flavor of the tasty insides.

So, if you make the logical connection that a shell is a covering of something in the computer world, you would not be too far off. In terms of computers and software, a shell is a user interface for the offerings of an operating system (though the exact definition is certainly up for debate, I think it really is just semantics at that point). Operating systems are meant to harmonize and control all the different parts of a computer so that it can  facilitate all the different functions and software we so require for them.

In fact, you likely have interactions with a shell daily: the nice graphical interface we use to control our computers, phones, tablets, etc. is a type of shell. This includes OSes like Windows 10, iOS 12, Android 8.0 Oreo, etc. At a high level, you could break an operating system into 2 parts: The user interface part that we are all familiar with and the tasty insides of the underlying operating system framework that is doing all the behind-the-scenes heavy lifting we take for granted. The interfaces are designed to be very user friendly (regardless of the fact many of us struggle with them daily). Believe me, you may have your qualms with Windows or Apple, but it is a lot more intuitive than if we had to live on the other highly utilized kind of shell: The Command Line Interface (CLI).

Some people love CLIs (and cling to their direct interaction with a computer as a bulwark to confronting the interminable loneliness of their personal lives) and some (well-adjusted) people are scared by it. Many things can be only done natively in CLIs. Most operating systems offer a Graphical User Interface (GUI, pronounced gooey, c’mon, you know that, also, this is one of the few times a gooey shell is a good thing—normally it just means you stepped on a turtle).

All operating systems (that I am aware of) also offer some sort of CLI.

Windows has DOS and Powershell. Linux is a generic term for a GUI version of Unix (generic because there are so many “flavors” of Linux/Unix – but only one flavor for its mercurial creator, Linus Torvalds: Salty). I grew accustomed to Bourne Again Shell, or BASH, as my preferred shell in a Unix system—it started a little rough but after it found God it really turned things around. It is commonly used and rather effective for my needs but there are other options that can be made available, including but not limited to:

• Ksh – Korn Shell
• Zsh – Z Shell
• Fish – Friendly Interactive Shell
• Tcsh – Has syntax similar to the programming language C

An important thing to consider is that not all computers have a GUI. In fact, I would argue that many servers do not have GUIs. Why? Consider what a server might do. Servers serve clients. The client/server relationship is utilized everyday by a lot of people: online banking, Facebook, FortNite, etc. In the most common sense scenario, servers take in data from a client machine, process it, and return information back to the client. Servers might require interactions to adjust settings, update data or general housekeeping (clearing caches, pruning unused/unneeded data) but generally, a user is not spending a lot of time on a server once it is in production.

So, GUIs are not often needed as they may take up system resources and cause unnecessary overhead. That’s not to say GUIs are never needed for servers but most things can be done with automated processes, shell scripting or someone running manual shell commands.

Yeah, Shells, Very Interesting. So, What’s SSH?

Sometimes, we keep our servers local. We can plug in a keyboard, mouse and monitor and control the server, as needed. More effectively and far more commonly these days, a lot of our servers live in a colo (co-location facility where many, many servers are hosted in an appropriate environment with cooling, throughput of data, physical security, etc.) or servers are virtualized like in Amazon Web Services or Microsoft Azure. So, without physical access to get to a shell, we can use Secure Shell.

SSH uses an encrypted network connection to connect to a server and allows the user to run shell commands to a server remotely as if they were sitting right in front of it. It is a step up from something called Telnet which essentially does the same thing but does not use an encrypted connection. Telnet comes through as plaintext. Telnet would be the HTTP to SSH’s HTTPS in this analogy. It is mostly deprecated this day and age.

Now, when I say server, let me clarify something: Any computer can be SSH’d to so long as an SSH server instance is running on that machine. Most server OSes have an SSH server instance at least installed on them that might just need to be activated with a few settings. But, even your home computer could technically run an SSH server and be accessed via a secure shell client (assuming other security processes, such as firewalls or anti-viruses allow the connection to be made).

How Can I SSH?

So, a server running the SSH server instance can have a client machine connect to it. PuTTY is a common application that is used for SSH. I use it. Many do. SSH functionality can be configured into environmental variables and run through DOS/Powershell or SSH can be configured in macOS’s Terminal which I believe will use bash as its default but will support other shells. For this article, I will refer to PuTTY which is very simple and capable.

Key/Certificate Based Generation and Authentication

Before we get started on setting up the ends of a secure shell session, let’s take a look at key generation for users that  provides authentication and adds a YUUUUUUGE layer of security for the session. Most know that a key pair includes a public key and a private key. A user would have a private key that is theirs and only for them and they have an accompanying public key that is available to everyone else. In the usage of SSH, the public key would sit on the server, in a subfolder of the user profile and the user would have the accompanying private key. The user would use the private key to login thus eliminating the need for the user password. The server is basically saying, “I’m the gatekeeper. Only the keymaster can have access. Are you the keymaster?”

And, if a user has the key, they are basically saying, “I am Vinz, Vinz Clortho, Keymaster of Gozer. Volguus Zildrohar, Lord of the Sebouillia.”

There are many ways to create a key pair for such use. Ill go over 2 of those methods here:

First, with access to the server, whether physically or through a different user, the SSH key pair can be generated right on the server itself. Here is an image (with commands) of what that generation looks like:

• The command to start off the generation is:

  ssh-keygen -t rsa

  • Keep in mind that this is from the relevant user directory, in our example it’s: rthomas
• When it asks what file to save the keys under, it will default to the .ssh folder of the current user( where the public key should reside). Press ‘Enter’ to select that.
• The next 2 lines are for a passphrase. I would recommend using a passphrase as an extra layer of security, but it certainly is up to the user.
• Once we browse to the user’s .ssh directory, we can see the two files. The one without an extension if the private key. It is best to keep that on a local machine and remove it from the server.

Second, as I mentioned earlier, PuTTY is one of the most popular standalone applications that is used for SSH. There often is an accompanying (I love this word today, apparently) software that will create a public/private key pair. It is called PuTTYGen. Here is what it looks like launched:

By selecting the generate button, the application will actually ask you to move your mouse randomly across the large grey space above that button. Kind of like a game. Those movements are used to generate the key pair.

From there, you have the option to add a passphrase (highly recommended) and then the option to save the private and public key:

Then, like the previous method, you would need to save the public key in the .ssh folder of the intended user on the server. You could FTP, SCP (link WinSCP article here) or try and copy and paste the public file to a new file on the server.

Server-Side Setup

This section could go a number of directions. Let’s look at a generalized approach for service, authentication, and security of SSH.

As mentioned, SSH is meant to get to a CLI shell of a computer system. In a sense, you are a user of that system but from a “remote” location. So, it is important to know what user you will be SSH’ing as. Having user credentials is an important thing but you also need to know what the role and permissions of that user are, too.

The default port used for SSH is 22. It could be specified to be anything but just be careful about assigning the server-side SSH service a different port because assigning a well-known port to SSH could certainly screw up another service or process. Use the default port or, if needed, use a dynamic port. Still, I recommend using the well-known port of 22 and having user-authentication and firewall rules (for example, specify valid source IP addresses) to secure the system.

The IP address/hostname of the server also must be known. The server could be sitting in the public, and, therefore, have a public IP address. Alternatively, the server could be behind a firewall and call for the need of a VPN or something like port forwarding to connect to the system. A good practice is to  whitelist specific IP addresses that you know will be using SSH protocol and deny all other IP addresses from using SSH.

For example, in Amazon Web Services, there is a security group profile which is associated to a VPC (the network profile) which helps define firewall and routing services. The security group specifies these rules based on protocol and ports. See below for an example:

Checking the status on a Linux based machine can be done with 2 methods. It depends if you are using SysVInit or SystemD. The status can be checked with the following commands:

sudo systemctl status ssh

or

sudo /etc/init.d ssh status

On a Linux based machine, enabling SSH on startup so it is always on is a good way to make sure that you are able to connect even if there are outages or server upgrades. On newer versions of Linux that use SystemD (any new server likely will), to ensure that SSH runs upon reboot, the following command can be typed:

sudo systemctl enable ssh

Client-Side Setup

This section can also go a few ways but let’s move forward like we want to use the GUI to make the SSH connection. Again, PuTTY is a very popular and low overhead software and is quite useful/compatible on just about any platform that you might throw it on. The overall concept on the client-side is quite simple: configure the necessary parameters to SSH and save that profile if you expect multiple sessions across the life of the server and execute. Below is a screenshot of the initial window for PuTTY:

You can see there are a lot of options. However, most default settings will allow for a SSH session to be made. A few of the quick, necessary things are:

• The hostname or IP Address is necessary.
• The Port needs to be specified. Remember, port 22 is the default port.
• The authentication section is used for (private) key authentication. A previous section outlines how to generate the private key. Here is where you specify the location of the private key (ideally on the local machine).
• In the first PuTTY image, you can configure the profile and then save it for future use. You can select the profile and load it to recall those connection settings.

Another thing to note on the connection is that once you execute the session, the user will be prompted to provide authentication. The user entry prompt can be bypassed by prefixing the user to the destination SSH server in the format of user@SSHServerDomainOrIPAddress.

OK, I’m in. Now What?

Well, uh, first off: congrats.

Second: It depends on what you want to do…..

From here, you can go any direction. Need to setup a webserver with something like Apache? How about a blog with something like WordPress? It really depends on your situation. If you are new to this, and, I would assume you are because no experienced person would be unaware of how to SSH, then I would formulate a plan, for sure. You would likely need to learn some CLI commands to navigate around and perform whatever functions you might be interested in doing.

One additional piece of advice here: In Linux/Unix based systems, permissions play a huge part of doing just about anything. Just because one user/group has permissions to do something, don’t assume that other users/groups will have the same permissions. Lots of things can fail and get halted by permissions. In fact, I’ve learned that most problems that I come across, I always consider permissions first as that has been the culprit more often than not.

Consider this chmod tutorial about permissions and use the chart below for a quick reference:

As always, I would keep security in mind when SSH comes into play. Some of the safety practices mentioned in this article will ensure a safe connection so your secure shell sessions can yield some productive results.

We hope you learned something. And be safe and careful. Certain actions can break SSH and therefore, access to a machine, especially in a virtualized environment and then you would have to do a dreaded restore or mount to another server instance. Yikes.

As always, leave any questions or comments below…

---

Check out Ross’s Email Security Series:

• Email Security – Part 1: Certificate Signed Emails
• Email Security – Part 2: Phishing and Other Falseness
• Email Security – Part 3: Sender Policy Framework (SPF)
• Email Security – Part 4: DKIM (DomainKeys Identified Mail)
• Email Security – Part 5: DMARC, Reporting and Email
• Email Security – Bonus: S/Mime Certificates for Apple Users

• #Secure Shell
• #SSH