1. Access OpenVZ 7 node via SSH and install required template with the command:Install required template
yum install centos-7-x86_64-ez
The template name always has the structure {distribution}-{release}-{arch}-ez. As an example centos-7-x86_64-ez
2. Access the master node via SSH and create a file under /vz/template/cache directory. The file name should be a template name with tar.gz extension. In our example the name would be centos-7-x86_64-ez.tar.gz:Create a file
SSH can handle authentication using a traditional username and password combination or by using a public and private key pair. The SSH key pair establishes trust between the client and server, thereby removing the need for a password during authentication. While not required, the SSH private key can be encrypted with a passphrase for added security.
The PuTTY SSH client for Microsoft Windows does not share the same key format as the OpenSSH client. Therefore, it is necessary to create a new SSH public and private key using the PuTTYgen tool or convert an existing OpenSSH private key.
Requirements
PuTTY SSH client for Microsoft Windows
Remote server accessible over OpenSSH
Install PuTTY And PuTTYgen
Both PuTTY and PuTTYgen are required to convert OpenSSH keys and to connect to the server over SSH. These two tools can be downloaded individually or, preferably, as a Windows installer from the PuTTY Download Page.
Once the PuTTY Windows installer is downloaded, double-click the executable in the Download folder and follow the installation wizard. The default settings are suitable for most installations. Both PuTTY and PuTTYgen should now be accessible from the Windows Programs list.
Use Existing Public And Private Keys
If you have an existing OpenSSH public and private key, copy the id_rsa key to your Windows desktop. This can be done by copying and pasting the contents of the file or using an SCP client such as PSCP which is supplied with the PuTTY install or FileZilla.
Next launch PuTTYgen from the Windows Programs list.
Click Conversions from the PuTTY Key Generator menu and select Import key.
Navigate to the OpenSSH private key and click Open.
Under Actions / Save the generated key, select Save private key.
Choose an optional passphrase to protect the private key.
Save the private key to the desktop as id_rsa.ppk.
If the public key is already appended to the authorized_keys file on the remote SSH server, then proceed to Connect to Server with Private Key.
Launch PuTTYgen from the Windows Programs list and proceed with the following steps.
Under Parameters, increase the Number of bits in a generated key: to a minimum value of 2048.
Under Actions / Generate a public/private key pair, click Generate.
You will be instructed to move the mouse cursor around within the PuTTY Key Generator window as a randomizer to generate the private key.
Once the key information appears, click Save private key under Actions / Save the generated key.
Save the private key to the desktop as id_rsa.ppk.
The box under Key / Public key for pasting into OpenSSH authorized_keys file: contains the public key.
Copy Public Key To Server
The OpenSSH public key is located in the box under Key / Public key for pasting info OpenSSH authorized_keys file:. The public key begins with ssh-rsa followed by a string of characters.
Highlight entire public key within the PuTTY Key Generator and copy the text.
Launch PuTTY and log into the remote server with your existing user credentials.
Use your preferred text editor to create and/or open the authorized_keys file:vi ~/.ssh/authorized_keys
Paste the public key into the authorized_keys file.ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBp2eUlwvehXTD3xc7jek3y41n9fO0A+TyLqfd5ZAvuqrwNcR2K7UXPVVkFmTZBes3PNnab4UkbFCki23tP6jLzJx/MufHypXprSYF3x4RFh0ZoGtRkr/J8DBKE8UiZIPUeud0bQOXztvP+pVXT+HfSnLdN62lXTxLUp9EBZhe3Eb/5nwFaKNpFg1r5NLIpREU2H6fIepi9z28rbEjDj71Z+GOKDXqYWacpbzyIzcYVrsFq8uqOIEh7QAkR9H0k4lRhKNlIANyGADCMisGWwmIiPJUIRtWkrQjUOvQgrQjtPcofuxKaWaF5NqwKCc5FDVzsysaL5IM9/gij8837QN7z rsa-key-20141103
Save the file and close the text editor.
Adjust the permissions of the authorized_keys file so that the file does not allow group writable permissions.chmod 600 ~/.ssh/authorized_keys
Logout of the remote server.
Connect To Server With Private Key
Now it is time to test SSH key authentication. The PuTTYgen tool can be closed and PuTTY launched again.
Enter the remote server Host Name or IP address under Session.
Navigate to Connection > SSH > Auth.
Click Browse... under Authentication parameters / Private key file for authentication.
Locate the id_rsa.ppk private key and click Open.
Finally, click Open again to log into the remote server with key pair authentication.
For those who wants things to be done fast you can use the script:
cd ~
wget -O csf-bfm-install.sh https://raw.githubusercontent.com/poralix/directadmin-bfm-csf/master/install.sh
chmod 700 csf-bfm-install.sh
./csf-bfm-install.sh
For those who wants more control and do things manually please follow the guide below (the guide might miss certain updates, but the script will be updated whenever it’s needed).
A common method of gaining access over a server is to use a technique called a brute force attack, or dictionary attack. What the attacker will do, is use a script to try and login to an account with every possible password combination. This tends to require tens of thousands of login attempts, but eventually, the right combination will be found, and they can login normally.
To prevent this, we can use a brute force login detection system in DirectAdmin, so called BFM (Brute Force Monitor).
1. Install CSF/LFD if it’s not installed yet.
Run this as root if you unsure whether or not you have CSF/LFD installed:
csf -v
You’ve got it installed if you see output similar to this (go to step #2 in this case):
# csf -v
csf: v8.22 (DirectAdmin)
You’ve got to install it if you see output similar to this:
# csf -v
bash: csf: command not found
First download and unpack it:
cd /usr/local/src
wget https://download.configserver.com/csf.tgz
tar -zxvf csf.tgz
cd ./csf
Now it’s the right time to test whether or not your server is ready to run CSF/LFD:
# ./csftest.pl
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing xt_connlimit...OK
Testing ipt_owner/xt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK
Testing iptable_nat/ipt_DNAT...OK
RESULT: csf should function on this server
If an output in your console differs much, you’d rather not install CSF and try another way of protecting your server.
Install it:
./install.directadmin.sh
And enable it. Update /etc/csf/csf.conf:
TESTING = "0"
Start it:
service csf start
Additionally you are advised to disable Login Failure Blocking in CSF/LFD as it will be Directadmin to care of it:
This last step is optional and should only be used after you’ve tested the above setup for a while to get comfortable that you’re not going to block yourself. The block_ip.sh is only used for an active “click” by the Admin, it does not automate blocking. To automate blocking, install the following script:
cd /usr/local/directadmin/scripts/custom
wget -O brute_force_notice_ip.sh http://files.directadmin.com/services/all/brute_force_notice_ip.sh
chmod 700 brute_force_notice_ip.sh
3. Update Settings in Directadmin
To make sure that BFM is enabled login as admin into the hosting panel, go to “Administrator settings” and bring the values to the following state (or similar):
IMPORTANT! Parse service logs for brute force attacks should be set to “Yes“! The other settings might be changed to meet your needs.
Save changes, and give a minute or so to changes to take effect. Now you’ve got Directadmin which will automatically block IPs of attackers with CSF.
4. Disable iptables (optional):
That was reported that raw iptables in some cases might overwrite existing rules loaded by CSF/LFD. To avoid it we’d recommend to disable iptables and ip6tables from being loaded at boot time:
If you trust your software and security settings, then you will probably want to hide all those numerous emails about found Brute force attacks. And here is how you can achieve it:
6. The block_ip.sh script specs (for better understanding):
An IP of an attacker will be blocked with iptables via CSF if the following requirements are met:
BFM support is enabled in Directadmin and properly configured
CSF/LFD installed together with the aforementioned scripts to allow Directadmin to communicate with CSF.
IP exceeded max allowed number of login failures on any account.
IP is missing in brute force skip list (/usr/local/directadmin/data/admin/brute_skip.list).
IP is not white-listed in CSF permanently (/etc/csf/csf.allow). Any mention of an IP in the csf.allow will protect the IP from blocking.
IP is not temporary in allowed list of CSF (/var/lib/csf/csf.tempallow).
An IP can be blocked from accessing either any port on the server or only a list of ports of an attacked service. A switcher USE_PORT_SELECTED_BLOCK can be found in /usr/local/directadmin/scripts/custom/block_ip.sh. The default value is 1.
USE_PORT_SELECTED_BLOCK=1; # SET TO 1 OR 0
# 1: TO BAN ACCESS ONLY TO A PORT WHICH
# WAS BRUTEFORCED
# 0: TO BLOCK ACCESS TO ALL PORTS
#
# NOTICE: MANUAL TRIGGER FROM DIRECTADMIN
# WILL STILL BLOCK ACCESS TO ALL PORTS
# FOR AN IP
If Directadmin on your Linux server fails to create users on a remote or locally installed MySQL 5.7+ with an error “Unable to add access host”, an example of which is shown below:
Unable to add access host:
Details
Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin' and host='localhost'
Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin_test2' and host='localhost'
Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin_testdb' and host='localhost'
here you can learn on how to fix it.
Why is it so?
In MySQL 5.7, the `password` field in `mysql`.`user` table was removed, and now the field name is `authentication_string`. Hence Directadmin drops the errors when it’s not informed that it’s connected to MySQL 5.7+ server, which is actual for our case since it’s installed remotely.
to swap the password column with authentication_string for password storage.
CustomBuild 2 should be doing that during the update when you install MySQL 5.7+ locally, so just double check it’s set in the /usr/local/directadmin/conf/directadmin.conf.
If MySQL 5.7 is remote, that might be why CustomBuild 2 didn’t notice. In which case, using mysql_milestone_16=1 in the directadmin.conf should let DA swap the field correctly.
echo "mysql_milestone_16=1" >> /usr/local/directadmin/conf/directadmin.conf
service directadmin restart
From time to time it is necessary to check the filesystem of a container in ploop format.
Cause
Due to various reasons, mainly because of a system crash or an incorrect replication level, the filesystem can became corrupted. As the result, the number of minor filesystem errors grows with time.
It can become necessary to check the filesystem in a ploop image for consistency to avoid data loss.
If you try to start VPS and got error messages like below then
vzctl start 192
Dump file /vz/dump/Dump.192 exists, trying to restore from it
Restoring container ...
Opening delta /vz/private/192/root.hdd/root.hdd
Data cluster 1112 beyond EOF, vsec=47137...
FATAL
Error in ploop_check (check.c:547): Fatal errors were found, image /vz/private/192/root.hdd/root.hdd is not repaired
Error in check_deltas (check.c:631): /vz/private/192/root.hdd/root.hdd : irrecoverable errors
Failed to mount image: Error in check_deltas (check.c:631): /vz/private/192/root.hdd/root.hdd : irrecoverable errors [11]
Starting container...
Opening delta /vz/private/192/root.hdd/root.hdd
Data cluster 1112 beyond EOF, vsec=47137...
FATAL
Error in ploop_check (check.c:547): Fatal errors were found, image /vz/private/192/root.hdd/root.hdd is not repaired
Error in check_deltas (check.c:631): /vz/private/192/root.hdd/root.hdd : irrecoverable errors
Failed to mount image: Error in check_deltas (check.c:631): /vz/private/192/root.hdd/root.hdd : irrecoverable errors [11]
There is a bug in SolusVM that the network settings for CentOS 7 and Fedora 20 do not get provisioned properly when you initially order your VPS. This is due to the change in the way these operating systems use their network config files. Even though there is nothing we can do to fix this automated error, fortunately, you can fix the problem yourself with ease!
First, login to your virtual machine as root using VNC through your SolusVM control panel (since networking is not working, this is the only way).
Next, change your working directory to /etc/sysconfig/network-scripts/, you may do this by running the following command:
cd /etc/sysconfig/network-scripts
Next, you will need to rename your ifcfg-eth0 file to the new format used by CentOS 7 or Fedora 20 to the new one, ifcfg-ens3. That command for this change is as follows:
mv ifcfg-eth0 ifcfg-ens3
Next, you will need to edit the file and replace any occurrence of eth0 with ens3. You may do this with the following command:
sed -i — ‘s/ifcfg-eth0/ifcfg-ens3/g’ ifcfg-ens3
Alternatively: You can edit the file using vim and replace the ifcfg-eth0 occurrence by hand.
We also need to add the DNS servers. Do to this, edit the file /etc/sysconfig/network-scripts/ifcfg-ens3 and enter the following:
DNS1=8.8.8.8
DNS2=8.8.4.4
You also need to edit your resolv.conf file located at /etc/resolv.conf and add the following:
nameserver 8.8.8.8
nameserver 8.8.4.4
These addresses are the Google DNS resolvers so they are extremely fast no matter where you are in the world due to anycasting.
Next, restart networking with:
service network restart
You should now have Internet access! If you have any questions or problems regarding this fix, please feel free to contact the support department as the difficulty of this change may be difficult for beginners. We hope SolusVM has a fix for this soon!
