- Complementary video
- A short vid on using ssh in a work environment.
- Previous "Day 1" threads
You should now have a remote server setup running the latest Ubuntu Server LTS (Long Term Support) version. You alone will be administering it. To become a fully-rounded Linux server admin you should become comfortable working with different versions of Linux, but for now Ubuntu is a good choice.
Once you have reached a level of comfort at the command-line then you'll find your skills transfer not only to all the standard Linux variants, but also to Android, Apple's OSX, OpenBSD, Solaris and IBM AIX. Throughout the course you'll be working on Linux - but in fact most of what is covered is applicable to any system in the "UNIX family" - and the major differences between them are with their graphic user interfaces such as Gnome, Unity, KDE etc - none of which you’ll be using!
Although there is a "root" user, you will be logging in and working from the user account that you setup. Because this is a member of the group "sudo" it is able to run commands "as root" by preceding them with "sudo".
- Connect and login remotely to your server
- Run a few simple simple commands to check the status of your server
- Change your password
Remote access used to be done by the simple telnet protocol, but now the much more secure SSH (“Secure SHell) protocol is always used.
If you're using any Linux or Unix system, including Apple's MacOS, then you can simply open up a "terminal" session and use your command-line ssh client like this:
ssh user@<ip address>
For example:
On Linux distributions with a menu you'll typically find the terminal under "Applications menu -> Accessories -> Terminal", "Applications menu -> System -> Terminal" or "Menu -> System -> Terminal Program (Konsole)"- or you can simply search for your terminal application. In many cases Ctrl+Alt+T will also bring up a terminal windows.
If you have configured the remote server with your SSH public key (see "Password-less SSH login" in the EXTENSION section of this post), then you'll need to point to the location of the private part as proof of identity with the "-i" switch, typically like this:
ssh -i ~/.ssh/id_rsa [email protected]
A very slick connection process can be setup with the .ssh/config feature - see the "SSH client configuration" link in the EXTENSION section below.
On an MacOS machine you'll normally access the command line via Terminal.app - it's in the Utilities sub-folder of Applications.
On recent Windows 10 versions, the same command-line client is now available, but must be enabled (via "Settings", "Apps", "Apps & features", "Manage optional features", "Add a feature", "OpenSSH client").
Alternatively, you can install the Windows Subsystem for Linux which gives you a full local command-line Linux environment, including an SSH client - ssh.
There are also GUI SSH clients for Windows (PuTTY, MobaXterm) and MacOS (Terminal.app, iTerm2). If you use Windows versions older than 10, the installation of PuTTY is suggested.
Regardless of which client you use, the first time you connect to your server, you may receive a warning that you're connecting to a new server - and be asked if you wish to "cache the host key". Do this. Now, if you get a warning in future connections it means that either: (a) you are being fooled into connecting to a different machine or (b) someone may be trying a "man in the middle" attack.
So, now login to your server as your user - and remember that Linux is case-sensitive regarding user names, as well as passwords.
Once logged in, notice that the "command prompt” that you receive ends in $ - this is the convention for an ordinary user, whereas the "root" user with full administrative power has a # prompt.
Try these simple commands:
ls
uptime
free
df -h
uname -a
If you're using a password to login (rather than public key), then now is a good time to ensure that this is very strong and unique - i.e. At least 10 characters - because your server is fully exposed to bots that will be continuously attempting to break in. Use the passwd command to change your password. To do this, think of a new, secure password, then simply type passwd, press “Enter” and give your current password when prompted, then the new one you've chosen, confirm it - and then WRITE IT DOWN somewhere. In a production system of course, public keys and/or two factor authentication would be more appropriate.
It's very handy to be able to cut and paste text between your remote session and your local desktop, so spend some time getting confident with how to do this in your setup.
Log out by typing exit.
You'll be spending a lot of time in your SSH client, so it pays to spend some time customizing it. At the very least try "black on white" and "green on black" - and experiment with different monospaced fonts, ("Ubuntu Mono" is free to download, and very nice).
Regularly posting your progress can be a helpful motivator. Feel free to post to the subreddit a small introduction of yourself, and your Linux background for your "classmates" - and notes on how each day has gone.
A discord server is also available.
Of course, also drop in a note if you get stuck or spot errors in these notes.
You now have the ability to login remotely to your own server. Perhaps you might now try logging in from home and work - even from your smartphone! - using an ssh client app such as "Termux". As a server admin you'll need to be comfortable logging in from all over. You can also potentially use JavaScript ssh clients (search for "consolefish"), or from a cybercafe - but these options involve putting more trust in third-parties than most sysadmins would be comfortable with when accessing production systems.
Your server is protected by the fact that its security updates are up to date, and that you've set Long Strong Unique passwords - or are using public keys. While exposed to the world, and very likely under continuous attack, it should be perfectly secure. Next week we'll look at how we can view those attacks, but for now it's simply important to state that while it's OK to read up on "SSH hardening", things such as changing the default port and fail2ban are unnecessary and unhelpful when we're trying to learn - and you are perfectly safe without them.
If this is all too easy, then spend some time reading up on:
Copyright 2012-2021 @snori74 (Steve Brorens). Can be reused under the terms of the Creative Commons Attribution 4.0 International Licence (CC BY 4.0).