Posted by: Master Will | June 1, 2020

Use SSH Keys With PuTTY On Windows


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.


  • 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.


For those who wants things to be done fast you can use the script:

cd ~
wget -O
chmod 700

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
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:

# ./
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:


And enable it. Update /etc/csf/csf.conf:


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_SSHD = "0"
LF_FTPD = "0"
LF_POP3D = "0"
LF_IMAPD = "0"

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

cd /usr/local/directadmin/scripts/custom/

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

cp: cannot stat `’: No such file or directory
cp: cannot stat `’: No such file or directory

Now fetch the files:

cd /usr/local/directadmin/scripts/custom/
wget -O
wget -O
wget -O
chmod 700

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 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
chmod 700

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):

Administrator Security Settings

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 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/ The default value is 1.

                            # 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:

Posted by: Master Will | May 7, 2020

Directadmin: Unable to add access host with MySQL 5.7+

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:


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.

More details can be found here:

How to solve it?

For MySQL 5.7, it should be using this:


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.


Posted by: Master Will | April 4, 2020

OpenVZ: How to perform fsck on a ploop container


From time to time it is necessary to check the filesystem of a container in ploop format.


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.


To run fsck, follow the following steps:

  1. Ensure the container is stopped:
    ~# vzctl stop 101
    ~# vzlist 101
    101          - stopped     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



Posted by: Master Will | January 9, 2019

Verify if named records still good

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
Posted by: Master Will | October 4, 2018

Openvz failed to mount image error in e2fsck

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...
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...
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



Posted by: Master Will | August 15, 2018

Network Unavailable with CentOS 7 (SolusVM)

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:


You also need to edit your resolv.conf file located at /etc/resolv.conf and add the following:


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!



Posted by: Master Will | January 23, 2018

How to install missing ifconfig command on CentOS 7

yum install net-tools

Posted by: Master Will | December 8, 2017

Force HTTPS On All Pages Of Your Website and 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]
# 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.


—– For non-Wordpress site ——

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 ->

and in token |CUSTOM4|, add:

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





Older Posts »