Return to SSH and Tunneling

Home ssh server

The best way to get familiarity with the concepts we will discuss is by experimentation. I think that it is becoming more common these days for people to own more than one computer and set them up in a network. And with cheap computers like Raspberry Pi it is really easy to get started. In this tutorial I want to discuss how you can set up such a server for your experiments in ssh. I encourage you to do this even though I don’t intend this series to focus on server administration. The idea is that by practising these these techniques behind a good firewall you can get some familiarity with them before you get out on the Internet where it matters. For most Linux users, at least, installing and setting up a server is really simple, and you can do it minutes.

Most Linux distros use OpenSSH for this purpose. We discussed this in our introductory tutorial, and I pointed you to http://www.openssh.com/manual.html as a good resource. With that in mind, let’s get started:

Servers for Different Systems

  • Ubuntu – install the package openssh-server
  • Fedora – Install the package openssh-server
  • SUSE – This should already be installed as part of the normal install
  • Windows – This is a little different since OpenSSH is not a Windows program at present. You may want to look at PowerShell Server as possible replacement. There is an article on Microsoft Technet that can get you started. This will eventually change since Microsoft recently (June 2015) announced that they would support and contribute to the OpenSSH community, so I hope we will soon have OpenSSH on all major platforms. There is a way to run OpenSSH with Cygwin, but that introduces too many variables for my taste. If you are a Windows person I would say stick with something more native, and when OpenSSH is a native program on Windows use that.
  • Macintosh – At its heart Macintosh OSX is BSD, which is the native home for OpenSSH, so you should have it already installed.
  • Raspberry Pi – The Raspberry Pi documentation says that ssh server is enabled by default for command line only. Since that is all we are looking at right now that won’t be a problem, but if you get to wanting to forward a desktop you need to look at VNC as a solution. If you want more information consult the Raspberry Pi documentation. This is a great option for people who want to experiment but don’t have a second computer.

Accounts

When you log on to a remote system using ssh you are logging on to an account that you already have on that system. You log on with your user name and password for that system, and when you log on your working directory is your home directory on that system. You can see this by running the “ls” command when you login. You will get a listing of the files and directories within your home directory. So obviously your first order of business is to confirm that you have an account on the server before you attempt to login, and that you know the password for that account.

Configuring Your Server

At this point I am going to focus on Kubuntu, which is what I run on my home network. If you use a different system consult their documentation for particular details in case you encounter differences. Most things are the same, but there may be small details that are different.

First, the config file is located in the /etc/ssh/ directory, and has the name sshd_config. Be careful that you get the correct file. There is a config file for the client, called ssh_config (note there is no “d” in the name), and you don’t want that. “sshd” refers to the ssh Daemon which listens to the port and handles login requests. This file comes with a standard configuration out of the box. You might want to take a look and see what is in there first. I notice that there are a lot of options, but some of them are commented out. To change them you need to use a text editor and remove the comment as well as change the value. But it might be wise first to create a backup of the file as it is before editing it. That way you can always return easily to known-good state. What I like to do is save a copy with the date I saved it, and I use the ISO 8601 standard for that purpose, since it is the only reasonable way to write dates and avoids the ambiguity that comes from the U.S. vs. European issue of whether the month or the day comes first. With the ISO 8601 standard the year comes first, then month, then day (i.e. YYYYMMDD or YYYY-MM-DD), which means that file names using this standard always line up in proper chronological order. So I created a backup called sshd_config_20150906. Then I edited my sshd_config file using Kate, the KDE Text Editor. Here are some of the things I would suggest you look at:

  • Password Authentication – This is the default setting and means that anyone with a password and an account can log in. That is very convenient, but unfortunately it is also convenient for someone trying to hack into your system. Within a home network that might not mean as much at first, particularly if you have a good firewall and never let your ssh port be exposed to the outside. But eventually you will probably want to enable connections from outside so you can access your systems from some other access point. And that is when password authentications will put you into danger. The best way to handle this is with key pairs, which we will discuss later.
  • Change the Port – This is one option you should implement immediately. It won’t stop everything, but there are scanners looking for open SSH ports to crack, and moving your port is a simple measure to stop this. Look for the following lines:
    # What ports, IPs and protocols we listen for
    Port 22

    And change the second line to
    Port XXXXX
    That is delete the 22 and give it a Port number you like. Save the file, and now you will need to configure your clients to use this new number.
  • Log more information – If you are setting up an SSH server you probably want information on any logins, and in particular any failed logins, because they could mean someone is trying to crack your server. The log that records everything is in /var/log/auth-log, which is a text file you can open in any text editor. The default level of information is INFO. Here is what the OpenSSH Manual says about LogLevel:

    LogLevelGives the verbosity level that is used when logging messages from sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging output. Logging with a DEBUG level violates the privacy of users and is not recommended.

    What you can do, and it is worth doing, is to change this to VERBOSE, which will record a lot more information. This is similar to how we changed the port number above. Look for the three lines that read:
    # Logging
    SyslogFacility AUTH
    LogLevel INFO

    and change the last line to
    LogLevel VERBOSE

    A good reason for adding this option is that VERBOSE mode will record failed login attempts, and that is the sort of thing you should be paying attention to. Failed attempts could be simply “fat-fingering” the password, in which case you should know you did it and can ignore it. But if you see multiple failed login attempts it may mean someone is trying to guess passwords to get on your system.

Once you have made your edits you will need to save your file, then restart your server with:

sudo restart ssh

This is not anywhere near a complete look at server setup and configuration, but it is only intended to let you set up a home server to experiment with behind a good firewall. I think it is difficult to understand ssh without something to experiment with, and setting up a server can give you a test bed to see how these commands on the client-side work. And now that you have a server set up, we can experiment with the login process, which is our next tutorial.

Listen to the audio version of this post onĀ Hacker Public Radio!

 Save as PDF