RamNode Debian primer script

The out-of-the-box Debian experience on RamNode has improved drastically in recent days, but it can still be quite a chore to get your vanilla VPS to the point where it’s ready for the challenges of the hostile, wild west climate of the Internet. That’s why I wrote a script that will get your RamNode hosted Debian VPS tuned, hardened and fit for production use in the fastest possible time.

Ramnode + Debian primer script

ramnode-bootstrap.sh history

RamNode is one of the fastest, most cost-effective VPS solutions around. But when I originally wrote my RamNode/Debian primer script, it was because the default installation of Debian on RamNode was frankly awful. There were superfluous i386 packages mixed in on x86_64 installs by default, an entire crufty, early 2000’s style LAMP stack, Sendmail, BIND, SAMBA… the list goes on. I liked RamNode a lot as a host, but I wound up spending far too much time cleaning up the default installation for people, eventually leading me to write ramnode-bootstrap.sh to automate the process.

Today the situation is thankfully much better than it was. RamNode offers two vanilla Debian installation choices for their OpenVZ VPSes: 64-bit, and 64-bit Minimal. Both are far, far more sane than previous iterations, and neither has the strange mixture of architectures and packages that previous versions suffered from. Thankfully, my script does a lot more than just purge junk packages for a clean starting point.

What the script does

  • Removes a handful of packages most people probably won’t want on a modern VPS.
  • Adds a handful of useful administrative tools (none of which run as a service). Some of these are actually somewhat important for the normal operation of Debian systems, such as dialog and tzdata.
  • Automatically brings the system up to date with the latest available packages from public mirrors.
  • Sets up system-wide IPv4/IPv6 firewall policies with the user-friendly UFW.
  • By default, sets the OpenSSH daemon to run on a randomly-defined, high-numbered port with a matching firewall rule to permit traffic. Your authentication logs will thank you (but you can override this behavior if you wish by editing the script’s variables prior to running it).
  • Further hardens SSH by installing Fail2Ban, only allowing ciphers/MACs without known vulnerabilities, enabling the AllowGroups option and disabling UseDNS.
  • Adds GPG keys and apt sources entries for dotdeb (cutting-edge PHP, Redis, Nginx, etc.) and tuxhelp (Hiawatha secure webserver) repositories.
  • Imports some pre-tuned, OpenVZ-friendly configuration files to maximize the performance and security of the system.
  • Creates backups of system default configuration files for reference.
  • Interactively adds a non-root administrative user account, disabling the built-in root account in the process.
  • When the setup is complete, it outputs a helpful, pre-formatted SSH client stanza for convenient future logins.

Note: ramnode-bootstrap.sh is intended for use on a new, vanilla RamNode OpenVZ VPS running Debian x86_64. You should not run this script on a system which is already in production, or bad things™ may happen.


Using ramnode-bootstrap.sh was designed to prepare your Debian VPS on RamNode as quickly and painlessly as possible. In fact, it takes a lot longer to describe the process than to actually do it.

  1. Get an OpenVZ VPS on RamNode. When prompted for which OS you’d like preinstalled, choose Debian 8 64-bit or 64-bit Minimal.*

    * If you’ve already messed around with the VPS or if it’s not running the expected flavor of Linux, you can always correct this. Just login to the control panel, click “Manage” next to the relevant host, select “Debian 8 64-bit” (or “Debian 8 64-bit Minimal”) from the list, then click “Reinstall”. THIS WILL DELETE ALL DATA ON THE HOST, so if there’s anything you want to keep, MAKE SURE TO GET A BACKUP FIRST.

  2. Set very strong passwords for both your RamNode account and Control Panel. Weak passwords in either of those places can allow side-channel access to your VPS which this script has no way of protecting against.

    This is completely abstracted from your Debian host, so unfortunately ramnode-bootstrap.sh cannot do this for you. However it is a very important security consideration that is often overlooked. No matter how secure your VPS instance may be, an attacker who can gain access to your RamNode account or Control Panel will have full control over your hosts. Personally, I use max-length, randomly-generated passwords for this purpose, and store them in a password manager.

  3. Login to your VPS. The information needed for your initial login in is provided by RamNode in an email. For example, if the IP address of your VPS was, you’d do something like the following:
    ssh -C -l root
  4. Download and run ramnode-bootstrap.sh. If you want to evaluate the code and/or change some variables in the script before executing it, you can do this as two separate operations:
    wget https://files.tuxhelp.org/scripts/ramnode-bootstrap.sh -O /tmp/ramnode-bootstrap.sh
    /bin/bash /tmp/ramnode-bootstrap.sh

    Otherwise, you can download and run it in a single command:

    wget https://files.tuxhelp.org/scripts/ramnode-bootstrap.sh -O /tmp/ramnode-bootstrap.sh && /bin/bash /tmp/ramnode-bootstrap.sh
  5. When prompted, define a new user account and password. This will be the first account added to your system for administration. I’d recommend never using a generic, easily guessable account name like “test”, “admin”, etc. Don’t neglect to set a decent password for it, either.

  6. Record your SSH stanza! When the script has completed, it will output a pre-formatted stanza for your SSH client. Add it to your local computer’s SSH configuration (typically ~/.ssh/config). If you’re not running a *nix-like system such as Linux or OS X on your client machine, record the information and manually add it to PuTTY (or whatever SSH client you happen to prefer) on Windows.

  7. Reboot. After completion, the script will ask whether you’d like to reboot. If there’s nothing else you need to do at present, press ‘ENTER‘. Otherwise, hit ‘n‘ to decline. Regardless, you will need to reboot eventually for all of the changes to go into effect.
  8. Optional:

  9. Do a test login via SSH. Once you’ve added the SSH information the script outputs to your ~/.ssh/config, you should be able to login to your host using the credentials you setup earlier. This time you won’t even need the extra SSH flags, IP address, etc. as the stanza you’ve added contains your username and the VPS’ hostname.
    ssh example
  10. Copy your SSH public key to your server. For added security and convenience, you can copy your SSH public key to ~/.ssh/authorized_keys on the server. The process is a bit different for every client OS out there, so I'll leave this as an exercise for the reader.
  11. Disable password-based SSH logins. If you've already got your SSH public key(s) added to your system and verified that they work, you can disable tunneled cleartext password logins entirely. Edit /etc/ssh/sshd_config with the tool of your choice and change the following line:
    #PasswordAuthentication yes

    to this:

    PasswordAuthentication no

    Unfortunately opensshd doesn't currently cope very well with graceful service restarts in OpenVZ, so you'll have to reboot the system before your change will go into effect... good thing OpenVZ systems reboot very fast – usually around 5 seconds or less.

  12. Add firewall pinholes for your public services. By default, the script configures UFW to only allow access to the SSH service from the outside world. If I wanted to add an allow rule for HTTP/S web services, the command would look something like this:
    sudo ufw insert 1 allow 80,443/tcp

  13. Create additional system users. By default, only one user is created to administrate the system. You can add more if you'd like with standard system tools, e.g.
    sudo adduser joebob

    In order for the user to be allowed to login remotely via SSH, you'll also need to add them to the 'sshlogin' group:

    sudo usermod -a -G sshlogin joebob

    Likewise if you'd like them to be able to make system-wide changes:

    sudo usermod -a -G sudo joebob

    You could also add them to multiple groups with one command, like so:

    sudo usermod -a -G sshlogin,sudo joebob
  14. Update the system. Even with your system being a lot more securely configured than a lot of hosts on the internet, you'll want to periodically update it with security patches and bugfixes. There's a really simple script installed by ramnode-bootstrap.sh that can do this for you in one command:
    sudo apt-up

    You could alternately setup unattended upgrades, but that may or may not be a good idea depending on which services it'll be running. Your call.

  15. Set the local timezone. Because the normal Debian installation process is bypassed on a pre-installed VPS instance, the host's local timezone isn't set by default. For convenience when reading timestamps (or if something in your software stack relies on it), you can easily choose your timezone using the standard Deb method:
    sudo dpkg-reconfigure tzdata

Future versions

Since this script was originally written in 2014, I've kept it up to date with the current state of both RamNode and Debian. I plan to continue doing so as time goes on, but even if I get hit by a bus tomorrow it's open source licensed. While wouldn't consider myself a master scripter, I did try to keep it as clean, sensible and modular as possible so others could extend or adapt its functionality for their own needs. It would be trivial to, for instance, install and configure a full application stack as part of the process. If you happen to write your own spin of ramnode-bootstrap.sh, I'd be interested to see what you've done with it.

4 thoughts on “RamNode Debian primer script

  1. The current version of the script (Oct 26, 2017) adds color highlighting to make informational messages from the script more distinct along with slightly improved error handling.

  2. I tried running on a Debian 9 install on Digital Ocean and ran into a few problems.

    * Changed DEBIAN_VERSION to 9
    * Removed libbind9-90 and apache2-mpm-prefork packages from PURGE_PKGS since it failed when it could not find them
    * Changed all references from “jessie” to “stretch”
    * Needed to install dirmngr which is required for running apt-key
    * Script didn’t like the quotes around “${GPG_KEYS}” in line 1217

    The dotdeb packages are not available for stretch so I use the deb.sury.org packages instead.


    There also won’t be any packages created for 7.1 or later so deb.sury.org is definitely the way to go.


    Additionally, I tend to use csf (ConfigServer Security & Firewall) so I disabled ufw and fail2ban. Curious to hear if you have any opinion on csf.

    I was very happy to see that your primer script matches a lot of what I do to lock down a server. I’m not a performance guru by any means so it was helpful to see your system variable configs.

    Thanks for sharing!

    • Thanks for the feedback. Yep, it’s got some RamNode/OpenVZ specific stuff in it because OpenVZ is a little different than other PV/container environments. I’ve found RamNode to be a lot faster than the vast majority of other VPSes though, especially for the money, so even with its early teething problems I felt RN was worth it.

      The general principles of the script apply anywhere, but it definitely needs to be tweaked for the environment you’ll be running it in. The double quote issue on line 1217 might be a dashism; tested on bash, zsh etc. and haven’t run into that issue. Another possibility is a copy/paste type issue where the quotes got changed to fancy inverted double quotes somewhere along the way.

      I’ve run CSF before. It’s pretty nice, I used it (without any of the cpanel stuff) for a few years on a couple of stand-alone servers. It generally worked fine for me, with a few exceptions. It’s fairly complex under the hood though, and there’s a lot to go wrong if one of the many interdependent parts changes at any point.

      As for the variables… I actually usually tune this stuff a lot tighter, but OpenVZ gives a limited amount of knobs to turn. Thus, with non-VZ VPSes you may want to revisit that. 😉

      All the best,

  3. Please note that if you have problems running this script, do not pipe directly to BASH. Instead, try saving it someplace on disk (/dev/shm or /tmp are just fine) and executing it from there.

Leave a Reply

Your email address will not be published.