Secure Shell Fundamentals - Learn SSH By Configuring It

SSH

Installation - Lab Environment with VirtualBox

One way we can set up an entire lab to learn to use SSH in is by using virtualization software like VirtualBox.

VirtualBox is maintained by Oracle and it is free and available for Windows, Linux, and MAC OS X. That should cover anyone taking this course. You can download it at https://www.virtualbox.org.

Virtualization software lets you run an operating system within an operating system. The operating system you will run inside VirtualBox is called a Virtual Machine or VM.

You can download Ubuntu Linux Desktop or Server as an .iso image, then boot your VM to that, to install Ubuntu as a VM.

You can also put other Windows or Linux VM’s on VirtualBox.

You can set all of this up for free, so please give it a try.

You’ll see how to install VirtualBox on Windows and MAC OS X in the next lesson. The process is very similar for installing on Linux.

Don’t worry if you’ve never been exposed to virtualization before and this doesn’t make sense to you right now. You’ll understand as you proceed through the lessons.

Even if you plan to install directly to hardware, please consider learning VirtualBox as understanding virtualization can server you well in the future, whether you’re a home user or an IT professional.

Installing VirtualBox

In this course, you'll learn to connect to a remote Linux computer using SSH. The computer you'll connect to will be a Virtual Machine running on VirtualBox.

So what is VirtualBox? It’s free software that lets you run multiple operating systems within an application on your existing computer.

It’s available for Windows, MAC OS X, Linux, and Solaris. That covers any operating system you’re likely to be using.

Once you’ve tried a virtual environment, installing on hardware seems slow and painful.

Many server infrastructures are virtualized, running on VMware ESXi, Microsoft HyperV, or are in the cloud on Amazon Web Services, DigitalOcean, or a similar provider.

Taking a moment now to learn VirtualBox increases your options for trying new operating systems and practicing new things yourself, and can make using virtualization software at work more understandable.

The Operating System you install the downloaded VirtualBox software to is called the Host. The systems you install are virtual machines, or Guests.

Virtual machines are often abbreviated as VM’s.

So, let’s get VirtualBox installed.

Download the appropriate package for your operating system from https://virtualbox.org/wiki/downloads.

Once it’s downloaded, browse to the file. It will probably be in your Downloads folder, unless you typically download to another location or moved it.

I’m showing the steps for MAC OS X here, but it will be similar for other operating systems.

For MAC OS X, double click on the VirtualBox…dmg file to start the installation process.

Your MAC will verify the integrity of the downloaded file.

The VirtualBox installation window will open. Double click on VirtualBox.pkg. 

Your system will verify the integrity of the VirtualBox.pkg file.

A window will open asking you to run a program to determine if the software can be installed. Click on Continue to continue the installation.

In the Install Oracle VM VirtualBox window, click on Continue.

Enter your username and password if prompted and click Install Software.

If the installation was successful, click Close to close the installer window.

Under Number 2 in the VirtualBox window, double click the Applications folder to open it and browse to VirtualBox.

Double click on VirtualBox to launch it.

You can also launch it from Launchpad.

For Windows, double click the executable you downloaded and follow the default installation prompts. Then open it as you would any other application.

On a Windows install, consider right clicking the downloaded executable and installing it as Administrator. I haven't had it happen myself, but I had one student report grayed out permissions when he was trying to select a certain network setting. Installing as Administrator will minimize your chances of encountering this error.

You’ll see how to install new virtual machines and work with them in upcoming lessons

SSH

Installation - Downloading the ISO

The files you’ll need to install Ubuntu are commonly assembled into a package called an iso image. Iso images are packaged in a way that they would be if they were put onto an optical disk such as a CD or DVD.

ISO stands for the International Standards Organization. It’s the body that comes up with all kinds of standards including the file system format for optical disk images. That’s ISO 9660 in case you are remotely interested. It may also contain other files commonly used by DVDs and Blu-ray Discs.

The nice thing about an operating system that has been packaged in such a way is that you can boot to it and install an operating system from it.

Another nice thing about iso images is that they do not have to be put onto optical disks to be usable. You can fool your computer into believing it’s loading from an optical disk when it’s actually loading from the downloaded image file directly or from a USB device.

To download the image you’ll need, go to http://www.ubuntu.com/download/server.

Choose the latest Long Term Support (LTS) image. As I write this that is 18.04.1. For you it may be 18.04.something. If you’re downloading after 2020, it will be 20.04.something.

Keep track of where the file is downloaded and its name as you’ll need these in the installation lesson for your installation method of choice.

I strongly encourage you to try Ubuntu out as a virtual machine using VirtualBox which will be explained in a later lesson.

Clicking on Download started downloading the file ubuntu-18.04.1-live-server-amd64.iso. The image is fairly large, about 812 megabytes, so it may take quite a while to download depending on your Internet speed. Over an hour for my horrible Internet connection!

Be patient and let the download complete.

You’ll then have the iso file you’ll need for upcoming lessons.

More Information

ISO Image Files

https://en.wikipedia.org/wiki/ISO_image

Ubuntu Server Download

https://www.ubuntu.com/download/server

SSH

Ubuntu 18.04 LTS Server on VirtualBox

In this lesson, we’ll do an Ubuntu Server 18.04 installation on VirtualBox.

Ubuntu 18.04 is the latest version as of this lessons creation. It was released in April of 2018.

In the previous lesson, you downloaded the latest Ubuntu Server 18.04 Long Term Support (LTS) .iso file. In this lesson, you’ll use that to create the server virtual machine (vm) you’ll use throughout the course.

Open VirtualBox then click on New.

Create a name for your server, and select Linux for the Type and Ubuntu (64-bit) for the Version.

Click on Continue.

Leave the Memory size at default (1024 MB here) and click Continue.

Leave Create a virtual hard disk now selected and click Create.

Leave VDI (VirtualBox Disk Image) selected and click on Continue.

For Storage on physical hard disk, leave Dynamically allocated selected and click on Continue.

Click on Continue.

Leave File location and size at default, unless you have to store in another location, and click on Create.

Your Server VM is created and waiting for Ubuntu Server to be installed.

Right click on your new server and select Settings.

Click on Storage.

Under Controller: IDE click on the Empty CD/DVD icon.

To the right, next to IDE Secondary Master, click on the disc icon and select your disk image. If it doesn’t show up there, you’ll have to browse to it by clicking Choose Optical Disc file and finding your downloaded image.

If you didn’t already have it downloaded, you can pause here, download it from ubuntu.com/download, then continue.

Click on OK.

Double click on your Server VM to start it.

Keep English selected, or select your language by scrolling up or down using the arrow keys, then hit Enter.

Under Keyboard configuration, leave English selected, or select your language, then hit Enter.

Leave Install Ubuntu selected and hit Enter to continue.

Leave the network connections at default and hit Enter on Done.

Leave Proxy address blank and hit Enter on Done.

Leave Use An Entire Disk selected and hit Enter.

Leave the default value in Choose the disk to install to: and hit Enter to continue.

Leave Done selected for Filesystem setup and hit Enter to continue.

Hit the down arrow under Confirm destructive action to select Continue and hit Enter.

Enter your name, hit Tab, enter your server’s name, hit Tab, and continue down the form.

Be sure you enter your password, then enter the same password to confirm it during that step.

When you get to Done at the bottom of the form, hit Enter to continue.

Software installation will commence based on the settings you specified earlier.

Once installation completes, hit Enter with Reboot Now selected to reboot into your newly installed OS.

When the text finishes scrolling, hit Enter after Please remove the installation medium.

Login with the username and password you supplied earlier.

My first step upon installing a server is to update the server. Here’s a one-liner that will do that for you:

sudo apt update && sudo apt upgrade -y && sudo apt full-upgrade -y

You will be prompted for your password to run the command with sudo privileges which will be covered in greater detail later on the course.

You’ll usually have to remove old kernel versions after an initial update, so I run sudo apt autoremove if needed after updates.

Now you’re ready to learn how to configure and maintain your server!

Additional Resources

Official Ubuntu Server Guide

https://help.ubuntu.com/lts/serverguide/introduction-chap.html

SSH - Configuring Remote Access - Preparing Your Server

To use ssh to connect to your server, you’ll have to prepare it with three things.

• Make sure OpenSSH Server is installed

• Make sure you can connect over the network

• Make sure you have a firewall exception for ssh

We’ll cover each in this lesson.

Install OpenSSH Server

You can see if OpenSSH Server is installed by typing man sshd_config.

If you have OpenSSH Server installed normally, this will bring up the man page.

If not, you’ll get an error

No manual entry for sshd_config

If it’s already installed, go to the next step.

If not, type sudo apt update, then sudo apt install sshd-server, hitting y when prompted to install it.

Configure Networking

If you’re using VirtualBox to run your Ubuntu Server, you will probably have to make a small configuration change to be able to connect from the network.

I’m assuming you’re on a home network with some kind of wireless router/firewall protecting your computer from the Internet. 

It shouldn’t matter much either way, though, as long as your root account is disabled for login, and you have a strong password on your user account. Also, be sure your system is up to date by running sudo apt update, then sudo apt upgrade -y, and sudo apt full-upgrade -y.

Once your system is up to date, power it down. Right click on it and select Settings, then click on the Network tab. In the dropdown for Attached to:, select Bridged Adapter.

This will give your Virtual Machine its own IP address on your local network, which is the most straight forward way of being able to connect to it over your network.

Configure The ufw Firewall

Once both of those are set up, configure the ufw firewall. 

More is covered on ufw, and how it works in the Securing Ubuntu Server section, in the Enabling Your Firewall (ufw) lesson.

Here, we’ll do the bare minimum, preparing your server to accept connections on over SSH on TCP port 22.

To see the status of ufw, type sudo ufw status.

If this is a default installation, you’ll probably get the reply Status: inactive.

Allow incoming connections for SSH by typing

sudo ufw allow ssh

Allow outgoing traffic and deny incoming traffic that wasn’t requested by your server by typing

sudo ufw default deny incoming

sudo ufw default allow outgoing

Enable the firewall by typing sudo ufw enable.

Ensure that it’s running by typing sudo ufw status again. This time, it should tell you the firewall is enabled, and that port 22 is allowed.

You can get more information by typing sudo ufw status verbose.

Start OpenSSH Server

Now that you’ve installed OpenSSH Server on your Ubuntu Server, configured networking, and configured your firewall, you can start it with the following command:

sudo service ssh start

You can check the status by either typing:

sudo service ssh status

or

sudo netstat -tanup | grep ssh

Remote Access - Connecting With SSH

Now that we’ve set up SSH on the server, we can connect to it from any computer that can reach it over the network it is connected to.

If you’re running a virtual machine on VirtualBox, you can connect from your host computer (the one running VirtualBox).

I’ll cover connecting with iTerm2 for MAC OS X in this lesson, and we’ll cover connecting with PuTTY for Windows in an upcoming lesson.

iTerm2 

iTerm2 for MAC OS X is free to install, but isn’t available in the App Store. Just browse to iterm2.com, click on Download, and double click the downloaded app once the download is complete.

Finding Your IP Address

You’ll have to know your server’s IP address to be able to connect to it.

The command to learn the IP address is

ip addr | grep inet

You can see several IP addresses listed.

127.0.0.1 is a reserved IP address for a special internal network adapter called a loopback adapter. It is used to allow network communication internally on your server.

The lines that say inet6 refer to IP version 6 addresses, which we’re not interested in right now.

The one that says inet and starts with a 192., a 172., or a 10., is likely the one you’re after. If you’re on a home or work network, it will likely be one of those. If your computer is directly connected to the Internet, it could be different.

Mine is 192.168.254.105.

Connecting With SSH

Open iTerm2, and type ssh <user>@<ip-address>

For me, the command is

ssh theo@192.168.254.105

You’ll be prompted for your password, so enter it.

And you’re in!

Now, you can do anything you could do at the command line on the console.

Well, almost anything.

Bear in mind, when you’re making changes to your networking configuration, your SSH configuration, or your firewall, they can affect you, since you’re connected over the network.

This is no big deal, if you’re working on a system where you have direct and easy access to a console, but can be a bit of a pain if the server is across the country or in the cloud somewhere.

When making changes to any of those items, keep your existing terminal session up, if possible, and test with a new connection, before you disconnect your original session.

Some changes, such as a mistake in your firewall configuration, could kill your remote session.

In that case, you’ll have to have console access, or think of another way in.

Also, this lesson only covered connecting with username and password, which isn't nearly as secure as key based authentication, which we'll cover in upcoming lessons.

Remote Access - PuTTY for Windows

In order to connect to your server over SSH, you’ll have to use a terminal emulation program. It’s a program that’s designed to act like you’re sitting at a terminal typing commands.

For Windows, I recommend PuTTY. It comes with another utility called PuTTYgen we’ll use in a later lesson, so please download both, or just download the entire PuTTY software suite.

PuTTY Download 

Browse to putty.org and click on the link that says “You can download PuTTY here.”

Under Package files, click on the link for 64-bit MSI(‘Windows Installer’).

Once putty has downloaded, double-click on the .msi file to install the PuTTY Suite.

Connecting

 Double-click on PuTTY to start the program.

Obtain the IP Address from your Ubuntu Server.

The command to do that, again is

ip addr | grep inet

Type the IP address into the Host Name or IP address dialogue box.

If you’re going to be connecting to your server often, and you likely will, put a name in under Saved Sessions, and click on Save to the right.

Then, when you want to connect in the future, you can just double click on the saved session to connect.

I usually just make the name of the session the same as the name of the server.

SSH Fundamentals - Birds Eye View!

In this lesson, we’ll explore navigating the Ubuntu Server command line and using the help system.

I chose to start with a few commands and the help system, because you need that understanding to do much of anything in Linux Server.

That little blinking cursor waiting for input, with no visible help of any kind can be intimidating!

Have no fear.

You’ll be hopping around and entering commands in no time.

Most Used Commands

There are a few commands you’ll use over and over in a given day of Ubuntu Server administration. We’ll cover the top ones, as well as have a look at the help system that’s always available to you.

pwd

How do you know where you are in Ubuntu?

If you have your prompt set at default, the working directory is part of your prompt.

That’s changeable though. Also, if you’re several levels deep in the directory structure, it can become truncated.

To know where you are at any given time in Linux, you can type pwd for print working directory.

ls

If you want to see what’s in a directory, type ls, for list directory contents.

ls and some common options will be covered more shortly.

cd

To move from the directory you’re in to another, you use the cd command, for change directory.

Practice

For practice with the three commands you’ve learned so far, do the following:

• Change directory to /etc

  • cd /etc

• List the contents of the /etc directory

  • ls (ls with nothing entered after it will list the content of the present directory)

• Print your working directory

  • pwd

Help

Well, look at that! Just three commands, and you can see where you are on the system, change to different directories, and list files.

What if, though, you wanted to see something other than what’s available by just typing ls in a directory?

For example, if you have many files listed, and aren’t sure what one you want, but you know the date it was created, how could you see that?

There are two types of help in Ubuntu that can assist you.

Linux Help

One is the —help system. (that’s two dashes or minus signs together).

Type ls —help and hit Enter.

From here on, I won’t say to hit Enter unless it’s unclear when you should do so. It will be implied.

Wow, the help scrolls by pretty quickly.

We’ll cover redirecting output with the pipe | in a later lesson. For now though, type ls —help | less.

This sends the output to a command called less, letting you scroll up and down to read the content.

When you enter a command in Linux, it can often be followed by an additional option that makes it behave differently.

These can be referred to as options, switches, or arguments.

Scrolling up a ways, you can see the -l (lower case l) option. It says it will display a long list format.

Hit q to quit using the less command.

Back at the prompt, type ls -l.

Now, you can see many fields, including the date the file was created.

Manual, or man pages

Linux’s —help system is unique to Linux, and may not be available on all Unix-like operating systems, and may not be available for all commands.

The more universally accepted way to find help in Linux is with the man pages.

Think of it as a huge stack of documentation, organized and made available to you by typing a quick command.

Type man ls.

The output is also a help system, but it’s formatted a little differently.

There’s the Name and what it does

A Synopsis telling you you could type ls options and a file name. The items in square brackets are optional.

and a Description with a sentence then a list of the options.

With some commands, like ls, there can be a huge number of options, so you may have to scroll around a bit to find the one you’re interested in.

You may also come across some you hadn’t though of that can be very useful.

When you’re done, you can type q to quit the man page.

So, now you know some commands to get you started, pwd, cd, and ls, and two ways to get help in Linux.

More Practice

Check out the man pages and help systems for the commands used in this lesson. What did you find when you tried to bring up the man page for the cd command? How about when you used —help?

Next, we’ll gain some understanding of what a shell is and what some more abut the BASH shell.

Shells and the BASH Shell

In this lesson, we’ll look at what Shells are, what the BASH shell is, and why they’re important.

The Linux Shell

You have to interact with the system somehow, and the Shell in Linux is the most common way to do that.

The Shell is a special program that is you interface to the kernel. It lets you type commands in, and have them interpreted and executed by the kernel or the operating system.

There have been many shells developed in the years since Unix was invented.

We’ll look at some of the main ones now.

shell

Ken Thompson developed the first Shell, called the V5 shell in 1971.

It had functionality we would recognize, but lacked some features we consider basic today, like command completion.

It was intentionally minimalistic to keep it small. Resources, like memory and drive space, were scarce in the beginning.

Bourne shell

The next major Shell developed was the Bourne shell, released in 1977, by Stephen Bourne.

The Bourne shell let programmers and administrators use many of the standard programming constructs in use, including control flows, loops, and variables. This means scripts could become much more powerful and could act like, and call actual programs.

There are many other shells including the Korn Shell (ksh), by David Korn, the tcsh for TENEX C shell, by Ken Greer, developed in 1975, and merged into the C shell in 1981, and the  Bourne Again Shell or BASH, which will be the focus of the rest of this lesson.

One of the goals of the BASH shell was to grab much of the useful functionality of the other shells and wrap them in to one “super shell”.

Unless you’re using a system that doesn’t have BASH, I know of no reason not to use it.

Behind the Scenes

So, what happens when you type a command, like ls into the shell?

When you hit Enter, your the Operating System searches for it in several places, and if it is found, executes the command.

It will start with the functionality the command invokes, then look for any options and arguments, as applicable for the command.

When you type ls, the system looks up the command, finding it in the /bin folder, and runs it.

You can see the places the system finds a command using the which BASH command.

If you type which ls, you’ll see that ls is found in /bin.

The same process is used for any command you type.

We’ll go much more into the possibilities in the following lessons.

Introduction - Man Pages

Since the man pages are on almost every Linux system, and they’re a well established, authoritative source of help and information, we’ll be having a closer look at them in this lesson.

man’s man page

A logical place to learn more about the manual system is the man page for man.

man man

We see the standard breakdown of a man page, with NAME, SYNOPSIS, DESCRIPTION, and OPTIONS.

There is also an OVERVIEW, and DEFAULTS section for man’s man page.

Manual Sections

Although it’s normally transparent to you, because you’ll likely just type man and the command you’re interested in, behind the scenes, there are sections to the manual.

Sometimes, a command is found in multiple sections, and you may want the man page entry for a particular section.

The sections are broken down as follows:

1   Executable programs or shell commands

2   System calls (functions provided by the kernel)

3   Library calls (functions within program libraries)

4   Special files (usually found in /dev)

5   File formats and conventions eg /etc/passwd

6   Games

7   Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7)

8   System administration commands (usually only for root)

9   Kernel routines [Non standard]

Most often, just typing man and the command you’re interested in will provide what you want. 

If you’re a developer creating some lower level interactions with the system, you may want the man page entry from section 3, Library calls, or section 9, Kernel routines.

Most, if not all of what we’re going to be doing in this course will come from section 1, Executable programs or shell commands.

If you’re curious to see what sections a command may be found in, you can type

man -a <command>

and you’ll be taken to each of the sections it is in.

man -a passwd

--Man-- next: passwd(1ssl) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]

--Man-- next: passwd(5) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]

Before each of the lines above was shown, you would have been taken to the respective man page entry for that section.

If you do want the man page entry from a particular section, when it is in multiple sections, you can just put the section number in parenthesis after the command.

Sections Within man Pages

Inside each man page, there are common sections defined:

NAME,  SYNOPSIS,  CONFIGURATION, DESCRIPTION, OPTIONS, EXIT STATUS, RETURN VALUE, ERRORS, ENVIRONMENT, FILES,  VERSIONS, CONFORMING TO, NOTES, BUGS, EXAMPLE, AUTHORS, and SEE ALSO.

Searching For a man Page

If you know part of the command you’re looking for, or what it relates to, you can search the man pages by using the -k option.

man -k group

Produces anything with the word group in the description.

man -k pass

Returns anything with the term pass in the description including passwd, if you had been looking for that but couldn’t remember if it was passwd or password you were hunting for.

man page Navigation

When you open a man page, it is displayed by a “pager” which is a program that shows you text one screen or “page” at a time, and lets you scroll forward or back, typically with the up and down arrows, and the page up, and page down keys to scroll more quickly.

You can also search within a man page by typing /<search term> where <search term> is the information you’re looking for.

Within the man page for ls, you can search for the term recursive to see what options you have for telling ls to search the directory you’re in plus subdirectories.

/recursive

Takes you to

-R, --recursive

       list subdirectories recursively

so, to do a recursive search, you can use the -R option or type —recursive. I favor the option that involves less typing, but you may want to spell things out sometimes for clarity.

apropos - An Alternative to -k

You can also search the man pages for an entry by using the apropos command (the results will be the same as what man -k <command> would return)

apropos passwd

Returns

chgpasswd (8)        - update group passwords in batch mode

chpasswd (8)         - update passwords in batch mode

gpasswd (1)          - administer /etc/group and /etc/gshadow

grub-mkpasswd-pbkdf2 (1) - generate hashed password for GRUB

mkpasswd (1)         - Overfeatured front end to crypt(3)

pam_localuser (8)    - require users to be listed in /etc/passwd

passwd (1)           - change user password

passwd (1ssl)        - compute password hashes

passwd (5)           - the password file

update-passwd (8)    - safely update /etc/passwd, /etc/shadow and /etc/group

Great work! Now you know how to understand and navigate the built in man pages.

The Super Special root User

In this lesson, we’ll look at what the root user is, why the root user is so special, and how to work with root permissions.

The root user

All Linux systems, and for that matter, Unix, and BSD systems, have a root user. The root has god-like power over your system. It can do ANYTHING!

If you’re doing good things, and not making any mistakes, that’s fine.

If, however, you make a critical error when you’re working as root, the consequences can be devastating to your server.

We’ll look at a simple command to illustrate the potential problems that can ensue if you make a mistake as root.

The rm command removes a file, or set of files, or set of files, and directories you specify.

rm removes files. With the -r option, it will remove the present directory and all sub-directories. With the -f option, it will force the deletion, even if it would otherwise have resulted in an error.

If you wanted to remove something from your home directory, and you were logged in as a regular user, you could have a situation like the following:

rm -rf /home/theo/somefile

due to a typo becomes

rm -rf / home/theo/somefile

You were in a hurry, and you somehow added a space after the / or root directory.

The shell understands rm -rf but it then sees / which it also understands and home/theo/somefile, which it sees as an argument it can’t interpret.

bash does exactly what it’s supposed to do, and starts deleting everything it can from /.

Since my privileges aren’t elevated, it will only be able to delete files I have the access to remove.

Not pleasant, but not catastrophic for the system as a whole.

What do you think happens if this is done as root?

Please watch the lesson to see.

The moral of the story is to make sure you work as a non-root user unless you have to elevate your privileges for some reason.

When you do have to, use the sudo command if it will get the job done.

Only on rare occaisions work as root, and do it by typing sudo su -, not by enabling login for the root account.

Also, be sure any critical systems are backed up!

Common Commands

In order to unleash the true power of Linux, you have to get comfortable working at the command line. 

In this lesson, we’ll learn some of the most common commands, so you’ll understand when you see them in future lessons, and you’ll be comfortable working with them on your own.

cat

cat stands for concatenate. To concatenate something is to link or chain parts together. cat streams or prints the output of whatever file you ask for to the Terminal.

To use cat, type cat followed by the file you want to look at:

head

head - Show’s the first several lines of the file you specify (10 lines by default).

tail

tail - Show’s the first several lines of the file you specify (10 lines by default). 

pwd

pwd - Print working directory. Shows your present location within the file system.

cd

cd - Change directory. Moves you from the directory you’re in to the one you specify.

ls

ls - List the files in the present directory.

find

find - Searches the file system for files or directories you specify.

locate

locate - Searches a database of the files on your system for a file you specify.

grep

grep - grep stands for global regular expression print. You tell grep what to search for and the directory or file to search, and it prints all of the lines that have a match.

more

more - Lets you pipe output from another command (like cat) into it so you can scroll around in it and look at things.

less

less - It was supposed to be an improved version of more, but now they’re quite similar. However, more does let you use your arrow keys to scroll, which I really like.

touch

touch - Although its intended purpose is to change the modification date of a file, it can also be used to quickly and easily create an empty file of the name you specify.

That’s a lot to take in in one lesson! Please practice each command, navigating around your Ubuntu system and looking at things.

If you don’t know where to start, /var/log is a good place. You’ll have to use sudo privileges to look at some of the files there.

Bear in mind, there are entire lessons coming up on some of these commands, like grep.

You don’t have to be expert with these yet. Just familiar.

BASH Shell Navigation

There are some small, but very helpful tools built into the BASH Shell. 

Whether you find yourself managing hundreds of Linux Servers or just running your personal blog on one, these few tools will save you quite a bit of time.

command history

When you type a command and hit Enter in BASH, the command you use is stored in the .bash_history file in your home directory.

This can be useful information, that can keep you from having to type a previous command you want to use again, or to help you jog your memory about how you did something.

To access this information, though, you don’t have to work with that file itself.

You can just hit the up arrow to see previous commands and the down arrow to scroll down in the command history.

This may not sound super useful, but trust me, it’s great. As you start using Linux more, you’ll understand the benefit.

tab completion

BASH will also try to figure out what you want to do and will complete commands, file names, and directory names for you.

If you type cat /var/log/au and hit tab, BASH will auto-complete auth.log for you.

If you have your computer sound enabled, you’ll hear a bonk kind of sound which indicates there are multiple possible completions, and it has shown you the first.

You can either hit Enter, to run with the file you have, or you can hit Tab again, to see the options available.

In my case, I hit Tab again and see that I have the following possibilities:

auth.log    auth.log.1

I can either hit Enter to see auth.log, or I can type a period, then hit Tab again to autocomplete to auth.log.1, which is an older log file created by log rotation.

Tab completion also works for changing directory.

If you type cd /var and hit tab, you’ll get the bonk sound. Hitting Tab again displays all of the sub directories in the /var directory.

If you go to a directory with a huge number of sub directories in it, you’ll get a warning asking you something like “256 results found. Do you want to display all 256?” You can type Y to display them all or N to refine your search further.

BASH asks because it is unwieldy to have a large number of options shown at once at the command line.

cd ../..

We already learned how to change directory. Here’s a short cut for changing directory upward from your current location.

Let’s cd into /etc/skel.

To go up one directory, we can just type cd ..

If you type ls -al in any directory, you’ll see, at the very top of the list “.”, then “..”. The . represents the current directory, and the .. represents the parent directory, or the directory that’s one level above your current location.

You can also string ../../.. together to go up several directories at once (you’ would go up three levels here).

Editing Text Files - Overview

As you learn to manage your server, you’ll find that you’ll often be editing text files.

Text files are the most common way to manage settings in Linux.

So, how do you edit a text file at the command line?

We’ll look at two methods.

vim - Vi IMproved

vi is a venerable text editor that has been around since the earliest versions of Linux, and before.

vim is a pure text editor, with no menus. This sounds like a disadvantage, but I hope you’ll come to see it as a great feature once you give vim a try.

I use vim exclusively in maintaining Linux systems.

You’ll learn the different modes of operating in vim, how to find, and edit text, and how to save your file.

nano

nano is a quasi-text editor, with a GUI-like menu available. I’m personally not a big fan, but I know many Linux admins I respect greatly like and use it.

Please give both a try, and get comfortable using whichever one you prefer.

There are also many people who use GNU Emacs, but I have never tried it.

Editing Text Files - vim

The first editor we’ll work with is vim.

There are literally whole books written on using vi and vim. I have the book “Learning the vi Editor, Sixth Edition” by Linda Lamb and Arnold Robbins, O’Reilly Press which, sadly, I’ve never completed.

We’ll hit on enough here to let you quickly and easily edit files with vim, and this is likely all you’ll need!

As mentioned in the previous lesson, vim stands for Vi IMproved. vi is an editor that you’ll find on almost any Linux, BSD, or Unix system. That makes it pretty universal.

If you want to edit a text file, you’re almost guaranteed to be able to use vi to do it.

The thing is, vi does not behave the way you would think it should. The up arrow may not work at all, or may not take you up a line in the file you’re editing. You use h, j, k, and l instead of arrow keys to move around.

vim is more user friendly in that regard.

vim is available on all Linux systems, although you may have to install it as a package on some. It’s in the default installation for Ubuntu Server.

vim - Vi IMproved

To use vim, you just type vim, then the file name of the file you want to open for editing. 

vim my-first-text-file.txt

If the file exists, you’ll be in it and ready to edit. If it doesn’t, it will be created and you’ll be able to edit it in vim.

Two Modes

vim has two modes of operation, Insert mode, and Command mode. 

When in Insert mode, you can write text into the file as you would in any text editor.

When in Command mode, you can efficiently navigate your document and manipulate text.

You enter Insert mode by typing the letter “i”. You leave Insert mode, going back to Command mode by hitting the “esc” key.

Insert mode

Once you open a file, you’ll be in Command mode. To be able to edit the file in the way you would in any text editor, you type “i” to enter Insert mode.

In Insert mode, you can use the arrow keys to go to the area you want to edit. You then hit the Del key to delete something that’s there now, or just type what you want inserted into the file.

To save your work, you hit the esc key to leave Insert mode, then type a colon “:” and type w then q to write your work to the file and quit.

Try editing a file using just what you learned above. 99% of the time, that’s all I need to edit a file.

Command mode

Command mode is where you do things like search within a file, or save and exit.

To search for text, hit esc to make sure you’re in Command mode, then type a forward slash “/“ followed by the text you want to search for.

If there are several instances of the word you’re searching for, you hit “n” for the next instance or “p” for the previous instance (searching forward with “n” and backward with “p”).

To save your work, as mentioned above, you hit esc to make sure you’re in Command mode, then type “:wq” to write and quit.

Typing “:q!” quits without saving, in case you change your mind about saving your edits.

Try editing some files with just these commands. 99% of the time, they’re enough.

If you want to get a bit more proficient, try the things below.

Command mode Advanced Usage

Here are some more advanced navigation techniques for those interested.

Using Letters Instead of Arrow Keys

In Command mode, you can navigate more quickly with some keyboard shortcuts.

Moving the Cursor

h, j, k, and l can be used instead of the arrow keys.

• h moves the cursor one character to the left.

• j moves the cursor down one line.

• k moves the cursor up one line.

• l moves the cursor one character to the right.

Remember though, the arrow keys function as you would expect, with right arrow moving to the right left to the left, up moving up one line, and down moving down one line. Holding a key moves multiple steps, like normal with arrow keys.

Moving to Different Words

Use w, b, and e to navigate to the start of the next word, the end of the word, or beginning of the word.

• w moves you to the next word.

• b moves you to the beginning of the previous word

• e moves you to the end of the current word

Beginning and End of Line

• o moves to the beginning of the line.

• $ moves to the end of the line.

Beginning and End of File

• G moves to the end of the file.

• gg moves to the beginning of the file.

Finding Your Last Edit

• `. moves to your last edit. That first character is a back-tick, usually located under the tilde “~”, above the Tab key on North American keyboards.

Putting a number before a command, will make that command repeat that number of times. To go ahead five words, you would type 5w.

Command Mode Editing

Learning a few editing commands for use in command mode can speed your editing up greatly.

Deleting, Undoing, and Redoing

• dd deletes the current line.

• dw deletes a word.

• do deletes to the beginning of a line.

• d$ deletes to the end of a line.

• dG deletes to the end of the file.

• u undoes the last operation (don’t we all need that from time to time!)

• Ctrl-r redoes the last thing you undid with u.

Searching and Replacing

/<text> searches for the thing specified in <text>.

n finds the next instance of the word searched for.

N moves the cursor to the previous instance.

?<text> searches upward in the file for the thing specified in <text>. 

:%s/<text>/<replacement text>/gc does a search for <text> through the entire document, replacing it with <replacement text>. It will ask you to confirm before replacing.

Those few commands are more than enough to do most tasks quickly, easily, and efficiently at the command line.

Please practice. 1/2 hour of playing and practicing can yield incredible results, and start you on your path to becoming a command line guru.

Editing Text Files - nano

Now, we’ll learn to work with nano.

Like vim, volumes could be and have been written about nano.

We’ll cover some basics to get you started.

nano - Nano’s ANOther editor

nano is also a text based editor, but it has a menu system to walk you through its commands.

It also makes use of hot keys, keys paired with the Ctrl key. Ctrl-G (pressing and holding Ctrl, then pressing G), for example, brings up the Help system for Nano.

Where you see M referenced in the menu and help files, it is referring to the Alt key.

Editing Text

Editing text in nano is super simple. Just open your file by typing nano <filename> and start moving around with the arrow keys, using delete to delete text, and typing in what you want to add.

Saving Changes

Ctrl-O writes your changes to the hard drive, and Ctrl-X exits.

nano Help

Ctrl-G or F1 accesses nano’s help system.

Searching For Text

Ctrl-W, or F6 for Where Is, will let you find text you specify.

Alt-W, or F16 for find next occurrence. (My F keys only go up to F12, so I’m not sure how I would use that).

Cutting And Moving A Line

Ctrl-K or F9 Cuts a line.

Ctrl-U or F10 Pastes a Line.

Wrapping Text

Alt-Shift-$ Enables word wrap. For lines that are very long, they won’t wrap by default.

Moving To Beginning Or End Of File

Alt-\or Alt-| Go to the beginning of the file.

Alt-/ or Alt-? Go to the end of the file.

Finding And Replacing Text

Ctrl-\

Type your search term          [press Enter]

Type your replacement term [press Enter]

A    - replace all instances, or be prompted at each instance found.

Editing System Files

Since you now know how to edit text files with vim and nano, I want to help you avoid some pain and suffering by showing you how you can keep the original of any system file you may edit, and subsequent versions as you modify it going forward.

The Pain of Experience

I wish I could tell you I read this somewhere, or learned it in a course as you are, but no. I modified a configuration file on an nginx (web) server and didn’t have the original or a previous version to fall back on.

If it were a simple edit or two, no big deal, but the editing was extensive, and having saved and exited, I couldn’t use the undo feature.

To get an original, you may be able to just copy from another server, or a clean build, provided it is running the same version of software, but this takes precious time.

You should also have backups of any production server, but again, restoring from backup or finding a file in backups takes time.

Simple Versioning

Short of using a full repository for your files, like git, how can you keep the original and versioned changes to your system files?

The solution is simple. Before you edit, make a copy!

Keeping Versions

If I wanted to edit /etc/ssh/sshd_config, for example, I’d first make a copy of it by typing sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.0. That would make a copy of the file in its original location with a .0 at the end. That tells me it is revision 0, or the original file.

If I want to make changes to the present copy of /etc/ssh/sshd_config, I don’t overwrite sshd_config.0, I create a new file, sshd_config.1, and so on for further revisions. 

If you find your directory getting cluttered, you could delete some of your older versions.

I always keep the original, and the latest change though.

Why The Extra Work?

If you edit a file, which you will do on your Ubuntu Server, you may later find that your edit creates some unforeseen issue and want to look back at what you changed.

If you edited the file, and don’t have a record of what you did, this can be a challenge.

If you don’t have the original, you can’t restore to that and start fresh.

If you do, you can use a program called diff to see what changed from the original, or if you have them, later versions, and the working copy.

How Does diff Work?

diff tells you what’s different between two (or more) files. I find the output confusing if used on more than two files, but it can be done.

You type diff <file1> <file 2>.

diff /etc/ssh/sshd_config.0 /etc/ssh/sshd_config

will show you the differences between the original copy of /etc/ssh/sshd_config (sshd_config.0 in this examplel) and the working or current version, /etc/ssh/sshd_config.

Armed with that information, you can troubleshoot more quickly by undoing your changes one at a time, or restoring to a previous version, and implementing the changes one at a time.

How To Restore?

To restore to a previous version, you just use the mv command.

mv moves a file, but if you move a file to an existing one, the existing one will be overwritten.

If you want to keep the present version, with the possible errors in it, for troubleshooting, just save it as the latest revision first.

Then, type mv /etc/ssh/sshd_config.0 /etc/ssh/sshd_config. Substitute .0 for the revision you want to restore to.

Please practice these steps as you go through the course, whenever we edit system files.

You’ll likely see me do it, and remind you, when applicable, both because it’s a habit for me, and because it’s a habit I want you to get into.

Remote Access - Key Based Authentication

Password authentication is OK, provided you create a strong, difficult to guess or crack password.

Here’s a weak, well known password, that provides zero protection:

P@ssw0rd

This is in the word list of many programs that try common passwords on systems they’re trying to break into.

Here’s a much stronger password:

R0deMicrophonesR#0ne!!!

That password is long enough and complex enough that it would be a real challenge for a password cracking program, if the proper encryption and hashing are used.

If you configure a maximum number of retries for SSH login, the default is 3 attempts for Ubuntu Server, the chances of someone correctly guessing the strong password above are near zero. The chance of it guessing the weak password are relatively good, as it is often used both by users, and by bad guys.

If you ever re-use your password(s) though, they can become compromised through breaches.

Compare both, of the passwords above to the following public key generated for key based authentication:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+D+LxaxTxMIY25V5IX/gbKEEWsYqrcSVZOv9Rr/xoHatuljwfsi0shQGHxKpfr2LOwBX5q4dt3/Bq18oXOeJmhVIAcnL/gKsMAw1GsnMNFPmwe1G3QrwV/ofxIrLGWlb6/vbBjZBmRmv/KLxyUcBbpsg8rGFobfLq15o3s4h/CAOYlr9OD8BO58DzW0nyEJvfNS/RAQ2Q6e8KH0+E91sxIU3bauDkSzEB6jh1u7drQEvB7OSuPZVA2jE3yGFi2U344gtq+BXlNc0kEQWAdLqi7L4MnAHLXWYWMNYylrzrMZlpR1VO3Kv9y6NxEYIOphGWiZxCd+44HxC+V1lVvpxH theo@Ubuntu-Remote

You can see, this is a practically uncrackable public key.

[NOTE] The public key I provided above was a disposable one for a temporary server. Even though it’s “public” you should not expose it unless you have to. 

It is OK to provide it to someone who wants to give you access to their server. It will not provide them access to your server.

To make things even more difficult for an attacker, that key is paired with a private key, and a mathematical operation is used that makes use of both keys for encrypting and decrypting traffic.

It’s a really, really good system for controlling access to your server.

It is worth the effort, and will become easy once you’re done it a few times.

Generating Your Keys

In order to use public key authentication, you’ll have to generate your keys. Linux provides a tool that makes the process easy called ssh-keygen. It works for Linux, BSD, and MAC OS X.

ssh-keygen will generate your public and private keys, store them in the default location, and let you set a password on your key, all in a few simple to follow steps.

I recommend setting a reasonable password (12 characters, using upper and lower case letters, numbers, and special characters), or a passphrase with those elements on your key.

That way, if someone is able to access your keys, they still can’t get on your server.

Protect your keys, especially your private key! If someone gets it, they can try to log in as you. The only thing that will save you is the password on your key at that point.

Here, I’m going to be on ubuntu-server, the server I’m using throughout most of the course, creating a key for use on Ubuntu-Remote, the server I’ve just configured for this lesson.

I’ll generate the keys on ubuntu-server, then copy them to Ubuntu-Remote.

The username will be theo on both servers.

Type ssh-keygen.

Accept the default location for the keys generated: /home/theo/.ssh/id_rsa by hitting Enter.

You’ll see that the directory /home/<username>/.ssh was created. That is the hidden directory where your keys will be stored.

You’ll get a key fingerprint, which you will not need, and an ascii art graphic showing you the randomness of the generated key.

This process will generate two files, id_rsa, your private key, do not ever give this out, and id_rsa.pub, your public key.

If you cat your public key, you’ll see a bunch of gibberish looking text like the output copied before.

Adding Your Public Key To The Remote Server

Now that you have your public key, you can add it to your new server by connecting over SSH. I recommend doing this over iTerm for MAC OS X, at the command line in Linux, or using PuTTY in Windows.

You can use the command ssh-copy-id to copy your ID to the new server.

ssh-copy-id <username>@ip_address

For my Virtual Machines, that will be:

ssh-copy-id theo@192.168.254.105

This creates the proper files and directories, if necessary, on the remote server, and puts your public key into them.

The .ssh folder will be created, if it doesn’t exist with 700 permissions, and the authorized_keys file will be created with 600 permissions.

SSH keys will not work if the permissions are not set up correctly on the file or the directory.

If you cat authorized_keys, in the .ssh folder, you’ll see your public key from the server you connected from.

If the authorized_keys file already exists, the new public key will be concatenated to the end of the file.

Why The Extra Security?

You may wonder, “Why would anyone attack my server? I have nothing valuable on it.”

Unfortunately, attackers likely don’t care who you are or what’s on your server. There are people and programs constantly scanning the Internet for vulnerabilities and automatically or through manual intervention, leveraging them to compromise systems.

I spun up a disposable server on DigitalOcean to illustrate this.

The server was up for 5 days. In that time, 1044 login attempts with invalid usernames were made.

This is a throw-away server with nothing anyone could want on it.

If nothing else, if it is compromised, it could be used to scan for and/or attack other resources.

Protect yourself with public key encryption.

In a future lesson, you’ll learn how to disable password authentication, so only key based authentication will be used. Until that is done, the system will fall back to password authentication if key based authentication fails. That’s not what we want.

Remote Access - Windows Key Based Authentication

In the last lesson, you learned how to set up key based authentication for Linux, and MAC OS X. In this lesson, we’ll learn how to configure it for Windows. 

We’ll also learn how to set key based authentication up manually, without the aid of ssh-copy-id.

We’ll start by adding a new user to our server and giving it sudo privileges.

adduser <username>

<password>

<password>

sudo usermod -aG <username> sudo

Test your remote access.

In PuTTY, enter <username>@<ip-address> in the Host Name (or IP address) text box. Save the session if you will be using it often.

Make sure you can use sudo permission with the new user.

sudo ls /root

Windows Keys

The things we have to do will be the same as we did with Linux, but the tools we use will be a bit different for Windows.

In a previous lesson, we downloaded a component of PuTTY called PuTTYGen.

PuTTYGen is a utility to generate public and private key pairs in Windows.

Either browse to it or just click on the start menu and type PuTTUGen. Click on it to open PuTTYGen.

Click on Generate to create your public and private key pair.

You’ll be asked to generate some randomness by moving your mouse around, so do that.

Click on Save public key, and accept the default name and location, then Save private key and do the same.

When prompted, enter and confirm the password your keys.

This password or passphrase will be used to encrypt the keys, so even if they’re stolen, they won’t be of use until the password is entered.

The public key will appear in a text box. Copy the key so you can paste it into the correct location on your Linux server.

If you forget to do that, you can do it using the Conversions tab later.

Adding The Key To Your Server

Now, SSH to your server by opening PuTTY and typing <username>@<ip-address> in the Host Name (or IP address) text box and clicking Open.

We’ll have to create the .ssh folder, add an authorized_keys file, and paste your public key into that file.

mkdir .ssh

chmod 700 .ssh

cd .ssh

touch authorized_keys

chmod 600 authorized_keys

You may be tempted to create the authorized_keys file using vim and paste your key into it. I recommend using the following method instead.

Being in the .ssh directory, type

echo “<public-key>” >> authorized_keys

Replacing <public-key> with the actual public key you copied earlier.

The reason I recommend this method instead of using vim or nano is that a single typo, even one you can’t see, in your authorized_keys file will break key based authentication. A text editor may insert something you can’t see easily, that will make your key not work.

Testing

Before you disconnect your remote session, test by opening a new PuTTY session. You’ll have to tell PuTTY to use your newly created key. 

It is best if you create a saved session at this point, if you haven’t already done so.

Click once on the session to select it, then click on SSH under Connection, then Auth.

You’ll see a section at the bottom of the window that says Private key file for authentication. Click on Browse and locate the private key you generated earlier.

Scroll back up in the Category window, click on Session, then click Save to save your changes.

Now, double-click on your saved session to open it.

You’ll be prompted for the password you assigned to your key.

Once you enter it, you should be in!

Be sure your sudo privileges work.

sudo ls /root

Troubleshooting

Because of the extra steps involved, you’re more likely to run into issues here than with the Linux process.

You can find helpful clues about why authentication may not be working in /var/log/auth.log on the server you’re trying to connect to.

You can either tail the log file, or grep for the username that’s having issues, and see what the log file says.

We’ll start with the basics, then work to more specific likely causes.

SSH Service

Type service ssh status. If the status says it is loaded, you’re good. If not, type sudo service ssh start.

Network

Type netstat -tanup | grep ssh.

You should get a line like the following:

tcp   0   0 0.0.0.0:22      0.0.0.0:*    LISTEN      1088/sshd

This means it is listening on all IP Address and it’s good.

ufw

Check the ufw status.

sudo ufw status

You should get output similar to the following:

Status: active

To                         Action      From

--                         ------      ----

22                         ALLOW       Anywhere

If not, type sudo ufw allow ssh and try again.

Permissions And File Content

If the service is started and listening, and ufw is configured correctly, there is likely a problem with permissions or the content of the authorized_keys file.

1. Permissions are not correct on the .ssh folder or the authorized_keys file

   1. Permissions on the .ssh folder must be 700

   2. Permissions on the authorized_keys file must be 600

2. There’s a typo in the name of the authorized_keys file. Make sure it is authorized_keys.

3. There’s a typo, possibly hidden, in the content of the authorized_keys file.

   1. Remove the contents by deleting everything in the file.

      1. echo “” > authorized_keys

   2. Re-do the command to paste your key into the file, ensuring that you’ve pasted it exactly as it was in the PuTTYGen output screen. If you no longer have that, you can use Import key under Conversions to open the public key.

If you’ve done all of the above, and you’re still having issues, please post a question in the course Question and Answer section, and one of your fellow students or I will try to help. You can also Google for help.

Configuring sshd_config on Ubuntu 20.04

I was updating my Ubuntu course from 18.04 to version 20.04 and found an intriguing new line in /etc/ssh/sshd_config.

Include /etc/ssh/sshd_config.d/*.conf

Looking at the man page for sshd_config, the SSH daemon, on starting, will now look for configuration settings in /etc/ssh/sshd_config.d/. The files should have any name ending in .conf. A possible name would be my_sshd_config.conf.

Why would I want to create a new, external file, instead of just editing the sshd_config file as I’ve always done?

From doing a quick search on the Internet regarding securing SSH, it looks like that’s exactly what most people are doing.

This new system introduces an opportunity though.

It follows the format for systemd unit files. I can now put my settings in a file in /etc/ssh/ sshd_config.d/ and they’ll persist even if /etc/ssh/sshd_config is overwritten as part of an upgrade to the OpenSSH version running on my server.

It will also supersede settings in the /etc/ssh/sshd_config file. For environments where a lot of people may be managing systems, it’s nice to know that someone tweaking a file in the wrong way will not compromise critical security settings for your SSH service.

So, how does it work?

In the /etc/ssh/sshd_config.d/ directory, create a new file. I’m naming mine 10-my-sshd- stuff.conf. You’ll have to do this with sudo privileges.

sudo vim /etc/ssh/sshd_config.d/10-my-sshd-stuff.conf

Inside that file, enter the keywords and arguments you want to change from default, or ensure are explicitly addressed. Note that keywords are case-insensitive and arguments are case-sensitive.

There are some configuration changes I pretty much always make for any publicly exposed server I’ll put inside the file.

• DebianBanner no

• DisableForwarding yes

• PermitRootLogin no

• IgnoreRhosts yes

• PasswordAuthentication no

• PermitEmptyPasswords no

  Caution! Be sure you have key based authentication set up and working before you set PasswordAuthentication to no!

  Content of my-sshd-stuff.conf file

  Be sure you understand the implications of the settings before applying them. Most are fairly innocuous, but setting PasswordAuthentication to no will lock you out of a remote system if you restart SSH and log out before testing. You’ll have to get back in through a console, then set up key based authentication.

  You can find my tutorial on setting up key based authentication here.

  Once you’re sure key based authentication is working, and your configuration file is the way you want it, restart SSH to make the settings take effect. There are a few ways you could accomplish this, but here’s one:

  sudo service ssh reload

  Reloading should not kill your active setting in case you’re in remotely and want to test with another connection before logging off.

  Thats it! Now you can manage all your SSH settings in one file and they won’t be clobbered when OpenSSH is updated.

In this lesson, we'll have a look at each line of our configuration file. We'll look at what the line sets, what the default is, and review why we set it this way in the file.

Further details on the settings that can be configured in this file can be found in the man pages by typing man sshd_config.

Here are the settings again:

DebianBanner no
DisableForwarding yes
PermitRootLogin no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no

Now we'll look at each line.

DebianBanner: Specifies whether the distribution-specified extra version suffix is included during initial protocol handshake.  The default is yes.

Information on what operating system is in use can be very helpful to attackers. This command will display slightly less information for people grabbing banners from SSH. Banner grabbing is looking at what information or what "banner" is returned from any connection attempt, successful or not.

We'll use nmap to see what is displayed when DebianBanner is set to yes, or default, then when it is set to no.

Here's what is displayed when DebianBanner is set to yes:

Theodores-MBP:~ tedl$ nmap -sV -p22 192.168.254.147
Starting Nmap 7.80 ( https://nmap.org ) at 2021-01-11 22:03 EST
Nmap scan report for ubuntu-20-40-server (192.168.254.147)
Host is up (0.0023s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds

Note that an attacker now knows we're running Ubuntu Linux.

Here's what it looks like when this setting is changed to no.

Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds
Theodores-MBP:~ tedl$ nmap -sV -p22 192.168.254.147
Starting Nmap 7.80 ( https://nmap.org ) at 2021-01-11 22:07 EST
Nmap scan report for ubuntu-20-40-server (192.168.254.147)
Host is up (0.0019s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 (protocol 2.0)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.38 seconds

Note that only the information on the OpenSSH service is displayed now. This is what we're after when setting DebianBanner to no.

DisableForwarding: Disables all forwarding features, including X11, ssh-agent(1), TCP and StreamLocal.  This option overrides all other forwarding-related options and may simplify restricted configurations.

Forwarding can legitimately be used for the following:

• To tunnel sessions transfer files through jump servers

• Connect to a service on an internal network from the outside

• Connect to a remote file share over the Internet

Please be sure your developers are prepared for you to disable this if they typically use it.

So, what's wrong with forwarding from a security perspective?

Forwarding can be used to pivot or to gain access to a network an attacker didn't have access to via a device that does have access to it. Many types of attacks can be carried out once access is gained including scanning for vulnerabilities and sending payloads and exploits. Also, since it's SSH, the traffic is encrypted, often letting the bad guys traffic remain hidden from view.

There are many types of forwarding including X11Forwarding and AgentForwarding. You can disable all forwarding with the single DisableForwarding directive.

If it's not needed, forwarding can be disabled using the global DisableForwarding directive.

DisableForwarding yes

PermitRootLogin: You will not typically connect to an Ubuntu server over SSH as the root user. For that reason, setting PermitRootLogin to no will disallow the root user from logging in over SSH. You'll connect as your regular user with sudo privileges and elevate when needed with the sudo command.

PermitRootLogin no

IgnoreRHosts: Specifies that .rhosts and .shosts files will not be used in HostbasedAuthentication.

Default is yes. RHosts is ignored. You may skip this and achieve the desired behavior with the default configuration. You may get complaints from scanning tools like Lynis and Nessus may complain if it isn't explicitly denied though.

IgnoreRHosts yes

PasswordAuthentication: Specifies whether password authentication is allowed. 

Default is yes, or allowed.

Once you have key based authentication enabled and tested, there's no longer a need to have password authentication enabled. If key based authentication is enabled but doesn't work for a user, and password authentication is still enabled, the default behavior is to fall back to password and let the user try her password for the maximum number of attempts.

This is not desired behavior for a system that uses key based authentication. We do not want any chance of a misconfiguration letting a bad guy guess a password and get access.

PasswordAuthentication no

PermitEmptyPasswords: When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings. 

The default is no.

This setting can also safely be ignored and you'll get the default behavior. Again, some scanning tools may complain if this isn't explicitly set to no.

That's it! Remember, you can find all of this and more in your systems man pages by typing man sshd_config. It's worth a quick look at that man page.

NOTE: If you're using Ubuntu 20.04 Server or newer, I strongly recommend using a custom file in /etc/ssh/sshd_config.d/ as taught in the previous lesson. This lesson is being left in place only for legacy support (support of installations older than 20.04).

Remote Access - sshd_config

Now that we have key based authentication configured for SSH, we can harden our SSH configuration. This is done in the /etc/ssh/sshd_config file.

sshd_config

There are several settings we’ll want to verify or modify in the sshd_config file to make it more secure against attack.

The sshd_config file configures the ssh daemon. The ssh daemon reads this file on starting and uses the configuration kept there to run.

The ssh daemon is the server service that listens for incoming SSH connections on port 22, by default.

There are several items that need our attention. We’ll want to:

• Consider changing the default port from 22 to something else, like 2222 

• Ensure Protocol is set to 2 

• Disable root remote access

• Disable ChallengeResponse Authentication 

• Disable password authentication

Editing sshd_config

As usual, when editing a system file, we’ll save the original or the latest version.

If you’re doing this on a clean Virtual Machine, you probably don’t have a copy of the original yet, so create one

cd /etc/ssh

sudo cp sshd_config sshd_config.0

If you do already have a copy of the sshd_config file, increment appropriately.

Now, we can edit the sshd_config file.

sudo vim /etc/ssh/sshd_config

The file isn’t that big, and we’re only looking for a few lines to confirm or edit settings on. You can just scroll through, or type Esc, then / followed by the term you’re looking for if you want.

Port Number

The first thing we come across, going from top down in the sshd_config file is the TCP Port number that the SSH daemon will listen on. It is Port 22 by default.

I’m not a big fan of security through obscurity. I’d rater just leave SSH running on the default port of 22, and secure the SSH configuration.

However, you will significantly cut down on the “noise” of random login attempts if you migrate to a different port.

Bear in mind, that if you shift to a different port, you’ll have to specify the new port number in the terminal emulator you use (iTerm for MAC, SSH Client for Linux, or PuTTY for Windows).

You’ll also have to permit inbound connections to that new port on your firewall.

sudo ufw allow 222

for example, will allow connections on port 222. You would just open port 222 on ufw, change the Port in sshd_config from 22 to 222, and restart the ssh server with service ssh restart.

Test your connection on port 222 before disconnecting your existing SSH session.

That way, if something’s wrong, you’ll be able to fix it with your logged in session.

To use a different port when connecting from a port other than 22, you specify it with the -p option.

ssh <username>@<ip-address> -p <port>

For the user theo to connect to 192.168.254.105 on port 222, the command would be:

ssh theo@192.168.254.105 -p 222

For Windows users, just specify the different port in the Port text box next to the IP Address. You can save this with your profile.

To re-cap, TCP Port 22 is designed to allow secure communications over SSH, but it is well known by attackers, and they’re constantly scanning for and attempting to log in on it. You may change the default port, if you choose, by changing the Port specification in sshd_config. Just remember, you’ll also have to reconfigure your firewall and connect on the new port always.

You make the actual change in the file by editing the following line:

# What ports, IPs and protocols we listen for

Port 22  < Change this number to the port you want and save your changes.

Remember to restart SSH, with sudo service ssh restart, and to test connectivity before closing your existing session.

Specify Protocol 2 (SSH Version 2)

There are older versions of SSH that have security flaws that have been addressed in SSH Version 2. 

Be sure only version 2 is used by making sure Protocol 2 is explicitly spelled out (this is the default for any recent versions of Ubuntu).

Protocol 2

Disable Root Login Over SSH

We do not want to allow root login over SSH. The root user is not able to log in by default on Ubuntu server. We’d like to keep it that way, but if it is enabled for some other reason, intentionally or through a configuration error, we do not want people to be able to try logging in with it.

root is the name of  the super user on all Linux systems, and bad guys know this. Every system has a root user. 

You may be thinking it might be OK, maybe even a good security practice to change the name of the root user. It isn’t, and please don’t. Many, many programs may break if this user name is changed.

Even if you change the name though, its User ID number will still be 0. You will break still more stuff if you tamper with that.

The thought was reasonable, but please keep the root user, but don’t log in with it.

To make sure remote login isn’t enabled for root, find the following line in the # Authentication section and set it to no:

PermitRootLogin no

Disable Challenge Response Authentication

This is a default, but please ensure it is set to no.

ChallengeResponseAuthentication no

Challenge response authentication could prompt for authentication credentials even if PasswordAuthentication is set to no through PAM (covered later in this lesson). Please just know where this setting is and confirm that it is set to its default value of no.

Disable Password Authentication

Make sure the line, PasswordAuthentication is explicitly set to no. 

Locate the following lines:

# Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes

Remove the # sign before PasswordAuthentication, and replace ‘yes’ with ‘no’:

The line should look as follows:

PasswordAuthentication no

Maximum Login Attempts?

You may be wondering how the system blocks login attempts after a certain number of failures for SSH users.

Please scroll all the way down to the bottom of the sshd_config file, and you’ll see an entry that says UsePAM yes.

PAM stands for Pluggable Authentication Modules, and it is how many aspects of logging in are handled, and not just for SSH.

We aren’t allowing remote access over SSH, because we explicitly stated that only key based authentication is permitted, but I want you to understand why the setting isn’t in the sshd_config file.

Even More Security

In a future lesson, in the Securing Your Server section, you’ll learn how to install Fail2ban. Fail2ban is a free, open source application that watches for malicious activity, like failed login attempts, and blocks the IP Address sending such requests.

That’s enough for now though.

Great work!

Securing Your Server - Fail2ban

Wouldn’t it be cool to block bad guys who are probing your server for vulnerabilities after just a few attempts, instead of letting them try their attacks over and over?

There’s a free, open source utility designed to do just that. It’s called Fail2ban, and there’s a package in Ubuntu’s repositories for it.

It monitors log files for services you want it to protect and will block the source IP Address of the attackers after just a few attempts to compromise your system.

Even if you allow zero chance of someone guessing a username and password to log on to your system with SSH, they can try attacking other services, if any are available as well. 

I like to just block them with Fail2ban, so they can’t keep trying.

We’ll learn how to install and configure Fail2ban in this lesson.

Installation

Installing Fail2ban is easy.

sudo apt update

sudo apt upgrade -y && sudo apt full-upgrade -y

sudo apt install fail2ban

That’s it!

We’ll also install two other programs.

sudo apt install sendmail iptables-persistent

Configuring Fail2ban

The file we’ll want to configure to set up Fail2ban is /etc/fail2ban/jail.local.

That file doesn’t exist yet though.

Create it by typing

sudo vim /etc/fail2ban/jail.local

jail.local File Contents

Copy the following into your jail.local file:

[DEFAULT]

# Ban hosts for one hour:

bantime = 3600

# Override /etc/fail2ban/jail.d/00-firewalld.conf:

banaction = iptables-multiport

[sshd]

enabled = true

Start Fail2ban

Start the Fail2ban service with the following command:

sudo service fail2ban start

Check the status with sudo fail2ban-client status sshd

Testing

You can test that it’s working by enabling password authentication, and trying several times to log in. After 6, it should block you for an hour.

To enable password authentication, set PasswordAuthentication to yes in /etc/ssh/sshd_config.

sudo vim /etc/ssh/sshd_config

Locate the line PasswordAuthentication no, and change it to PasswordAuthentication yes.

Restart the SSH service.

sudo service ssh restart

Remember to set your server back to only allowing key based authentication.

Reverse the change, changing PasswordAuthentication back to no.

Restart the SSH service.

sudo service ssh restart

Security - ufw

In this lesson, we’ll configure your firewall. 

Ubuntu 16.04 and newer comes with ufw installed by default. ufw stands for Uncomplicated Firewall.

There’s a firewall called iptables that is on many linux distro’s, but it’s kind of unwieldy for people new to Linux and firewall management.

ufw is a wrapper or interface to make it much easier to manage the underlying iptables firewall.

You type a simple command into ufw, and behind the scenes, ufw modifies iptables to do what you asked.

ufw

Unless you uninstalled it for some reason, ufw should be there. If it isn’t, though, you can install it by just doing:

sudo apt update

sudo apt install ufw

Configuring for IPV6

There are two versions of Internet Protocol (IP) (the protocol used by your computer for networking). IP Version 4 is the older style you’ve probably seen. A typical address would look like this: 

192.168.1.1

IP Version 6 was created to extend IP because the Internet grew so quickly, we were running out of available addresses. 

IP Version 4 has 4,294,967,296 (about 4.3 billion) addresses available. That sounds like a lot, but when you start putting IP addresses on millions of computers, smart phones, and even refrigerators, you can run out quickly.

An IP Version 6 address looks like this:

1A23:120B:0000:0000:0000:7634:AD01:004D

One thing you’ll notice is that there are many more characters in it. Because there are more characters available, the IP Version 6 address space is much larger. There are 3.4 * 1027  addresses available for IP Version 6. That’s 34 with 27 zeros after it! 

IP Version 4 and IP Version 6 are both enabled by default on Ubuntu Server 16.04.

Since IP Version 6 is enabled, we’ll have to prepare our firewall to use IP Version 6. 

We’ll edit the /etc/default/ufw configuration file to enable IPV6 support. First, though, we’ll copy it.

sudo cp /etc/default/ufw /etc/default/ufw.0

sudo vim /etc/default/ufw

In the ufw file, make sure the line IPV6= has the value of yes:

IPV6=yes

Once that’s done, hit Esc, then Colon wq.

Esc :wq

Default Policy

Now, we’ll set a pretty standard default firewall configuration. We’ll allow all outbound traffic coming from your server, and deny any incoming.

sudo ufw default deny incoming

sudo ufw default allow outgoing

The deny incoming statement does not deny traffic coming back from sources you requested. For example, if you send an outbound request to the Ubuntu update repositories, it will let the response from those servers back to you.

Allow SSH

Secure Shell (SSH) is the protocol you’ll use to manage your server remotely. Configuration will be covered in a separate lesson, but we’ll allow it through the firewall now.

sudo ufw allow ssh

This allows SSH connection attempts from any IP address. If you know you’ll always be connecting from one or only a few IP addresses, you can allow traffic just from that IP address as follows:

sudo ufw allow from 192.168.1.1 to any port 22

Changing 192.168.1.1 to the IP address you’ll be connecting from, of course. 

Enabling ufw

Enabling ufw is simple.

Let’s have a quick look at iptables before we fire it up though, to see what changes will be made by ufw when we turn it on.

sudo iptables -L

It should look like this:

Chain INPUT (policy ACCEPT)

target     prot opt source               destination

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

Don’t worry about understanding it. Just have a before and after look. It’s an empty rule set right now.

Now, we type sudo ufw enable.

You can check the status of ufw by typing sudo ufw status.

Have another look at iptables.

sudo iptables -L

Wow! Where did all those rules come from.

If you hadn’t used ufw to type those few commands, you would have had to enter all those iptables rules yourself.

Allowing Connections for Other Services

Hopefully, you’re spinning up your server to provide a service such as web services on your web server, or some other service.

You can permit web services by typing: 

sudo ufw allow http

sudo ufw allow https

You can type ufw status to make sure the new ports are enabled. You can get more information with ufw status verbose.

Securing Ubuntu Server - Identifying and Removing Unneeded Services -netstat

It is important to know what network services are listening for connections, and how they’re listening.

When a system wants to connect to your server over the network, it will request the connection on your server’s IP address, and on a particular port.

Different ports represent different services.

Some common TCP port numbers are:

22 - Secure Shell - SSH - For secure remote access connections to your server.

80 - Hyper Text Transfer Protocol - HTTP - Clear text web services.

443 - HTTP Secure - HTTPS - Encrypted web services.

Those are the port numbers for just a few of the most common services.

The server will listen on a port with a service.

The ssh daemon will listen on port 22.

The web server daemon will listen on ports 80 and 443.

When you connect to the port for the service you want, the computers will negotiate a connection in an agreed upon manner, and you’ll receive the service you requested.

It is important to make sure only the services you need are listening on your server.

One tool to check what is listening is netstat.

netstat 

netstat, run without any options will provide useful output. I often run it with the -tanup options though.

netstat -tanup

-t = show tcp related information.

-a = show information on all listening processes

-n = show numeric information about hosts (do not attempt name resolution)

-u = show udp related information

-p = show the associated listening program

Running netstat -tanup on a cleanly installed system will show you something like the following:

theo@ubuntu-server:~$ sudo netstat -tanup

Active Internet connections (servers and established)

Proto  Local Address    Foreign Address     State   PID/Program name

tcp        0.0.0.0:22     0.0.0.0:*         LISTEN  1092/sshd

tcp        192.168.254.135:22 192.168.254.101:49687 ESTABLISHED 1614/sshd: theo [pr

tcp        192.168.254.135:22 192.168.254.101:54492 ESTABLISHED 2159/sshd: theo [pr

tcp6       :::22              :::*           LISTEN 1092/sshd

udp        0.0.0.0:68         0.0.0.0:*      950/dhclient

(Recv-Q and Send-Q were removed from above output)

How does all this help us secure our server?

We can see if anything’s listening that we don’t want listening.

In our case, we don’t have the need for Internet Protocol Version 6, so we’ll disable that.

Disabling IPv6

There are presently two versions of the Internet Protocol in use on the Internet. IP version 4, and IP version 6. 

IP version 6 is great, and it has many more addresses available than IP version 4 does, but we don’t need it on our server, so we’ll disable it.

Security - Restricting sudo

If you have multiple users and groups administering your environment, you may want to restrict what certain users or groups can do with sudo.

If you don’t, every user who has sudo permissions can do absolutely anything on any Ubuntu server he or she has permissions on.

We’ll learn how to restrict who can do what in this lesson.

/etc/sudoers.d/ Directory

You could just edit the main sudoers file, /etc/sudoers with the visudo command, but you run the risk of your changes being overwritten or “clobbered” by an upgrade. 

This is why, Ubuntu checks the /etc/sudoers.d/ directory for a configuration file it can use in running sudo commands.

When you put a file there with just the configuration settings you want, they will be kept intact during upgrades.

visudo -f

To add a configuration file there, use visudo with the -f flag to specify the path and name to the file you want to use.

visudo -f /etc/sudoers.d/my-sudoers

Will create a file called my-sudoers in /etc/sudoers.d/ unless it already exists, in which case, it will let you edit it.

Create a sudoers file in the /etc/sudoers.d/ directory called my-sudoers and populate it with the lines below:

Type visudo -f /etc/sudoers.d/my-sudoers

and add the following for later use:

# My sudoers file

# Host alias specification

# User alias specification

#User_Alias WEBMASTERS=luke, leia

# Cmnd alias specification

#Cmnd_Alias WEB=/etc/init.d/nginx status, /etc/init.d/nginx reload, /etc/init.d/nginx start, /etc/init.d/nginx restart, /etc/init.d/nginx stop

# Runas alias specification

# User Privilege Lines

#luke ALL=/etc/init.d/nginx status, /etc/init.d/nginx reload, /etc/init.d/nginx start, /etc/init.d/nginx restart, /etc/init.d/nginx stop

#WEBMASTERS     ALL=WEB

# Group Privilege Lines

User Line

The following is a user definition line:

root    ALL=(ALL:ALL) ALL

root is the user we’re talking about in this line.

ALL= before the equals sign is the host the line applies to. 

(ALL: means root can run the command as all users.

ALL) means root can run the command as all groups.

 ALL means root can run all commands.

Adding a User

You can add a user to your file into the file in sudoers.d and give that user permission to perform only certain operations.

Let’s say we have a username, luke, that we only want to be able to check the status of and restart our nginx web server.

You can edit the my-sudoers file in /etc/sudoers.d as follows:

sudo visudo -f /etc/sudoers.d/my-sudoers

In the file, add the following line under User Privilege Lines

luke ALL=/etc/init.d/nginx status, /etc/init.d/nginx reload, /etc/init.d/nginx start, /etc/init.d/nginx restart, /etc/init.d/nginx stop

This will let luke rune the commands specified on any host. He will be able to check the status of and reload nginx.

Other nginx commands are disallowed.

That works, but it’s kind of long and ugly. We can make things more efficient, especially if we have several users or groups with aliases.

Aliases

You can imagine, if you are responsible for configuring groups of users to do groupings of tasks, it can be cumbersome to just track the permissions individually.

No, we’ll see what it’s like to use aliases.

There are four kinds of aliases. User, Runas, Host, and Cmnd.

User aliases let you group users with similar job functions. 

Runas aliases let you want the user the person running the command can impersonate.

Host aliases let sudo be run on groups of computers or hosts.

Cmnd aliases group like commands that can be run together.

User and Cmnd Example

We’ll set up User_Alias and a Cmnd_Alias for a web server.

The User_Alias will look like this:

User_Alias WEBMASTERS=luke, leia

This will put Luke and Leia into an alias for users called WEBMASTERS.

The Cmnd_Alias will look like this:

Cmnd_Alias WEB=/etc/init.d/nginx status, /etc/init.d/nginx reload, /etc/init.d/nginx start, /etc/init.d/nginx restart, /etc/init.d/nginx stop

User Privileges Using the Aliases

To let the group of users utilize the aliased commands, you just add the following line:

WEBMASTERS      ALL=WEB

This will let the users specified in the WEBMASTERS alias run the commands on all hosts that are permitted in the WEB Cmd_Alias.

luke and leia will be able to check the status of, reload, start, restart, and stop the nginx web service.

You can see how aliases can save you a lot of time and headaches by letting you group people, commands, and hosts by function.

You are only limited by your imagination. You should be able to easily manage multi-user environments with aliases.

Important Caveats

1. Always use visudo -f /etc/sudoers.d/<file-name> to edit your file. Never do this with a text editor alone.

2. Don’t uncomment the last line of the /etc/sudoers file.

The last line of /etc/sudoers starts with a pound sign “#”, but it is active, and is not a comment. Be sure to leave that line as-is to have your /etc/sudoers.d/ directory checked for your my-sudoers configuration file and any others you may create.

Do NOT remove the leading pound sign in an attempt to uncomment that line.

3. Be sure the files you put in /etc/sudoers.d/ do not have a period “.” in them and do not end with a tilde “~”, or they’ll be overlooked and not used by sudo on your system.

Moving Files - scp Between Linux Systems

Eventually, if it hasn’t happened already, you’ll want to move files to or from your Linux server at the command line,

We’ll cover one of your options for doing that in this lesson.

Copying to the Command Line

If you try copying a file to your Linux server by dragging and dropping to a terminal, it won’t work.

The command line does not know how to interpret any of the signals generated in that attempt.

Instead, you have to use a program or command that operates at the command line.

One easy to use, secure program for doing this is the Secure Copy or scp.

scp Overview

Secure Copy operates on port 22, the same as SSH, by default, and it operates using the same mechanisms that let SSH work.

If you have SSH configured, you automatically have the ability to use SCP.

No additional configuration is needed.

It can be used to upload (take files from a location to your server) or download (put files on your server on a different computer) files and directories.

It is a secure way of authenticating and uploading or downloading files. The connection to the server and movement of files are all encrypted in transit.

Using scp

The syntax for scp is fairly straight forward once you’ve used it a few times. The two things you can do are download files or directories and upload files or directories.

Downloading

scp <username>@<from ip>:<file name> /local/directory/

where scp is the command, username is the username you want to connect with, from ip is the ip address of the server you want to download the file from, and file name is the file you want to download. /local/directory/ is the directory on the server you’re connecting to where the file is located.

It would look like this:

scp theo@192.168.254.105:ssh_settings /home/theo/

Would connect to 192.168.254.105 with the username theo and try to find a file called ssh_settings in the default directory on the remote server, and if it’s there, download it to the /home/theo/ directory locally.

The default directory on the remote server will be the home directory of the user you’re connecting with. In this example, it will be /home/theo/ on the remote server.

Uploading

To have a local file uploaded to the server you’re connecting to, the syntax is similar but reversed.

scp <file name> <username>@<to ip>:/remote/directory/

This will copy a file from the directory you’re in when you run the command to the directory you specify on the remote server.

scp ssh_settings_modified theo@192.168.254.105:/home/theo/

will copy the file from the present working directory named ssh_settings_modified to the server 192.168.254.105 connecting with username theo, and put it in the /home/theo/ directory on the remote server.

Copying Directories

You can add the -r flag to do a recursive copy, copying the contents of the directory you specify.

scp -r ssh_stuff theo@192.168.254.105:/home/theo/

Will copy the directory ssh_stuff and its contents from the local directory you’re in when you run the command to the /home/theo/ directory on 192.168.254.105.

Copying Between to Two Remote Hosts

You’re not limited to copying between the system you’re connecting from and the one you’re connecting to with scp.

You can also copy directly between two remote hosts.

The syntax is the same, except you’ll specify a login and password for both locations.

scp <username>@<from ip>:/remote/directory/file <username>@<to ip>:/remote/directory

So, the command

scp -3 theo@192.168.254.134:/home/theo/ssh_stuff_new theo@192.168.254.105:/home/theo/

will copy the file ssh_stuff_new from 192.168.254.134 to the /home/theo/ directory on 192.168.254.105, with the command being run from a completely different computer.

The -3 option will make the transaction occur via the computer running the command, so only its keys have to be on each remote server.

Otherwise, the public keys for remote server one will have to be on remote server 2, and vice-versa.

Troubleshooting

If you run into any issues, make sure SSH works for the username and systems you’re trying to copy files to and from.

Try a simple connection with SSH, without the SCP command.

If this works, check your syntax.

Also, make sure the user you’re logging in with has permission to manipulate the files in question.

Moving Files - Windows

If you want to copy files between a Windows computer, and a Linux computer, from the Windows PC, you’ll need an extra piece of software on the Windows side.

There are many options, but we’ll be using Cyberduck. I recommend against using FileZilla, but you may want to check out WinSCP if you don’t like Cyberduck for some reason.

Cyberduck

Navigate to cyberduck.io in your favorite web browser on your Windows system, and click on the download link for your operating system. It’s available for Windows, Windows 10, and MAC OS X.

As with any program, be very careful where you download the file from. From the source is best. Others may repackage it with bundled malware.

Double click the downloaded file and accept the defaults to install Cyberduck.

Using Cyberduck

Cyberduck is pretty intuitive for experienced Windows users. 

Find Cyberduck in your start menu and double-click on it to open it.

Click on Open Connection to create a connection for your server.

From the protocols dropdown list, select SFTP (SSH File transfer Protocol), make sure port 22 is selected, and put in your username and password.

Once connected, the gui interface is pretty intuitive. You can browse the file system on the remote server or click the Upload icon on the top menu bar to see a window allowing you to browse the local system for the file(s) you want to upload.

Key Based Authentication with Cyberduck

If you’re connecting to a server that requires key based authentication, Cyberduck can do that too.

Just go to Open Connection again, and after completing the other steps above, click on Choose… next to the SSH Private Key input window and browse to your private key file. It will end in .ppk if you generated it with PuttyGen.

When you connect, you’ll be prompted for the password you assigned to your private key file.

After that, all the rest is the same. Browse around and move your files as needed.

That’s it. Good job!

Linux Screen Command

screen is a Linux program that can be used, among other things, to let you reconnect to a session and be exactly where you left off.

It's designed to let you switch between multiple sessions or screens on the same system, but if you have intermittent or problematic Internet connections from your Internet Service Provider, it lets you connect back up to a session you were in and be exactly where you would have been if you had stayed connected.

We'll cover some very basic use cases for screen to familiarize you with it now.

To create a screen session, you just type screen at the command line. If you plan to have multiple screen sessions open on the same system, it is useful to name the sessions as you create them. You do this with the -S option.

screen -S session1

To create a session called session1.

If you plan to have several open it is helpful to name them descriptively so you'll know which is which.

If you don't choose a name, screen will name the session for you with a name like:

14468.ttys000.Linux-Server1

To view current sessions, type screen -ls or screen -list.

Here's an example of the output:

bash-3.2$ screen -ls

There are screens on:

        14488.ttys002.Linux-Server1     (Attached)

        14475.ttys000.Linux-Server1     (Attached)

2 Sockets in /var/folders/t2/dllp92n90g9gv0nxn6bckk_80000gn/T/.screen.

There are two active screen sessions. One starting with 14488 and one starting with 14475. Both are being used and show Attached.

Leave a Process Running Even if You Log Out With nohup

There may be times when you want a process to keep running even if you log out or are logged out by a system.

Normally, when you log off a Linux system, any process you were running would be killed. Sometimes, you don't want this.

One way to achieve keeping your processes running is with the nohup command.

nohup stands for "no hang up." It's from the old days of modems and telephone lines. When you hang up a phone call, the call ends.

nohup keeps the "line" open even if you disconnect.

People who may find this commend useful are developers, DevOps, and people in math or physics. among many others. Anyone who wants to run a possibly long running program without interruption.

The two ways you can run a command using nohup are:

• nohup COMMAND [ARG]

• nohup [OPTION]

Let's start by creating a tiny bash script we can use for testing. I called it sleep4.sh, but you can call it whatever you want.

Here are the contents of the file, sleep4.sh:

#!/bin/bash

echo "I'm sleeping for 4 seconds..."

sleep 4

echo "I'm awake now!"

Remember to make it executable after you're done by typing chmod +x sleep4.sh.

You run it by typing bash ./sleep4.sh  or if you prefer, just ./sleep4.sh within the directory where you created the file.

If you just run it as a bash script without invoking nohup here's what you'll see:

I'm sleeping for 4 seconds...

I'm awake now!

If you run the command using nohup, by typing nohup bash sleep4.sh, input will be ignored while sleep4.sh is running and output will be appended to nohup.out in your home directory unless you specified a different file.

After running, you can see what happened by looking at the content of the nohup.out file.

cat nohup.out

I'm sleeping for 4 seconds...

I'm awake now!

If you run the command multiple times, you'll see multiple iterations of the output in the nohup.out file as it appends to the file. It doesn't overwrite existing content.

If you want the output to go to a file otherthan the default of nohup.out, you can redirect and specify a file name.

nohup bash sleep4.sh > my-output.txt

Will create the same output as in the previous example, but will write it to my-output.txt instead of nohup.out.

Remember to use two greater than signs if you want to append to your file instead of overwrite.

nohup bash sleep4.sh >> my-output.txt

For a file that only takes 4 seconds to run, there isn't any value added by using nohup.

What if you have a program that may take hours or days to run?

You can now create a bash script that will sleep for 10 minutes and we'll see how to use nohup and background to let it run to completion.

Create a sleep600.sh file with the following content:

#!/bin/bash

echo "I'm sleeping for 10 minutes..."

sleep 600

echo "I'm awake now!"

If you run that without back grounding the process with the ampersand "&" or using nohup, your system will put you on hold for 10 minutes unless you break out of the script with Ctrl-C.

If you run it with nohup and you background it with &, you will have to hit [Enter] to get your cursor back.

nohup bash sleep600.sh &

To see that the process is still running, type pgrep -a bash to see a list of all running bash processes.

You can also see what jobs are running with the jobs command.

jobs

[1]+  Running                 nohup bash sleep600.sh &

Once the command completes, you can see the output appended to the nohup.out file.

This seems exactly the same as simply running a process in the background. The difference is that if you disconnect from the system while the job is running with nohup, it will not stop.

If you disconnect, then reconnect and type pgrep -a bash after running with nohup, you'll see that the process is still running.

You can start any process and background it using nohup with the ampersand.

You'll want to use it to run commands that don't expect input or you'll have to foreground them using fg to interact.

Now you understand how to use nohup, should you ever have to run a long-running script you don't want interrupted.