The Debian Series: Digesting the Secure Shell

In this opportunity, I’m here to explain how we can get to work with a pretty well-known tool for everybody, but mostly for software developers and computer-related people, the SSH or the Secure Shell.

There are a lot of things that an SSH terminal can do for our business, projects, and even for development workflows, including configurations, VCS setups, user management, deployment activities, and more, SSH is the main window for server management.

I will present to you a bunch of isolated concepts related to SSH basic usage, protocol interactions, securing practices, and more. But first, we need to give a custom but formal definition to it. An SSH is a console that helps you access computers and network equipment in an encrypted way, that’s it, there’s nothing more to add about. Of course, there’s a whole new world after it, the SSH is only a gate to it.

Background

In case the previous concept was not that self-explanatory. I’ll try to expand a little bit without going too deep into it. The SSH's main function is based on providing a way for remote management, with the premise of a secured encrypted connection.

SSH is a suite of tools, you also may encounter scp or sftp around. SSH can also be considered a network protocol, an evolution of the telnet that was insecure because it wasn’t able to handle encryption in its communications.

The SSH works on the port 22

Installation

Most of the Linux-based distributions already have the SSH installed, usually comes with the OpenSSH tool but can be some other installed. You can install related builds (from source code), pre-compiled software, or even download for the OS repositories with the help of apt or yum package managers.

On the other hand, the Windows systems support the SSH protocol but do not include any tool for it. You can check out Putty (it’s the popular one for Windows), but I’m pretty sure that OpenSSH have a solution for Windows OS as well.

From now on, I’ll talk only from the Linux-based perspective. I’m working on a Debian 9 machine, so, most of the concepts can be replicable to Windows machines, but some features or ways to interact with it may differ between Operating Systems.

With that said, let’s continue.

You can check the location with the command which ssh and the documentation with man ssh

Configuration

The SSH client works great with the default configuration for most of the users, but you can change it to achieve any particular goal. The SSH configuration file is on the/etc/ssh/sshd_config (for the server) and the /etc/ssh/ssh_config (for the client).

For the server side, the main things that you can configure are the service port number (PORT), the listening IP address (ListenAddress), the protocol version (Protocol) and the HostKey . There’s more in there of course, but everything is related to logging, authentication, and other features involved.

The SSH Client

To use the SSH Client, an SSH server must be installed and running on a remote server. Of course, the port 22 must be open, if remains defaults

Then, if you are using Windows (w/ Putty), open the program, and type the host, port, the software will attempt to connect, meanwhile, you will be prompted to accept and register your HostKey and after that, you will need to add your username and password. After that, a session will be completed and then you will be able to prompt any command you

For Debian (Linux-based) a shell is required, this process is more straightforward, you will need to type the following.

ssh <user>@<ip>

The process after is the same.

Authentication

Another way of performing a valid authentication SSHis by using the public or private keys from the SSH client. This is very useful for remote script executions because you can bypass the process of typing your user and password.

You can create the keys in your machine with the help of the ssh-keygen command. This process generates two keys, the private key that is stored on the machine and a public key that is transferred remotely to authenticate in the target machine.

So, this can be summarized in 4 main steps:

1. Generating the keys: ssh-keygen [options]
2. Copying the public key: scp id_rsa.pub root@IP:/home/david/id_rsa.pub
3. Sending the key for identifying remote machines (from the remote server) like: cat id_rsa.pub > .ssh/authorized_keys
4. Changing the /etc/hosts file with your IP, domain, and user

Avoiding Root access

Once the connection with theroot user is made, you will need to configure the service to avoid accessing with a root user. The root account must be protected and used whenever it is necessary, but not for daily usage.

You must use a normal (or different) user account and then elevate privileges when needed.

To avoid root access, you will need to configure the SSH server, specifically the /etc/ssh/sshd_config file and block the PermitRootLogin=no option.

After that, the service must be restarted. This is done like: service sshd restart

Remote connections tools

Previously, the telnet , ftp and the tftp were the traditional protocols for accessing machines remotely. A lot of people still use some of these services for maintaining old software, configuring CMSs, and not-so-old productive software.

The most common usage case is the final setup of WordPress CMS, a lot of people uses FTP clients to change the database credentials in the wp-config.php file, omitting that, ftp, along with telnet and tftp are insecure protocols, the information travels clear-text, without any encryption, making it susceptible to any attack based on traffic interception (Sniffing).

You can easily start a session with Wiresharkin a controlled environment and start sniffing the network traffic, when you authenticate using a telnet client or even when using FTP clientyou will see your auth credentials in clear text anywhere in the captured traffic (you can filter packets for FTP)

For that reason, the SSH came with a suite of tools that work exclusively with encrypted connections. The information travels without any possibility of being easily readable.

Then, a “new-born” concept of tools came along, these are the scp , the sftp and the sshfs . I said “new-born” because they are not-so-new, they have existed for a while now.

SCP

This tool is part of the SSH program, SCP and stands for Secure Copy protocol. It is a program that lets you copy files safely between local networks or to the internet with encrypted connections.

This service requires a user and password in the remote server to establish a connection. The basic limit of usage is that you need to know them system directory very well because the tool won’t let you “travel” across the directory tree easily, so this may be a little confusing if it’s your first case.

Here’s an example:

scp file.txt root@IP:/root/file.txt

SFTP

The name speaks for itself, is the secure version of the FTP. This tool lets you transfer and copy files remotely in a safe way. The cool thing is that this maintains a session to the remote server and lets you interact with the directory tree easily.

SFTP uses two commands to download (get) and upload files (put)

Here’s an example:

sftp root@192.168.1.12 (performing the connection)

sftp> ls (listing directory)

sftp> put file.txt (uploading a file to the server)

SSHFS

This tool is used for sharing files remotely, by mounting remote filesystems locally, just like Docker Volumes if you are familiar with the concept. SSHFS needs to be installed apart.

SSHFS is very easy to use, you just will need to create a directory that will act as the remote local directory, this will be visible on the remote machine as well, it's like a shared filesystem from both machines.

This is a simple folder mapping between local and remote folders, a client-server analogy.

Let me explain it from the start.

Let’s imagine we have a local directory called files with an anything.txt file in there, so we need to share that file, right?

You can easily start an sftp session and upload the file, but with SSHFS we are going to use the whole directory, so let’s share the folder

sshfs root@IP:/home/files/ home/david/Documents

The first part of the command refers to the remote server and the second directory is referencing the local machine

You can close and unmount the connection referring to the local machine directory like this:

fusermount -u /home/david/Documents

What about multiple SSH sessions?

In general terms, it's kinda tedious to open and close SSH connections in only one shell, there’s a lot of multiplexor terminals that can let you handle multiple shells (and possibly multiple connections) at a time.

And finally.

Securing SSH configurations and connections

SSH by default is a secure protocol, but it always can be better secured. There are a few things you can do to secure your SSH connections against your server or client. Let me list that for you.

Server-side: /etc/ssh/sshd_config

1. Change the default port, from 22 to whatever
2. Avoid root access
3. Disable SSH with protocol ver 1
4. Limit the user connections, sessions, and re-connection attempts.

Client-side /etc/ssh/ssh_config

1. Connect to the right port
2. Edit setting files for permanent settings
3. Use key-based authentication and safely handle the keys generated.

For both sides, you may need to restart the service.

That’s it.

Before I go, let me say that I am intentionally missing the SSH port forwarding and the X-forwarding (this is for opening GUI apps with SSH). Both are uncommon concepts that rarely can be seen around. If you are interested, doing simple research, is not a big deal.

This article is from my experience, if you see that something is wrong, feel free to complement it. Knowledge is free

Happy coding :)