Introduction

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.

1. Click Conversions from the PuTTY Key Generator menu and select Import key.
2. Navigate to the OpenSSH private key and click Open.
3. Under Actions / Save the generated key, select Save private key.
4. Choose an optional passphrase to protect the private key.
5. 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.

Otherwise, proceed to Copy Public Key to Server.

Create New Public And Private Keys

Launch PuTTYgen from the Windows Programs list and proceed with the following steps.

1. Under Parameters, increase the Number of bits in a generated key: to a minimum value of 2048.
2. Under Actions / Generate a public/private key pair, click Generate.
3. You will be instructed to move the mouse cursor around within the PuTTY Key Generator window as a randomizer to generate the private key.
4. Once the key information appears, click Save private key under Actions / Save the generated key.
5. Save the private key to the desktop as id_rsa.ppk.
6. 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.

1. Highlight entire public key within the PuTTY Key Generator and copy the text.
2. Launch PuTTY and log into the remote server with your existing user credentials.
3. Use your preferred text editor to create and/or open the authorized_keys file:vi ~/.ssh/authorized_keys
4. Paste the public key into the authorized_keys file.ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBp2eUlwvehXTD3xc7jek3y41n9fO0A+TyLqfd5ZAvuqrwNcR2K7UXPVVkFmTZBes3PNnab4UkbFCki23tP6jLzJx/MufHypXprSYF3x4RFh0ZoGtRkr/J8DBKE8UiZIPUeud0bQOXztvP+pVXT+HfSnLdN62lXTxLUp9EBZhe3Eb/5nwFaKNpFg1r5NLIpREU2H6fIepi9z28rbEjDj71Z+GOKDXqYWacpbzyIzcYVrsFq8uqOIEh7QAkR9H0k4lRhKNlIANyGADCMisGWwmIiPJUIRtWkrQjUOvQgrQjtPcofuxKaWaF5NqwKCc5FDVzsysaL5IM9/gij8837QN7z rsa-key-20141103
5. Save the file and close the text editor.
6. Adjust the permissions of the authorized_keys file so that the file does not allow group writable permissions.chmod 600 ~/.ssh/authorized_keys
7. 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.

1. Enter the remote server Host Name or IP address under Session.
2. Navigate to Connection > SSH > Auth.
3. Click Browse... under Authentication parameters / Private key file for authentication.
4. Locate the id_rsa.ppk private key and click Open.
5. Finally, click Open again to log into the remote server with key pair authentication.

Credit: https://devops.ionos.com/tutorials/use-ssh-keys-with-putty-on-windows/

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:

LF_TRIGGER = "0"
LF_SSHD = "0"
LF_FTPD = "0"
LF_SMTPAUTH = "0"
LF_EXIMSYNTAX = "0"
LF_POP3D = "0"
LF_IMAPD = "0"
LF_HTACCESS = "0"
LF_MODSEC = "0"
LF_DIRECTADMIN = "0"

2. To make Directadmin’s BFM compatible with CSF you should do the following:

cd /usr/local/directadmin/scripts/custom/
cp block_ip.sh block_ip.sh.bak
cp unblock_ip.sh unblock_ip.sh.bak

It’s OK if you have no block_ip.sh and unblock_ip.sh, and the previous step might fail with a warning:

cp: cannot stat `block_ip.sh’: No such file or directory
cp: cannot stat `unblock_ip.sh’: No such file or directory

Now fetch the files:

cd /usr/local/directadmin/scripts/custom/
wget -O block_ip.sh http://files.plugins-da.net/dl/csf_block_ip.sh.txt
wget -O unblock_ip.sh http://files.plugins-da.net/dl/csf_unblock_ip.sh.txt
wget -O show_blocked_ips.sh http://files.plugins-da.net/dl/csf_show_blocked_ips.sh.txt
chmod 700 block_ip.sh show_blocked_ips.sh unblock_ip.sh

Create the empty block list and exempt list files:

touch /root/blocked_ips.txt
touch /root/exempt_ips.txt

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:

CentOS 5, 6:

chkconfig iptables off
chkconfig ip6tables off

mv /etc/init.d/iptables /etc/init.d/iptables~moved
echo -e '#!/bin/bash\nexit 0;' > /etc/init.d/iptables
chmod 755 /etc/init.d/iptables

4. Disable firewalld (optional):

CentOS 7:

systemctl disable firewalld
systemctl stop firewalld

5. Suppress BFM messages (optional):

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:

echo "hide_brute_force_notifications=1" >> /usr/local/directadmin/conf/directadmin.conf

Restart directadmin.

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:

1. BFM support is enabled in Directadmin and properly configured
2. CSF/LFD installed together with the aforementioned scripts to allow Directadmin to communicate with CSF.
3. IP exceeded max allowed number of login failures on any account.
4. IP is missing in brute force skip list (/usr/local/directadmin/data/admin/brute_skip.list).
5. 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.
6. 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

Used links:

• http://help.directadmin.com/item.php?id=380
• http://help.directadmin.com/item.php?id=404
• http://help.directadmin.com/item.php?id=1332
• https://help.poralix.com/articles/how-to-block-ips-with-csf-directadmin-bfm

Why is it so?

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.

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.

More details can be found here: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-6.html

How to solve it?

For MySQL 5.7, it should be using this: https://directadmin.com/features.php?id=1840

mysql_milestone_16=1

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

That’s it.

Credit: https://help.poralix.com/articles/directadmin-unable-to-add-access-host-with-mysql-5-7

Symptoms

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.

Resolution

To run fsck, follow the following steps:

1. Ensure the container is stopped:

   ~# vzctl stop 101
   ~# vzlist 101
   CTID      NPROC STATUS    IP_ADDR         HOSTNAME
   101          - stopped   10.10.10.11     fsck.test
   

   Note: Do not perform fsck when the container is running or mounted.

2. Mount the container’s ploop image. This allocates a ploop device on the host:

   ~# ploop check -F /vz/private/101/root.hdd/root.hdd
   ~# ploop mount /vz/private/101/root.hdd/DiskDescriptor.xml
   add delta dev=/dev/ploop12345 img=/vz/private/101/root.hdd/root.hds (rw)
   

3. Run fdisk -l for the /dev/ploopX device reported by the previous command. You will need to let the system fetch a list of partitions on /dev/ploopX:

   ~# fdisk -l /dev/ploop12345
   WARNING: GPT (GUID Partition Table) detected on '/dev/ploop12345'! The util fdisk doesn't support GPT. Use GNU Parted.
   Disk /dev/ploop12345: 10.7 GB, 10737418240 bytes
   255 heads, 63 sectors/track, 1305 cylinders
   Units = cylinders of 16065 * 512 = 8225280 bytes
   Sector size (logical/physical): 512 bytes / 512 bytes
   I/O size (minimum/optimal): 512 bytes / 512 bytes
   Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
   /dev/ploop12345p1               1        1306    10485759+  ee  GPT
   

4. Perform a file system check for the partition reported in the previous command’s output (note p1 at the end):

    ~# e2fsck -y /dev/ploop12345p1
   e2fsck 1.41.12 (17-May-2010)
   /dev/ploop12345p1: clean, 22404/655360 files, 238012/2620923 blocks
   

   Note: You may add more options to e2fsck, check the manual pages if needed.

   -p - Automatically repair the file system without any questions.
   -y - Assume an answer of `yes' to all questions.

5. Unmount the ploop image:

   ~# ploop umount -d /dev/ploop12345
   Unmounting device /dev/ploop12345
   

6. Start the container:

   ~# vzctl start 101

    

Credit: https://virtuozzosupport.force.com/s/article/000013760

To check if DNS (named) service contain bad records, then run below

named-checkconf -z /etc/named.conf

If php 5.6

systemctl restart php-fpm56.service

If php 7.2

systemctl restart php-fpm72.service

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]

 

Try these command to fix it.

# ploop check -F /vz/private/192/root.hdd/root.hdd
# ploop mount /vz/private/192/root.hdd/DiskDescriptor.xml
# fdisk -l /dev/ploop46026
# e2fsck /dev/ploop46026p1
# vzctl start 207

 

Source: https://serverfault.com/questions/666443/openvz-containers-will-not-start-after-a-reboot

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!

 

Credit: https://www.meanservers.com/billing/knowledgebase/19/Network-Unavailable-with-CentOS-7-or-Fedora-20.html

yum install net-tools

—– For non-Wordpress site ——

This is the thing that got me when I was making the full transition to HTTPS for my blog. After changing the site name, all my CSS and JavaScript assets were still coming in with the HTTP URL path rather than HTTPS. This caused my site to appear broken in pretty much every browser.

These site asset files can easily be corrected by fixing the rewrite rules in your .htaccess file found at the root of your WordPress application.

# BEGIN WordPress
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{SERVER_PORT} !^443$    <---- Add this line
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]   <---- Add this line
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Notice the highlighted lines in the above code. We’re saying that if the current port isn’t 443, then rewrite the URL to use HTTPS with a 301 redirect. The rest of the above code should already exist in your WordPress .htaccess file. Usually it will be found at the bottom of the file.

 

If you want to force a given website or path to use https, redirected from http, you can create an .htaccess file in the DocumentRoot for that domain or hostname, and add the following code:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

which will redirect any non-https connections to https using the same request and GET variables.

If your site is running through CloudFlare, your https requests to it may actually hit your server in plaintext (http), which is confusing.
For that case, you might need something like this for an http to https redirect:

RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

where the only usable header is X-Forwarded-Proto, because the %{HTTPS} variable is “off” for requests from the CloudFlare network.

---

If you’re running nginx, go to:

Admin Level -> Custom Httpd Config -> domain.com

and in token |CUSTOM4|, add:

|*if SSL_TEMPLATE=”0″|
return 301 https://$host$request_uri;
|*endif|