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 to be done directly in the operation system of your instance or with the help of our User data feature (it allows to pre-configure the machines). If interested, you can learn more about User data here, in our Product Documentation.
Note: the presented solutions are prepared to be used on Linux distributions, Ubuntu specifically, as the most widespread one. If you use some operation system from a different family or your own custom image, the solution can be different for you and you might want to double-check it in the Internet and adjust.
Let's start!
SSH password authentication
Here, at Gcore, the security is of outmost 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 do prohibit password authentication when connecting our virtual instances/bare metals via SSH and encourage our users to use SSH-keys as far more secure option.
However, this can be inconvenient for someone 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 a part of your User data, having changed the value of password parameter:
#cloud-config
password: your password
chpasswd: { expire: False }
ssh_pwauth: True - But sometimes, out of a sudden, you can face the urge of changing this on the existing machine without re-creating it. If this is the case, you can follow the next instruction to be used right in the terminal (we assume you are not root):
1. Run
sudo nano
/
etc
/
ssh
/
sshd_config.d
/
*
.conf
Change 'PasswordAuthentication no' line to 'PasswordAuthentication yes', save the changes and close the file (Ctrl+X, Y, Enter)
2. Reload SSH service so that the changes would be taken into account
sudo systemctl
restart
ssh
3. Create the password for the needed user
sudo passwd (
for
root)
/
sudo passwd
*
username
*
(
forany other user)
4. You are done!
After that you will be able to use the password you set both to connect your server via SSH/VNC console.
Set up password via VNC only
The example above is good and will help you to adjust the settings. But in order to enter the needed commands you need to connect your server somehow first. And how to do that if, for example, your machine is not available via Internet right now and you can't connect it via SSH?
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! Having done the next actions, you will set your password even when the machine is unavailable from the Internet:
-
- Connect the server using VNC console by clicking the 'Access to console' button
- When it is open, click the shortcut macro 'Ctrl-Alt-Delete' in the top right corner. This will start the boot process again
- Once the server starts loading, click on the terminal itself with a left-click button of your mouse and then click 'Esc' button in order to enter the GRUB menu before the actual boot from the disk starts (it is better to click 'Esc' multiple times quickly in order to ensure entering the menu)
- Select Advanced options there and choose any of the recovery mode options available
- Press 'Ctrl+D'. You will see a graphical menu then. Choose 'root' to get under the root shell prompt and click 'Enter' twice
- Having got under the root shell, execute 'passwd ubuntu' to set up the password for 'ubuntu' user (default for our service for the machines on Ubuntu)
- Press 'Ctrl+D' and choose 'resume' to boot the machine normally, click 'Enter' twice.
Nice! You are now able to to log in to your compute via password using VNC console and can work with the server, for example, in order to restore the connectivity to your VM from the Internet.
Configure additional interfaces
As the consequence of the issue we reviewed right before that, let's discuss how we can actually restore the connectivity via Internet towards the instance.
You see, if you decide to add another IP to the running server the whole new interface will be created and it will be required to configure it in the OS.
This means that if, for example, you need to get another public IP and you delete/detach you current public interface and create a new one after that, your machine will become unavailable since the new interface should be configured manually within the operation system.
So, let's review on how you can do that (of course this is also applicable just for adding new interfaces including the private ones).
For Ubuntu/Debian machines, please, do the following:
1. Run
ip a
After running the command, you will see the list of all interfaces of the server and their status, IP, etc. If the status of one of our interfaces is DOWN, it is our case
2. Run
sudo nano /etc/netplan/50-cloud-init.yaml
You will see the configuration of your old/another interface. All that 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:
network:
version: 2
ethernets:
enp3s0:
dhcp4: true
match:
macaddress: your_mac_address
mtu: 1500
set-name: enp3s0
You can look the MAC-address up in our Customer Portal, having opened the overview menu of the instance, under Networking section:
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. You are all set!
You can now test the connectivity towards your new IP or double-check the status of the new interface having run 'ip a' once again. You will now see that the status of the second interface is 'UP' and the IP is displayed/has changed.
Direct access to root
As another measure on our side in terms of enhancing the security, we can mention deliberately locking the access to root user which has administrator privileges in Linux systems. It is a good common practice to use personal users with limited access not to damage the system accidentally and to ensure access control.
While using 'sudo' before the commands (used to perform it with admin privileges) and getting under the root shell with 'sudo -i' when needed covers most of the use cases, sometimes it can be still inconvenient, for example, when executing some scripts involving root's directories or, for example, transferring some files over SFTP and so on.
We do 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 the 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 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 further login directly as root!
Change the port used for SSH connection
It is also a widespread practice to change the default port used for connecting 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.
Here is how you can do that 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 that you need to do is just to change '8443' to the port number that you would like to use for 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.
These were some common administration cases and the solutions to it we wanted to share. We sincerely hope that it will allow you to achieve the desired result and will improve your experience with our service.
If you still have any questions left 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 assist you to their best.
Good luck with your setups!
Comments
0 comments
Please sign in to leave a comment.