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:
ssh support@192.123.321.99
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 support@192.123.321.99
See "SSH client configuration" in the EXTENSION section for details of how to configure ssh to simplify the above command.
On an MacOS machine you'll normally access the command line via Terminal.app - it's in the Utilities sub-folder of Applications. On Linux distributions with a menu you'll typically find it under "Applications menu -> Accessories -> Terminal", "Applications menu -> System -> Terminal" or "Menu -> System -> Terminal Program (Konsole)"- or you can simply search for your terminal application.
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".
No suitable Windows GUI client is built-in, or available from Microsoft, but the de facto "standard" is a free program called PuTTY. It is written and maintained by Simon Tatham, so get it directly from his site at:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
You can download and install the full suite with "Windows installer" version. If you don't have permission to install software on the computer you are using then you can run PUTTY.exe directly from its download page without installing it. There are other SSH clients, and any should be suitable for the course.
Setting this up to connect with a password is fairly intuitive. Using a public key to authenticate, as you need to with AWS, is a little trickier, as you need to convert the format of the keypair provided by AWS, as outlined in:
https://www.youtube.com/watch?v=bi7ow5NGC-U
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html
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.
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 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:
- "SSH Tunneling" (e.g. https://linuxize.com/post/how-to-setup-ssh-tunneling/)
- "Password-less SSH login" (e.g. https://linuxize.com/post/how-to-setup-passwordless-ssh-login/)
- "SSH client configuration" (e.g. https://linuxize.com/post/using-the-ssh-config-file/)
Copyright 2012-2020 @snori74 (Steve Brorens). Can be reused under the terms of the Creative Commons Attribution 4.0 International Licence (CC BY 4.0). This means you can copy, distribute and adapt the material as long as you credit Steve Brorens, and abide by the CC BY 4.0 licence terms.