Basic system administration solutions

In this article, we are going to address the most frequent use cases that you might face while using Gcore's Cloud service, and we hope that this will streamline your interaction with our infrastructure and cover your needs.

This will include some basic system administration guides to solve the issues that you might come across during service utilization, whether done directly in the operating system of your instance or with the help of our User data feature (it allows you to pre-configure the machines). If interested, you can learn more about User data here, in our Product Documentation.

Note: the solutions presented here are intended for Linux distributions - Ubuntu specifically, as it's the most widespread one. If you're using a different operating system or your own custom image, the solution may differ, so you might want to double-check it online and adjust it accordingly.

Let's start!

Adding SSH keys

As we've mentioned, we encourage the use of SSH keys over password authentication, as it's the far more secure option. Here's how you can set that up.

• If you're creating a new machine, the easiest way is via User data. Just paste the following, having added as many keys as you need (each on its own line, starting with a '-'):

#cloud-config
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAGEA3FSyQwBI6Z+nCSjUUk8EEAnnkhXlukKoUPND/RRClWz2s5TCzIkd3Ou5+Cyz71X0XmazM3l5WgeErvtIwQMyT1KjNoMhoJMrJnWqQPOt5Q8zWd9qG7PBl9+eiH5qV7NZ
- ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAGEA3FSyQwBI6Z+nCSjUUk8EEAnnkhXlukKoUPND/RRClWz2s5TCzFEWOFWEFWEOR2324WReReOR3234re

This adds every key you list to both the default user of your OS (ubuntu on Ubuntu, debian on Debian, etc.) and to root. As soon as the machine is created, you'll be able to connect with any of the added keys straight away - no extra steps needed.

• If you only want a key to work for one specific user rather than all of them, add it under the users module instead, having specified the user first:

#cloud-config
users:
  - name: foobar
    ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAGEA3FSyQwBI6Z+nCSjUUk8EEAnnkhXlukKoUPND/RRClWz2s5TCzIkd3Ou5+Cyz71X0XmazM3l5WgeErvtIwQMyT1KjNoMhoJMrJnWqQPOt5Q8zWd9qG7PBl9+eiH5qV7NZ

• And if you need to add a key to a machine that already exists, you don't need User data for that at all - simply connect to the server and paste the public part of the key into the ~/.ssh/authorized_keys file of the relevant user, then save the changes. You'll be able to connect with the new key right away.

SSH password authentication

Here, at Gcore, security is of utmost priority for us. We value it a lot and reflect that in our services when choosing the approach.

Gcore's Cloud is not an exception. This is why we prohibit password authentication when connecting to our virtual instances/bare metals via SSH and encourage our users to use SSH keys as a far more secure option.

However, this can be inconvenient for some users, and here is how you can change that:

• Of course, it can be easily enabled with the help of User data (the feature we mentioned above). To do that, just paste the following as part of your User data, having changed the value of the password parameter:

#cloud-config
password: your password
chpasswd: { expire: False }
ssh_pwauth: True

• But sometimes you might suddenly face the need to change this on an existing machine without re-creating it. If this is the case, you can follow the instructions below to be used right in the terminal (we assume you are not root):

1. Run

sudo nano /etc/ssh/sshd_config.d/*.conf

Change the 'PasswordAuthentication no' line to 'PasswordAuthentication yes', save the changes and close the file (Ctrl+X, Y, Enter)

2. Reload the SSH service so that the changes are taken into account

sudo systemctl restart ssh

3. Create the password for the needed user

sudo passwd (for root)/ sudo passwd *username* (for any other user)

4. You are done!

After that, you'll be able to use the password you set to connect to your server via both SSH and the VNC console.

Set up password via VNC only

The example above is good and will help you adjust the settings. But in order to enter the needed commands, you need to connect to your server somehow first. And how do you do that if, for example, your machine is not available via the Internet right now and you can't connect via SSH?

The VNC console is your way! It is particularly useful in such cases, but you still need a password that you haven't set yet.

Don't worry, we've got you covered! By following the steps below, you'll be able to set your password even when the machine is unavailable from the Internet:

1. Connect to the server using the VNC console by clicking the 'Access to console' button
2. Once it is open, click the shortcut macro 'Ctrl-Alt-Delete' in the top right corner. This will start the boot process again
3. Once the server starts loading, left-click on the terminal window and then press the 'Esc' key in order to enter the GRUB menu before the actual boot from the disk starts (it's best to press 'Esc' multiple times quickly to ensure you enter the menu)
4. Select Advanced options there and choose any of the recovery mode options available
5. Press 'Ctrl+D' - you'll then see a graphical menu. Choose 'root' to get to the root shell prompt and press 'Enter' twice
6. Once you're in the root shell, run 'passwd ubuntu' to set the password for the 'ubuntu' user (default for our service for machines on Ubuntu)
7. Press 'Ctrl+D' and choose 'resume' to boot the machine normally, then press 'Enter' twice.

Nice! You are now able to log in to your compute via password using the VNC console and can work with the server, for example, in order to restore connectivity to your VM from the Internet.

Create a new user with sudo privileges

Sometimes, rather than sharing the default user or enabling root directly, you'd simply like a dedicated user with administrator rights - for example, one per team member. This is also easily done via User data:

#cloud-config
users:
  - name:                 foobar
    sudo:                 ALL=(ALL) NOPASSWD:ALL
    passwd:               $6$lIlyELDPEXE.gboH$RLOzx88w.hHcXaz3k2oEmhb.VNjawOvmvfbTuLit8GtuENNiocnPA/FxzqPmjGFM/j/3oHJmIoEwI5QBe2Zt9/
    groups:               users, admin
    lock_passwd:          false
    shell:                /bin/bash

Here's what each of these lines does:

• name - the username you're creating
• passwd - a SHA-512-hashed password. You can generate one with the mkpasswd command, e.g. mkpasswd verysecretpassword
• sudo - grants this user superuser rights
• groups - adds the user to the listed groups
• lock_passwd: false - enables password authentication for this specific user (needed if you'd like to log in with a password rather than a key)
• shell - sets the default shell for the user

As with everything else in this article, this only applies at creation time - on an existing machine, you'd create the user the usual way, with sudo adduser and usermod -aG.

Direct access to root

As another security measure on our side, we deliberately lock access to the root user, which has administrator privileges in Linux systems. It is good common practice to use personal users with limited access, both to avoid damaging the system accidentally and to ensure access control.

While using 'sudo' before commands (to perform them with admin privileges) and getting into the root shell with 'sudo -i' when needed covers most use cases, it can still sometimes be inconvenient - for example, when executing scripts involving root's directories, or transferring files over SFTP, and so on.

We understand that, and here is how you can solve this in minutes:

1. It is super easy to do via User data - in just 2 lines:

#cloud-config
disable_root: false

2. But if you need to allow direct access to root on an existing machine and re-creating is not an option for you (for example, you have important data on the machine), the same can be achieved via the terminal in the following way:

Run

sudo nano /etc/cloud/cloud.cfg

Then just change the line 'disable_root: true' to 'disable_root: false', save the changes and close the file (Ctrl + X, Y, Enter)

And run

sudo cloud-init clean -r

This will reboot the server and apply the changes. You are done and can now log in directly as root!

Change the port used for SSH connection

It is also a widespread practice to change the default port used for connecting to the remote server via SSH (which is 22) in order to increase the security of your system and avoid, for example, the simplest brute-force attacks.

Ensure that your chosen SSH port is not blocked by your operating system's firewall or any cloud firewall/security group before restarting the SSH service.

Here is how you can change the port in our Cloud:

1. Of course, this can also be done via User data. You can use the following sample configuration for that:

#cloud-config
runcmd:
- sed -i -e '/^#Port/s/^.*$/Port 8443/' /etc/ssh/sshd_config
- sed -i -e '/^ListenStream=22/s/^.*$/ListenStream=8443/' /lib/systemd/system/ssh.socket
- systemctl daemon-reload
- systemctl restart ssh

All you need to do is change '8443' to the port number that you would like to use for the SSH connection.

2. The same can be achieved via the terminal, on an existing machine, in the following way:

Run

sudo nano /etc/ssh/sshd_config

And change the line '#Port 22' to 'Port 8443' where 8443 is just an example of the port - you can specify any port desired.

Run

sudo nano /lib/systemd/system/ssh.socket

Change the line 'ListenStream=22' to 'ListenStream=8443' where 8443 is just an example of the port - you can specify any port desired (but it should match the one you entered in the file above).

Then run

sudo systemctl daemon-reload

And run

sudo systemctl restart ssh

You are done! Now your server is available via the port you specified in both files above.

Install packages automatically

If you know upfront which packages your machine will need, there's no reason to install them by hand after connecting - User data can take care of that at boot:

#cloud-config
packages:
- git
- htop

Just list whatever packages you'd like installed, and they'll be there as soon as the instance is ready to use.

Configure additional interfaces

As a consequence of the issue we just reviewed, let's discuss how we can actually restore connectivity via the Internet to the instance.

You see, if you decide to add another IP to a running server, a whole new interface will be created, and it will need to be configured in the OS.

This means that if, for example, you need to get another public IP and you delete/detach your current public interface and create a new one afterward, your machine will become unavailable, since the new interface needs to be configured manually within the operating system.

So, let's review how you can do that (this is also applicable to adding new interfaces in general, including private ones). The exact steps depend on your OS.

Ubuntu (any version) / Debian (any version)

1. Run

ip a

After running the command, you will see the list of all interfaces of the server and their status, IP, etc. We need to save the MAC address of the second interface.

Let's explain:
1 - interface status. As you can see, the second interface is down;
2 - interface names. We will configure enp6s0;
3 - MAC addresses of the interfaces. We need to save the address of the second interface.

PS: Ignore the lo interface. Consider that it does not exist.

2. Run

sudo nano /etc/netplan/50-cloud-init.yaml

You will see the configuration of your existing interface. All you need to do is either adjust the setting (in case you re-created the interface) or add exactly the same one, but for your new interface. The only difference should be the MAC address of the new interface and its set-name. It should look like this:

3. Once you've adjusted the settings, save the changes and exit the file (Ctrl + X, Y, Enter)
4. Next, run

sudo netplan apply

5. Run ip a again to check the interfaces. You will see that the status of the second interface is 'UP' now and the IP is displayed.
6. You are all set!

CentOS (9), Rocky Linux (9, 10), Fedora

These are all NetworkManager-based, so the workflow looks a little different:

1. Log in via SSH
2. Go root with sudo -i (or prefix each command below with sudo)
3. Run nmcli device status to see all interfaces and their state. The new interface will typically show up as disconnected - that's the one we need
4. Create a connection profile for it, with DHCP:

nmcli connection add type ethernet ifname eth1 con-name eth1 ipv4.method auto

(replace eth1 with your actual new interface name from step 3 - you don't need to match it by MAC address here, since NetworkManager already recognizes the device)

5. Bring it up:

nmcli connection up eth1

6. Run nmcli device status or ip a again to confirm it shows connected and has an IP
7. You are done!

SUSE

SUSE uses wicked rather than netplan or NetworkManager:

1. Log in via SSH
2. Go root with sudo -i
3. Run ip a to find the name of the new interface
4. Create the config file for it:

vi /etc/sysconfig/network/ifcfg-eth1

(replace eth1 with your actual interface name) and add:

STARTMODE='auto'
BOOTPROTO='dhcp'

5. Apply it:

wicked ifup eth1

6. Run ip a to confirm the interface is up and has an IP
7. You are done!

Windows Server

This OS sets up new interfaces itself - you don't need to do anything manually. If the interface doesn't appear right away after adding it, rebooting the server usually resolves it.

MikroTik OS

ip dhcp-client add interface=ether1 disabled=no

for IPv4, and for IPv6:

ipv6 settings set accept-router-advertisements=yes
ipv6 dhcp-client add request=address interface=ether1 disabled=no

Replace ether1 with your actual new interface name - run interface print to see all interfaces along with their MAC addresses, which you can match against the Customer Portal.

A few important things to keep in mind when working with multiple interfaces:

• All private networks are handed out with DHCP on, regardless of whether the subnet is routable or not - this is the same whether you're adding one extra private interface or several (each one just needs its own bit of config, as shown above).
• Once everything above is done, don't be alarmed if the new IP doesn't respond to ping right away - that's expected. Routing to that IP still needs to be configured (e.g. via the ip route command) in addition to bringing the interface up, and this depends heavily on what you're trying to achieve - there isn't a single one-size-fits-all setup, so you'll need to configure the routing to match your own use case.
• Keep in mind that multiple interfaces on a Linux VM are not the same thing as additional IPs in Hosting. In Hosting, binding several IPs to a single interface is enough and everything works out of the box; with Cloud instances, each interface genuinely needs its own configuration.
• On Ubuntu specifically, interfaces need to be configured inside the OS yourself, even if you added them at instance-creation time - not just when adding them to an already-running machine. That's exactly the process walked through above.

You can now test connectivity to your new IP, or double-check the status of the new interface by running the verification command shown for your OS above once again.

Prioritize your public network over private ones

If your instance has both a public interface and one or more private ones, you might notice that outbound traffic sometimes prefers the wrong gateway. This happens because both interfaces get a route from DHCP, and by default neither is prioritized over the other. You can fix that automatically at boot with the following User data:

#cloud-config
write_files:
  - path: /opt/set-route-metrics
    content: |
      #!/usr/bin/env bash

      netplan_config="/etc/netplan/99-custom-overrides.yaml"
      metric=200
      iface=$(ip r | awk '/172.25.9.0\/24.*link./ {print $3}')

      echo "network:" > $netplan_config
      echo " ethernets:" >> $netplan_config
      echo "  $iface:" >> $netplan_config
      echo "   dhcp4-overrides:" >> $netplan_config
      echo "    route-metric: $metric" >> $netplan_config
      chmod 600 $netplan_config

      netplan apply

runcmd:
  - [ bash, /opt/set-route-metrics ]

A couple of things worth knowing:

• You can write the script to any directory you like - /opt is just an example.
• The default route metric on Ubuntu is 100, so setting 200 here is enough to make the private network's routes lower priority than the public one. Other distributions use different defaults (CentOS, for example, defaults to 400), so adjust the value if you're not on Ubuntu.
• Replace 172.25.9.0/24 in the awk pattern with the actual subnet used by your private interface.

If you'd rather skip DHCP-provided routes for the private network entirely and define your own instead, you can do that too:

#cloud-config
write_files:
  - path: /opt/set-custom-routes
    content: |
      #!/usr/bin/env bash

      netplan_config="/etc/netplan/99-custom-overrides.yaml"
      iface=$(ip r | awk '/172.25.9.0\/24.*link./ {print $3}')

      echo "network:" > $netplan_config
      echo " ethernets:" >> $netplan_config
      echo "  $iface:" >> $netplan_config
      echo "   dhcp4-overrides:" >> $netplan_config
      echo "    use-routes: false" >> $netplan_config
      echo "   routes:" >> $netplan_config
      echo "   - to: 172.16.0.0/24" >> $netplan_config
      echo "     via: 192.168.1.100" >> $netplan_config
      chmod 600 $netplan_config

      netplan apply

runcmd:
  - [ bash, /opt/set-custom-routes ]

And, as always, both of these can be applied to an already-running machine too - just create the same /etc/netplan/99-custom-overrides.yaml file by hand and run sudo netplan apply afterward.

Set custom DNS servers for a private interface

Similarly, if you'd like your private interface to use specific DNS servers instead of whatever gets handed out by DHCP, here's a script for that:

#cloud-config
write_files:
  - path: /opt/set-custom-dns
    content: |
      #!/usr/bin/env bash
      netplan_config="/etc/netplan/99-custom-overrides.yaml"
      interface=$(grep "enp.*:" /etc/netplan/50-cloud-init.yaml | sed -n -E -e 's/([ \t]*)//p')
      dns=[8.8.4.4]

      echo "network:" > $netplan_config
      echo " ethernets:" >> $netplan_config
      echo "  $interface" >> $netplan_config
      echo "   dhcp4-overrides:" >> $netplan_config
      echo "    use-dns: false" >> $netplan_config
      echo "   nameservers:" >> $netplan_config
      echo "    addresses: $dns" >> $netplan_config
      chmod 600 $netplan_config

      netplan apply
runcmd:
  - [ bash, /opt/set-custom-dns ]

This first tells the network to ignore the DNS servers offered by DHCP, then writes in the ones you actually want - you can list as many as you need in place of 8.8.4.4.

Prefer to do it by hand on a machine that's already running? That works too:

1. Run

sudo nano /etc/netplan/99-custom-overrides.yaml

2. Add the following lines there

network:
 ethernets:
  enp3s0:
   dhcp4-overrides:
    use-dns: false
   nameservers:
    addresses: [8.8.4.4]

Save the changes and exit the file.

3. Run

sudo netplan apply

It doesn't matter which way you choose - you can specify any number of DNS servers instead of 8.8.4.4.

These were some common administration cases and the solutions to them that we wanted to share. We sincerely hope that this will allow you to achieve the desired result and will improve your experience with our service.

If you still have any questions or simply have some other inquiry, please don't hesitate to get in touch with our Support team (available 24/7). You can find how to contact them here, and once you do, they'll do their best to assist you.

Good luck with your setups!