New Linux Install!

Today, I found a wonderful deal on a small VPS over at Ionos: 1 vCore (Xeon Gold 5120 @ 2.2GHz), 512MBs RAM and 10GBs SSD storage – all for $2 per month.
This might not sound like a whole heck of a lot of resources to you, and you’d be right. But for specific use cases, this is perfect.
(disclaimer: The above link is a referral which may provide financial gain for us, with referral rewards)

If you’re using another hosting company’s VPS, Dedicated server or VM, you might find a good bit of useful information here, especially the stuff past the Ionos setup and configuration stages. For initial hardening of an Ubuntu server, you might want to read this article here.

So, the first thing you’d need to do is to create an Ionos account (presuming you’ll be ordering a VPS from Ionos), and then order your VPS. Like most hosting companies, you can create an account with your first order. I actually really like Ionos account pages and provisioning and management interface. The one thing I do not like is having to use a customer id to login, but to each their own.

This is my first VPS with Ionos. Ionos was previously named 1&1, but has changed considerably since their merger and name change. We (My wife & business partner) have a dedicated server from Ionos, which we’ve had for about 8-10 months now. It’s a solid server with no issues. I’m expecting the same with this VPS.

Well, that’s partially true. I ran into a snafu with provisioning ipv6 on this VPS, and resorted to a fresh install. Both times, I had Ubuntu 18.04 installed, because it’s what I’m comfortable with. I really like apt/apt-get, and some tools made by the Ubuntu team, and feel they’re better suited running on Ubuntu itself.

The issue with the ipv6 provisioning was actually not an issue with provisioning, but a mis-understanding about Ionos’ hardware firewall, which sits outside of the VPS. I failed to realize that their firewall was what was blocking my attempts at ipv6 connectivity. Upon re-imaging of the VPS, I read the little pop-up, which stated something about firewalls – At that point, 2 hours of work were gone and I was face-desking pretty hard, because I knew that was my issue all along.

So, step 3 (1 & 2 are above) is to create a new firewall configuration, and, for the time being, allow all connections so that the firewall is not an issue for setup. I personally will be taking advantage of the hardware firewall, once I’ve got all my services provisioned and working. That way, if I run into any issues in setup, or afterward I can narrow down the cause. Some IS professionals would argue with me about not initially taking advantage of this firewall. They may be more correct. After creating the configuration, you’ll need to assign it as your active firewall rules for the VPS. The Linux server does not have to be restarted for this. (Note: I use a software based firewall within the Linux environment to restrict access to services, ports, etc. I personally use and have found UFW to be more than adequate to do the job in lieu of IPTables, another software firewall for Linux) The only other thing to mention here is that you must manually setup an IPv6 address through the management interface for the VPS, and to set up ipv6 firewall configs the same as for ipv4, if you plan to use IPv6 at all.

At this point, you should have an account and interface access for your hosting company, a VPS, and hardware firewall config(s).

Now, let’s get to it! Use your favorite SSH client to log into your fresh VPS. You’ll need the root password given to you from your hosting company, usually sent to you via email. Ionos, however, has the new-image generated password available on the management page. Pretty nifty! You should be able to connect with any SSH client over port 22/TCP. PuTTY, KiTTY (a fork of PuTTY), WinSSHTerm, SSH client built into Linux, as well as any other SSH standard-compliant client will work.

At this point, we’re through with Ionos, and everything here will be Ubuntu, if not GNU/Linux generally relevant.

CHANGE YOUR ROOT PASSWORD!!!

Once logged in as root, type {passwd} and then enter your new password.
(Again, for a better start to hardening your server for security, read the "Linux SSH login – a good starting point", linked above)
At this point, it is advised to create a new user account, with sudoers access, with a new password, and then log out of the VPS as root and log in with the new account. We’re going to ignore this for the time being as everything we’re going to do first requires root/sudo access, and in the event that someone manages to get into your system before you’re done, it’s not too troublesome to reimage the VPS.

UPDATE YOUR APT CACHE!!!

Before doing much else, you should run {apt update && apt upgrade}
This may (more than likely /will/) cause a kernel update, and will require a restart (shutdown -r now)

SETUP & INSTALL SOME BASIC STUFF!!!

Now, let’s get some administrative things out of the way. Namely, hostname and fqdn (fully qualified domain name), additional utilities, and some software & services.
UFW – Uncomplicated Firewall, easier to use firewall than IPTables. (IPTables has it’s place, but most don’t need that power) {apt install ufw}
fail2ban – Intrusion mitigation software to ban access after N unsuccessful authentication attempts. {apt install fail2ban}
Linux PAM – Pluggable Authentication Module, part of most modern distros. Ensure it’s installed.

  • additional reading and consideration for libpam_shield and pam_tally2 for additional levels.

htop – a better hardware resource monitoring tool, with CPU, RAM and cache graphs, process list, etc. {apt install htop}

GNU Screen – a virtual terminal service allowing easier management of full-time processes (tmux and fg/bg work too!) {apt install screen}

HAProxy – an HTTP(S) and TCP proxy, for routing connections (layers 4 & 7) to different ports and hosts. Not required, but useful {apt install haproxy}

HATop – a monitoring tool for HAProxy, requires reading documentation to use. {apt install hatop}

MariaDB – An enhanced fork of MySQL SQL database server – You’ll know if you require an SQL server. {apt install mariadb-server}

  • MariaDB setup will require you to have certain information available, and written down for later access. This can be done later in the overall setup process though.

Java – If you require a Java Virtual Machine (JVM), I highly suggest using Oracle’s JRE. This, however, requires adding an apt repository. Read more here to install Java 12 in ubuntu!

  • If you choose not to use Oracle’s JRE, you can use OpenJDK, with a simple {apt install openjdk-11-jre-headless}

Hiawatha – a security focused light weight (compared to Apache, anyways) web server. Requires source tarball to install latest version.

This should about do it for the additional software and utilities. At least as far as installation goes. Now, onto configuring hostname and fqdn!

With time, change comes. Change is good, needed and wanted. Sometimes it isn’t. Sometimes older technology works just as well, or even better in some cases. There’s various ways to set your new server’s hostname. We’re going to use the tried and true method.

There’s a couple places to set hostname and fqdn.
/etc/hosts and /etc/hostname are two files, where changes will be made.

In hosts, you’ll add your public IP (the same IP you used to connect to the server via SSH) and the fqdn you wish to associate with that IP.
{12.345.67.89 blog.bluntaboutit.com}
This assigns blog.bluntaboutit.com to the IP 12.345.67.89 (fake IP, do not use!)
{ff02:816:f00d:3475::1 blog.bluntaboutit.com}
This assigns the fqdn to the provided IPv6 address (also fake)
With this, blog.bluntaboutit.com will connect to either the v4 or v6 address.

In the hostname file, you’ll add your hostname, which will appear after the @ in bash, as well as identify the machine on the network and other spaces.
This is a single simple string.
{blog.bluntaboutit.com}

Make sure to use domains you actually own and can assign the IP addresses to in your DNS server. Otherwise you might find yourself in a heap of trouble, possibly even with your hosting provider.
Once you’ve edited your files, confirmed the data is correct, saved the files, confirmed the data is correct again, you can restart the VPS. This will solidify the settings and cause your server to use the new hostname and fqdn on start up. Another option, for temporarily setting the hostname is to use {hostname blog.bluntaboutit.com}

Now, I’m running this server as a POP server – point of presence. It’s a server dedicated to running a reverse proxy (HAProxy), where users will connect to and be forwarded to the real server. This is due to the real-time nature of the connections. Having this server will give more stable client-proxy connections to those in the region than doing a client-server connection directly. It adds a tiny bit of latency to the connection, but overall it’s more stable. The proxy-server connection is running through private infrastructure, and so is unencumbered by public traffic, and less hops. Ultimately, there is less latency for the client-proxy-server connection than for client-server connections for most users in the region of the world closer to this server.

With that, I won’t be using mariadb, screen, java, or hiawatha. However, I will still be using UFW, fail2ban, PAM, SSH keys (for login), htop, HAProxy and hatop. The afformentioned software is noted, mostly as these are things which I would normally use on a server, for various reasons and to varying degree. They may also be things which others may forget to install at a more appropriate time. And so, they’re listed as a reminder – just in case. Others may have other software which they consider to be basic stuff, and may want to add to the list of initial setup installables.

SETUP YOUR FIREWALL!!!

Now, there’s two firewalls you can use. I highly suggest using both your hosting provider’s hardware firewall, as well as UFW (Or IPTables, if you need the power it provides). UFW is super simple. But, there is a bit of a learning curve.

Setting up UFW:
Before you do ANYTHING with UFW (once you have it installed, that is) PLEASE do yourself a favor and add your ssh port.
{ufw allow 22/tcp}
This adds a rule to UFW to allow any connection (inside or outside the private network) to connect to the server to port 22 via TCP on IPv4 and IPv6 address (if IPv6 is enabled on your server)
UFW is still very powerful, but for admins looking only to open/block ports/IPs/IP ranges to/from their server, UFW is the easier, and honestly safer choice. IPTables configs can become very complex and can easily be mis-configured to a point of failure. UFW has sanity checks on the commands run against it, and will hint at why the command wasn’t accepted.
If you have, say, a service listening on TCP port 25565, and want everyone in the world to connect to it, but only to your IPv4 address, you would run
{ufw allow from any proto tcp to 12.345.67.89 port 25565}
This will allow any IP address capable of routing to the server’s IP of 12.345.67.89 to connect to TCP port 25565. Likewise, to allow any IP to connect to v4 or v6 addresses, from anywhere, the command can be simplified to the level of SSH’s rule:
{ufw allow 25565/tcp}

UFW also provides firewall access to allow/deny/route in-bound and out-bound traffic on several protocols.

Setting up hardware firewalls:
You’ll need to find the docs for your hosting provider or your own hardware firewall in order to configure and use. Being Ionos is still growing, I feel there is a chance that anything I write here about their hardware firewall setup may become outmoded and useless as time goes on. Their documentation is pretty clear however.

SETUP YOUR AUTHENTICATION PROTECTION!!!
We’ll be using fail2ban as one of several layers to our unauthorized access mitigation solution.
Being that fail2ban has a lot of really good write-ups already, I’m going to have you read A2 Hosting’s instructions. I could copy and paste their instructions, or just the commands they use, but since I use their docs often, I might as well toss them some love!

I will make some notes, however:
"enabled = false" – This setting, on or near line 117 of the default config as of fail2ban 0.10.2, should NOT be changed as indicated by A2 Hosting’s page. Doing so will enable EVERY jail, causing fail2ban to fail to start… and ban. In the individual sections for each jail (such as "[sshd]") add the line "enabled = true" to enable that jail.

"ignoreip" – If you have either a jump-box or a static IP, then you would add that IP to this list, and uncomment it. Otherwise, relying on this to save you from failed logins can bit you in the behind if your IP does change. Especially since now someone else is now potentially white-listed on your server to attempt to brute-force it over time. A jump-box is another server or VPS which only, or primary use is to SSH into, and then connect to other servers. This can be achieved either by logging into the jump-box and then starting a new SSH session from there to the target server, or by means of automatic redirection (i.e. a reverse proxy) If you do not specifically pay for a static IP, or specifically told you have one, usually with business accounts – then you more than likely do not have a static IP, even if your IP hasn’t changed in 6+ months. You can test this by removing all power from your cable/dsl modem for an hour, and comparing the IP address(es) from before it was powered off and after it’s powered back on. Disconnecting the ISP’s wire (telephone wire, coax cable or fibre cable) for at least an hour will usually also work. Exchanging the modem for a new one will too – if you have a Static IP, the new modem WILL have the new IP (unless your ISP sucks really bad)

"bantime" – The default and suggested is 10 minutes. If you’re not afraid of locking yourself out (Either because you’ve never failed log in more than N times, or are OK with accessing the remote console) OR you’re OK with waiting that length of time before logging in again, you can set this MUCH higher. Otherwise, leaving it at 10 minutes is probably OK. I set this much higher.

"findtime" – This is also default to 10 minutes. If this were set to 3 days, all accumulated login failures over 3 days will count towards N tries. If you fail login once a day on average, you can easily become banned if this is set too high. Usually script-kiddies will give up on a host if they’re banned quickly. Between this and the next setting, determines the solution for N tries per X time. Or, at default: 5 tries per 10 minutes, which results in a 10 minute ban. This is plenty for those script kiddies, but a dedicated hacker will just take a snack break and try again. I prefer 3 tries per 5 minutes, with a much longer ban. But I’m comfortable using the remote console.

"maxtry" – Again, 5 is the default, and I set mine to 3. This is simply the number of failed authentication attempts before the IP is banned.

Additionally, if you’re using UFW and want it to handle IP bans, change these keys to use ufw:
(ensure you have /etc/fail2ban/action.d/ufw.conf before relying on this!)
banaction = ufw
banaction_allports = ufw

As pointed out in the A2 Hosting write-up, there is a large selection of services fail2ban can monitor. Most of these settings are probably best left alone, unless you have a specific reason for changing them. Don’t forget to change enabled to = true!

Restart fail2ban service, and enjoy!
{service fail2ban restart} (and view status with {service fail2ban status} – ensure there’s no issues!)

Linux PAM has several config files, all which are optimally set by default. However if you wish to take a look, and make changes at risk of bricking your server, they’re in {/etc/pam.d/} These can be used to fine tune failure attempts. Be careful though, as you can easily negate fail2ban’s timings.

HARDEN YOUR SERVER MORE!!!
At this time, the server is minimally secured and ready to use. But it can still be brute-forced over time – just a much longer time. I highly suggest changing from password SSH authentication to using SSH key pairs. Having a password locked private key is also valuable to this, and should not be overlooked for convenience.
If however, you REALLY wish to continue to use passwords, will never be using SSH, or for what ever reason are not able to use SSH keys, you can bypass this section – but I strongly urge you to reconsider.

Passwords are great for keeping the kids off your desktop, out of your game, and away from specific files. But they can be cracked. And with newer CPUs, times are getting much shorter for cracking software. This applies to file locks, as well as account passwords. SSH Keys too can eventually be cracked, as can the password on an SSH private key – but we’re adding layers of security, which helps greatly to mitigate intrusions! Hardware firewall -> UFW -> fail2ban -> PAM -> account name -> SSH keys -> pk password. Lots of levels to get through.

Some additional methods to help mitigate intrusions include, but aren’t limited to disabling root login over SSH, restricting accounts from services and sudo, changing the SSH port from 22 to something else, requiring SSH access from (a) specific IP address(es) and you have yourself a pretty secure server. Denying all outbound connections, with exception to needed IP/ports can mitigate certain attacks as well as malicious software from "phoning home" Disabling and/or uninstalling any non-used services and software will limit attack vectors for exploits as well. There are also other software which can be installed, such as anti-malware software, spam filtering, and additional levels of authentication enforcement. It can get pretty crazy! Some systems need the protection.

Reminder: We’re still using the root account. At this point, it may be beneficial to create a new user account, with sudo permissions to use as your administrative account (using a not common word for the account name), and a user account without sudo power for running anything that will never need root privileges to operate. Most software does not require sudo/root privileges to run. Remote console can be used for true root access, if ever needed – such as if your administrative account becomes locked or corrupted. As the only software I am running requires root access, I will be creating a new user account with sudo power only, and locking root from ssh login.

Creating your first non-root administrative user account:
Let’s say your administrative account will be named stormbringer. (Let’s not use this name for accounts, ok?)
{adduser stormbringer}
This will prompt for additional information, starting with the new account’s password.
Next, the account must be added to the sudo group, which (should) give it sudo access:
{usermod -aG sudo stormbringer}
To test that the new user account functions, and that it has access to sudo:
{su stormbringer}
The bash prompt should now have replaced "root@" with "stormbringer@" – provided it does, do:
{sudo apt update}
This will prompt for stormbringer’s password. Enter it. This should update your apt cache. If it does, success! If not, go back up a few lines and try again.
To exit out of the stormbringer account back to root, simply do:
{exit}
The bash prompt will now read "root@"

SSH Keys are the key:
NOTE: Be sure to use your administrative user account (NOT root) when performing the below, unless you specifically need to allow the root user to have ssh key login authority.

We’re going to add SSH keys, and disable password login. For this, we need to generate a key-pair on our VPS. This does a couple of things – one, it lets you have a "master key" which can be put on your other servers for convenience, and be easily negated by generating a new key pair replacement in the event of a security breach or loss of key control. It also populates the file system with needed directories. We’re also going to use a separate key pair which belong to the admin. This allows changing the admin’s keys without affecting the other servers. It is good practice to replace key pairs which have been distributed often. Having a separate key for the admin account also allows the admin to retain access to all servers when the server-specific keys are replaced.

SSH keys will not prevent the need to use a password for privilege escalation once logged in with an account with sudo power. Keys can, however be used to disallow password authentication on SSH login.

Since we’re going to be denying SSH login to the root user account, go ahead and log in to the server with your administrative account. It’s best to use a new SSH session for this account, leaving the root session open for the time being. This is so that if there are any issues with connecting via the administrative account, the root account can quickly be accessed to assess the issue, and fix it. All instructions from now on will be done using the administrative account, and NOT the root user account.

To begin, we’ll generate a server specific key pair. Because this key pair will only ever be used for server-server communication, and getting to these keys is difficult, it can be seen as "mildly safe" to generate this pair without a password. In some instances, this can be more safe, as scripts written to rsync data across an SSH connection must store the private key’s password in plain text (unless you want to get really into it, and will encrypt the password, which is beyond most people)
{ssh-keygen}
Let the keys be generated to the default provided path. This will make life easier for you. However, security by obscurity is still a thing, and changing this could be seen as obscurity. Unless you have reason to password protect this key pair, simply leave the password request empty.
When the generation is complete, you will be given a nifty ascii art, followed by the bash prompt. Success!

To create an admin specific key pair, the same instructions can be followed above, either on the same machine (which will overwrite the current key pair), on another Linux host, or with some other tool, such as PuTTY’s key pair generator.

Success! You’ve got an admin specific key! (I’m going to assume you figured out how to do this, because I literally already told you)

To grant access to the administrative account via the admin key, the admin key pair PUBLIC key needs to be added to the server/account.
Create, if it does not exist: /home/stormbringer/.ssh/authorized_keys (using vi, nano, etc)
or with {cp /home/stormbringer/.ssh/id_rsa.pub /home/stormbringer/.ssh/authorized_keys}
Add your public keys to authorized_keys file, including the server and all admin public keys.
Add a comment (using "#") to identify the public key’s owner. This will allow the admin to quickly select and remove expired/compromised/orphaned/ keys and those of ex-admins/users. Do NOT delete or alter the id_rsa.pub file, or you will lose half of your server-specific key pair.
Add new keys, one per line, and only taking up one line. If word-wrap is enabled, the strings will appear on multiple lines, ensure they are in fact on a single line.
Repeat this for each admin public key which needs to be added for access to the account.

In your SSH client, you will need to associate your private key with the server/user profile. This is done differently depending on OS and client. On Windows, PuTTY’s Pageant program will run in the background, and require a password to unlock the private key, but will provide the key to many Windows based SSH clients, including PuTTY and WinSSHTerm v2.

Create a new, (if counting, third) SSH session. This time, using the administrative account (stormbringer, in my example here) – and if everything went right, the connection should quickly complete without requiring a password to be entered. (No cheating here, don’t add your password to an auto-fill script!) Once the administrative account is logged in using SSH keys, SUCCESS! Now we can move to disabling password authentication.

(At this point, you should be able to log in with your administrative account, using only SSH keys, and be able to use sudo to run programs, which will still require the administrative account’s password. If you cannot do these three things in this manner, you should review the instructions, or seek real-time/live assistance)

HARDEN THE SSH DAEMON!!!
Now that you can log in using SSH keys, let’s get rid of that gaping security hole known as "password authentication"! While doing this, there are some additional changes to the SSHD config that can be made. I’ll go over some of them here:
Edit this file with {sudo nano /etc/ssh/sshd_config} (replace nano with vi if you’re hardcore, or old school)
Being that the administrative account is being used, sudo is now required to alter system level config files.

Note: Towards the top of this file are some config options which can be changed, such as the port SSH listens on, and IPv4/6 addresses. Be sure to make appropriate changes in the hardware firewall and UFW/IPTables if these are changed!

These options are commented out, but are enable by default, allowing overrides with changes here. Changes require uncommenting the lines. I also uncomment lines which still apply default values and won’t be changed, but which I use, just as a visual aide when editing the file at a later time.
LoginGraceTime – default is 2 minutes before the session will timeout for no input. This can be changed to 30s when using SSH keys, unless very latent network connections are expected to be used. Leaving this at default is also fine.

  • PermitRootLogin – default is "prohibit-password" or "yes" – change this to "no" to completely disable root SSH login. Leaving this as "prohibit-password" will allow the use of SSH keys to login to the server via the root user. I will be setting this to "no"
    MaxAuthTries – default is 6, I prefer 4. fail2ban should kick in at 3, but just in case.
    MaxSessions – deault is 10. That’s a lot of sessions for a server with 99% no SSH usage at all. File servers accepting rsync over SSH may require more, however.
    * PubkeyAuthentication – default is yes, and commented out. This can be left alone, or uncommented for visual aide, or paranoia reasons.
    * PasswordAuthentication – default is yes. We’re changing this to "no" to prevent password attempts.
    * PermitEmptyPasswords – default is no. I uncomment anyways, even though the setting is nullified by the above setting.
    * ChallengeResponseAuthentication – default is yes. This can still allow brute-force password attacks. We’ll uncomment and set to "no"
    * UsePAM – default is yes. We’ll keep this uncommented and set to "yes" – This allows for less complex client setups.
    X11Forwarding – default is yes. This is a server, what’s a gui? Set this to "no"
    PrintMotd – default is no (at least on my ionos Ubuntu 18.04 image) – This can be changed to provide various info/data on login.
    Banner – default is commented out and set to "none" – I want a nice banner I can grin at on login. I’m setting to "/home/stormbringer/ssh-banner"

    • The ssh-banner file won’t exist, it needs to be created. This is where some nice ascii art, or a big "NO TRESPASSING" sign can be store for display.

The settings marked with * are ones we’re concerned with, regarding security and hardening the server. The rest are fluff and ancillary.
Now here’s something tricky. My config, at the very bottom, has "PermitRootLogin yes" and "PasswordAuthentication yes" – both uncommented. This would negate our previous settings. Ensure your file does not have duplicate entries. Review the file after restart as well, just in case something is messing with things.

Save your file. If you used sudo to run the editor, you should have no problems saving. If you cannot save, you didn’t sudo. Copy the contents, or save to an alternative location in the account’s directory. Then close the editor (if you failed to sudo, either sudo cp the saved file to the proper location, or re-open the proper file WITH sudo)

(If you want a banner, create the file you specified, with at least a word, so it will exist and not potentially cause issues with the config, or login)

Now, we need to test our config the best way we can – by putting it into use with the SSH service.
{sudo service ssh restart} and enter the account’s password. This may cause your connection to reset.
Create a new SSH session (counting still? Number 4) to ensure login is still possible. If not, you’ll need to fix your config. If your connection was reset, you’ll need to fix your config /using remote console/ – which can be a pain. If you were able to log in (and see the text from ssh-banner file if you created one) Success!

Now, go ahead and start your 5th SSH session, this time, using the root user. You may receive the text from ssh-banner file, but then be disconnected with a "no supported authentication methods available" message. If you, like I, do not want root to be able to log in with SSH – SUCCESS! Go ahead and close all but the original root user session and one of the administrative sessions.
At this time, it may be prudent to test {sudo apt update} and {su -} (from the administrative account)
Sudo will require the administrative account’s password. "su -" on the other hand should require the root user account password to access. Sudo should be enough for most things, however in rare cases, the actual root user account may need to be utilized to gain access to portions of the system or services.

Congratulations! You’ve made it to the end. Your reward? A wonderfully secure server. At least to what I consider to be a basic level of security!

BUT WAIT! THERE’S MORE!!!
Did we forget about the hardware firewall? Nope! (ok, well, maybe a little.)
By now you should know if you’re running IPv4 and/or IPv6, and what address(es) will be utilized for what purposes. You should also know at least some of the ports your services and software will be listening on. The hardware firewall configuration should mirror (at least mostly) the rules for allowed ports in UFW. There may be instances where UFW may have more open ports than the hardware firewall. This would be due to allowing monitoring services from your hosting provider, connections to/from other servers on the LAN/private network, or maybe other reasons, such as future use. The hardware firewall should never have any ports opened which are not explicitly in use on the server. Open ports are open attack vectors for exploits, Denial-of-service attacks, and other nefarious things. UFW can block a lot, but it uses server resources to do so. A flood of connections (DDoS) not mitigated by the hardware firewall can potentially overwhelm the Linux server, causing a crash, exploit, or full intrusion.

Here’s a starter kit of useful commands you can perform to inspect your server:
{df -h} (disk filesystem, human readable) will display the amount of space allocated, used and free on your drive, and where each portion is mounted. Generally "/" will be the most used, and largest partition. It’s also the partition that can be used up by extraneous software installs and file storage in the user’s /home/ directory.
{du -h} (du -sh) (disk usage, human readable (summary)) Can specify a directory to see how large that directory or it’s contents are.
{free -h} (available memory resource, again human readable) This shows some quality stats about your RAM can cache.
{lscpu} (list CPU information) This shows information about the CPU as reported to Linux via the hypervisor from the hardware. Modern VPSs generally have accurate info.
{lspci} (list PCI information) Not too horribly useful for VPSs, but can provided critical data on dedicated servers.
{jobs}/{fg}/{bg} – If you’ve ever ghosted a program, where it’s still open but can’t be accessed, try these commands.
{htop} – nice system monitoring tool, with colors! Can also

Some of these commands give good info without sudo. Some will give more info when run as root or via sudo.

This is a baseline of a good start to a fresh Linux install. Obviously, there’s many many many more things that can be done with a Linux server, in terms of use, and security both. But this should provide more than a firm footing for any new Linux server.

I, the author, and BluntAboutIT.com take NO responsibility for any loss of data, access, sanity or finances resulting in the failure (or successful) following of this guide. It is a GUIDE, not a set of axioms. Every admin should fully know, understand and carefully choose the routes they take with their servers, as well as with any and all configurations, software, etc. This guide is here for two reasons only: To help the education process for those who need a bit of help getting started, and for myself, so I have a "check list" of sorts when provisioning new servers. What works for me may not work for you, either technically or functionally. You’ve been warned. I, the author, and BluntAboutIT.com take NO responsibility for any loss of data, access, sanity or finances resulting in the failure (or successful) following of this guide. It is a GUIDE, not a set of axioms. Every admin should fully know, understand and carefully choose the routes they take with their servers, as well as with any and all configurations, software, etc. This guide is here for two reasons only: To help the education process for those who need a bit of help getting started, and for myself, so I have a "check list" of sorts when provisioning new servers. What works for me may not work for you, either technically or functionally. You’ve been warned.

Leave a Reply

Your email address will not be published. Required fields are marked *