There are several ways to access your hosting account via SSH:

• Windows (access via PuTTY)
• macOS/Linux (access via Terminal)
• Terminal menu in cPanel

To access your hosting account via SSH on Windows, you should:
1. Make sure that SSH access is enabled for your account.

2. Open your SSH client, put your domain name or the IP address of the server into the Host Name field, enter 21098 into the Port field (22 for a VPS/Dedicated server), choose SSH as your connection type and press the Open button:

3. You will receive the Putty Security Alert. Press OK:

4. When prompted, enter your cPanel username and password (when you enter the password, it is automatically hidden for the security purposes):

You can find cPanel login details in the Hosting Welcome email sent right after the package activation. If you face difficulties finding the Welcome email, reach out to our Support Team for assistance.

If you use macOS, you don’t need to install a third-party client like PuTTY to connect to your hosting account via Secure Shell (SSH). Instead, you can use Terminal – a command line emulation program.

Instructions for Linux are similar.

Before you start, make sure SSH access is enabled for your hosting account.

1. Open your Terminal application:

You will see a window with a user$ sign and a blinking cursor. This is your basic command prompt.
From in here, you can establish an SSH connection to your hosting server:

To connect, you need to execute the following command:

ssh USER@SERVER -pPORT

USER: user you want to establish the SSH connection for. It can be either root (only for VPS and Dedicated servers) or cPanel username
SERVER: hostname/IP of the server you are connecting to
PORT: connection port – 21098 for a Shared server, 22 – for a VPS/Dedicated server

2. Now the computer will attempt to connect to your hosting server.
If it is your first time connecting to the server, you will see a message asking you to confirm the connection establishment. Type yes and press the Enter key to proceed:

3. You will be asked to input the SSH password (for root or cPanel account). Your cPanel login details (or root password) can be found in the Hosting Welcome email sent to you after the package activation. If you have difficulties finding the Welcome email, contact our Support Team for assistance.Type in the password and press Enter.

NOTE: The cursor will not be moving when you will be entering your password:

4. If all is good, you will see a line beginning with [user@server ~]$. This will indicate that the SSH connection has been successfully established:

The Terminal interface allows you to access an in-browser SSH application for direct command-line access within a cPanel session. In order to access cPanel Terminal, follow the next steps:

1. Make sure that SSH access is enabled for your account.

2. Navigate to cPanel >> the Advanced section >> the Terminal menu:

3. If you are opening this menu for the first time, the warning notice will be shown. Click on I understand and want to proceed.

This message won’t appear in future sessions.

4. Now you can run SSH commands using this interface:
That’s it!

Disabling root logins

Since the root user is granted all the privileges on the server, and exposing the root login possess a threat to your entire system, it may be a wise decision to disable root logins.
Here is how to do it.

Preparation stage: Make sure to create a user with Superuser AKA: sudo rights to perform all the necessary administrative actions. Once you are logged in to the server, follow these steps:

1. To create a new user, run the following command:

useradd -m -s /bin/bash -c “Admin”  techuser

Where:

Useradd is an actual command to create a user
-m – an argument which creates a user with a default home directory in the format /home/user (in this case home/techuser).

If you would like to use a different argument than the default directory, use -d argument instead of -m, and specify the desired directory e.g. /example/home/user)

-s  – allows specifying the shell for the user (in this case the shell is /bin/bash)
-c – comment addition. The actual comment here is ‘Admin’
techuser – an example username. Instead of techuser you can use any username you like, just be sure to modify all the commands above accordingly).

Set a password for the newly created user (make sure you set a strong, secure password).

NOTE: While typing the new password you won’t see any symbols appear, as hidden fields don’t show anything at all. If you hesitate about your password you can press Ctrl + U to empty the field and then start from scratch.

passwd techuser

Once you entered the password, you should receive the following output:

Now you need to assign sudo (Superuser) rights to your user. This process varies depending on the Linux distribution you are using.

Debian (also Ubuntu):

usermod -aG sudo techuser

CentOS (also CloudLinux):

usermod -aG wheel techuser

Now you can Test if your newly created user has sudo rights:
Switch to the new user you’ve created:

su – techuser

Prepend commands that require Superuser access with sudo:
For instance: sudo ls -la /root

You will be prompted to enter a password for your user which will be used to log in to the system and confirm sudo actions whenever they are required by the system.
If you did everything correctly, it will give you the file output:

However, If you are using WHM/cPanel, you can assign sudo rights to any cPanel user.  It is preferable to using the useradd command. To do so, once a cPanel account is created, you can go to your WHM >> Security Center >> Manage wheel group >>  Add a user to the wheel group.

Choose your cPanel username from the list, and click Add to Group.

2. Disable SSH login option for root:

Now open /etc/ssh/sshd_config. You can use nano text editor for this:

sudo nano /etc/ssh/sshd_config

Then find (either with or without “#” in the beginning of the line):

#PermitRootLogin yes

Instead set it to this:

PermitRootLogin no

Make sure the edited line doesn’t begin with #, as it will be considered just as a comment and will not take any effect.

You can edit your default SSH port in this file as well. See how to make these changes below.

Changing default SSH port

By default, the SSH port is set to 22.
Locate the following line in the same file /etc/ssh/sshd_config:

Remove # and change 22 to your desired port number. Though make sure you do not use the ports which are used by other systems ( i.e. 465,993 which are mail ports etc).

E.g:

In order to keep the custom port, make sure that the new port you set up is working. For the majority of firewalls, the ports up to 1000 are open by default. If you will be using higher numbers, make sure to open them manually, adding a corresponding rule to the firewall settings.

In order to Test the settings you should leave 2 ports opened:
Port 22
Port 22345
Once you log out and log in again using your custom port, and have made sure it is allowing you to connect, you may comment ( putting # at the beginning of the line) or delete the string with Port 22.

Save the changes and close the file. Press Ctrl + O to save. Type Ctrl + X to exit.

To apply the settings, the SSH service needs to be restarted. If you are logged in as a techuser (or your custom created one to replace root), you will need to use the sudo command to perform this action.

Depending on your distro and its version, the required command may be different, as well as the name of SSH service (sshd for Centos and CloudLinux and ssh for Ubuntu).
In the example below we use sudo systemctl restart sshd as we run CentOS 7.

Other variants if you run some other distro or version (e.g. Centos 6, Ubuntu 14.04 and older versions):
sudo /etc/init.d/sshd restart
sudo service sshd restart
sudo restart ssh

If you have turned off root login on previous stages, you will still be able to log in to your control panel with root details.
If you use a cPanel license for your server, you can disable password authentication using the SSH Password Authorization Tweak menu in the WHM panel.

NOTE: Once you press Disable Password Auth, all cPanel users will be able to access SSH only via SSH Keys.

Generate SSH keys

On your local machine, you need to have a pair of SSH keys (one public and one private).
Generate SSH keys on your local machine (applicable for Linux and MacOS):

ssh-keygen -t rsa

You will see this message:
> Generating public/private rsa key pair.

When you’re prompted to Enter file in which to save the key, press Enter. This accepts the default file location and name. Just be sure not to overwrite your existing SSH keys. You can find them using the command (you can cancel the creation of SSH keys by using Ctrl + C shortcut and then run the command below to see if you have any keys already):

ls -la ~/.ssh/
> Enter file in which to save the key (/home/you/.ssh/id_rsa): Press Enter.

At the prompt, type a secure passphrase. For more information, see Working with SSH key passphrases.

Enter passphrase (empty for no passphrase): Type a passphrase
Enter same passphrase again: Type passphrase again

The passphrase is used to protect your key. You will be asked for it when you connect via SSH. Generating SSH keys with no passphrase is not recommended for security reasons.
You can check the process of generating ssh keys below:

Once you have generated your SSH key, you will be provided with two keys. You can check them in your home folder in a directory called .ssh:

ls -la ~/.ssh/
id_rsa  id_rsa.pub

For Windows there are various pieces of software which enable you to generate SSH keys:

WSL (Windows 10) provides an experience similar to your regular Linux distro, you just need to activate WSL, install the distro software you like from Windows Store, and run it using these instructions. Once you install and run it, you can create SSH key pair in the same way you can on Linux (as shown in previous steps).

MobaXterm, ConEmu, and similar also allow you to simulate Linux Shell so that you can use SSH programs in the same way you do it on Linux (and WSL).

PuTTY is an SSH client that allows you to connect remotely to SSH servers, but it doesn’t simulate shell environment, so generating SSH keypair here is a different process. For this, you will need PuTTYgen that is installed along with PuTTY:

1. Go to Windows Start menu >> All Programs >> PuTTY >> PuTTYgen.

2. Click on Generate and start moving the mouse randomly within the PuTTYgen window.
3. Optional: enter a key comment, which will identify the key (useful when you use several SSH keys).
4. Type in the passphrase and confirm it. The passphrase is used to protect your key. You will be asked for it when you connect via SSH.
5. Click Save private key and Save public key to save your keys accordingly.

You can copy a public key to your remote SSH server right from the PuTTYgen window as shown in the screenshot.

Copying public key to your SSH server
You need to copy your public key to the server to a file called authorized_keys located in the same .ssh folder of your remote user on the server. There is a command in Linux and MacOS you can use to do this automatically:

ssh-copy-id -p your_custom_port_number techuser@yourserverIP

Or you can manually copy contents of id_rsa.pub (it’s important to copy contents of your public key, NOT the private one):

And then paste it in the authorized_keys file on your server (each new key begins on a new line, in case you need to add multiple keys in the future).
To edit the authorized_keys file on your remote server you can use this command once you are connected back to the server:

nano ~/.ssh/authorized_keys

Once changes are done, press Ctrl + O to save. Type Ctrl + X to exit
You will probably see all the pasted text in a single line, so it may appear differently on your screen.

If you have a cPanel license, it is possible to set up SSH Keys using WHM or cPanel.

WHM

1.Log into your WHM panel as root.
2. Go to Security Center >> Manage root’s SSH Keys >> Generate a New Key:

3.Specify the key settings:

Key Name: enter your unique key (in this example we used ncstest)
Key password: either enter or hit Generate Key
Password again: re-enter the password
Choose the type: RSA (slower to generate but faster to validate) or DSA (faster to generate but slower to validate)
Key Size: choose the Key size (the higher the number, the more security, but slower authentication speed)
And press Generate Key.

Once it is done, a pair of public and private keys are generated.
In order to use it for a login you need to Authorize the public key. To do so, please Return to SSH manager >> public_keys >> find out your keys and go to Manage Authorization.

On the prompted window, press Authorize.

Then, press Return to SSH Manager find the private key you have just created and copy it.

If you will be using PUTTY, you will need to convert it to PPK format. In order to do so, enter the password for your user and press convert.

To import existing keys, you can go back to SSH manager, and find the Import Key option. Import Key will redirect you to the following window. Please choose a name for this key and paste a desired (private or public) key you to import. It will also be possible to import a PPK key. If you don’t use one, you may leave this field empty.

CXS is installed by default on all our Shared servers, and VPS/Dedicated servers with Full Management. In other cases, you will need to purchase the license to use it. Aside from that, running the scan requires root access, so if you need to run ad-hoc scan on a Shared server or VPS/Dedicated server with Complete management, please contact us.

While reading this guide, please keep in mind the following:

• CXS is designed as a command-line utility. Most of its functionality is available via the WHM plugin, but we will keep the focus only on the Command Line Interface (CLI) usage.
• All text that appears in bold should be replaced with your own data.
• The purpose of CXS is to stop unprivileged user-level threats and viruses. It is not a rootkit scanner and it will not detect or combat malware that was able to gain root access to the system.
• Scanning system folders, beyond your home folder, is not recommended as it can result in false-positive results. Doing so with options like –quarantine may put the system into an unrecoverable state.
• The constantly-evolving nature of malware makes it impossible to give specific steps on how to evaluate whether or not a file is malicious. Before making any final judgements, make sure to do all the necessary research on your own.

Important locations and configurations

Configured and quarantined files are stored in the specified locations below:

CXS SSH one-line commands

One-line commands below can be used to scan single locations or home folders of a particular user. To make it easier for you to interact with the commands, some additional parameters were added.

The full list of the common additional CXS parameters can be found below:

CXS supports many other parameters that can be checked by running the following commands:

cxs --help

Or

cxs --help | less -R

They provide a full list of possible options as well as a detailed description of each.

Scanning the whole server

Before starting the scan for the whole server, first adjust the CXS ignore list, since there are some standard cPanel files located in /home folder that will trigger false-positive results. To do this, run the following command:

cat > ~/ignorelist <<EOF
/home/virtfs
/home/.cpcpan
/home/cPanelInstall
/home/.cpan
/home/.cpanm
/home/cpeasyapache
/home/latest
EOF

Now you can start the scan.

In order to run it in the background, save the report to the /root//full_server_scan file and send as an email to yourself once it’s over, use the following command:

cxs /home -B --report /root/full_server_scan --ignore ~/ignorelist --mail email@domain.com

Storing scan reports in the database

You can run scans with the –dbreport option to store the results in the database located at /etc/cxs/cxs.db. It has its downsides, like the way timestamps are handled and the more rarified format of the database (SQLite), but it still might come in handy.

The detailed instructions on how to use it can be found below.

1. Find the timestamp (epoch format) of the scan start:

date -d 'your timestamp' +%s

2. Check the scan time in the summary and add to it to the start moment:

echo $((timestamp + scan_time))

3. Enter the database:

sqlite3 /etc/cxs/cxs.db

4. Locate the report:

SELECT * FROM reports WHERE timestamp = 'timestamp';

Sometimes, the timestamp of the scan is off by a second depending on the exact start time of the scan. You can locate it by checking the closest timestamp available:

SELECT timestamp FROM reports;

Working with quarantined files and false-positive results

After performing a scan, you may notice that the CXS quarantined files are not malicious. In this case, it’s necessary to closely examine the files’ contents and decide whether or not you should modify, whitelist, or keep them quarantined.

Viewing quarantined files

Standard text viewing/editing tools (cat, less/more, etc.) allows you to view/edit contents of the file, but in order to safely view a quarantined file, we recommend using the following command:

cxs --qview /path/to/quarantine/cxsuser/user/malicious_file

If the file is located in a system folder (e.g., /opt, /etc, etc.), you will need to use –force option to be able to scan it:

cxs --force /path/to/quarantine/cxsuser/user/malicious_file

As a result, you will see the output that looks as follows:

Considering whether or not the file is dangerous

In our example, it’s easy to detect the malicious code; it stood out from the normal PHP code and we had access to the clean master version (since the file is a part of popular WordPress plugin).

Generally-speaking, however, this is the hardest part as malicious code is often obfuscated, encoded or otherwise not readable by humans. Due to the diverse nature of these exploits, it’s impossible to cover all. Therefore, we can only advise you to:

• Never restore/whitelist files if you are not sure what harm they can do.
• Whitelist only md5 checksums, not files or folders. This way only one specific state of the file will be whitelisted and further modifications will trigger CXS checks one more time. Otherwise, users will be able to put something that affects the whole server in that location, either by mistake or intentionally, and antivirus will ignore it completely.

File restoration and whitelist management

If you have detected and removed the malware part of the file, you must proceed with the required steps:

1. Run an extra scan to make sure that file is now safe:

cxs --force /path/to/quarantine/cxsuser/user/malicious_file

2. Restore it:

cxs --qrestore /path/to/quarantine/cxsuser/user/malicious_file

If it’s not possible to determine why the CXS treated the file as malicious, but you are sure that it is safe to use it, follow the next steps:

1. Find out MD5 sum of the file.

md5sum /path/to/quarantine/cxsuser/user/malicious_file

2. Add md5sum to whitelist:

echo “md5sum:md5sum_from_previous_command” >> /etc/cxs/cxs.ignore.user

3. Restore the file:

cxs --qrestore /path/to/quarantine/cxsuser/user/malicious_file

4. Restart CXS:

service cxswatch restart

or

systemctl restart cxswatch.service

Congrats! Now you know how powerful the ConfigServer Exploit Scanner (CXS) tool can be, helping you to effectively secure your server.

Active file scanning performed by CXS prevents malware exploitation of an account by deleting or moving suspicious files to quarantine before they become active. It can also prevent the uploading of PHP and perl shell scripts, which are commonly used to launch more malicious attacks and for sending spam.

Additionally, CXS allows you to perform on-demand scanning of files, directories, and user accounts to detect suspicious exploits, viruses, and resources (files, directories, symlinks, sockets, etc.). You can run scans of existing user data to find exploits that have been uploaded in the past, or using methods not included with active scanning.

Included with the CXS Command Line Interface (CLI) is a web-based User Interface (UI) which can help you:

• Run scans
• Schedule and edit scans via CRON
• Compose CLI scan commands
• View, delete, and restore files from quarantine
• View documentation
• Set and edit default values for scans
• Edit commonly used CXS files

CXS license orders have the following system requirements:

Control Panel: cPanel/WHM

Operating System: CentOS 7, CloudLinux 7/8, AlmaLinux 8

CXS is a commercial product that is sold and licensed strictly on a one-time per server basis, with updates provided for the life of the product. To order a CXS license ($60), please submit a ticket to our Billing/Sales department.

CXS license is installed for free for All VPS And Dedicated Servers with Managment on them

If the license is installed on the server, you can scan your account via the CXS scanner, feel free to follow these steps.
NOTE: Interaction with the CXS license requires root access. Since root access is not provided on complete managed servers, all the uploaded files are scanned automatically while all the inquiries related to ad-hoc scan, quarantine, and interpreting the results can be addressed to our technical support.

man – format and display the on-line manual pages
SYNOPSIS

         man [-acdfFhkKtwW] [–path] [-m system] [-p string] [-C config_file] [-M pathlist]
       [-P pager] [-B browser] [-H htmlpager] [-S section_list] [section] name …

DESCRIPTION

man formats and displays the on-line manual pages. If you specify section, man only looks in that section of the manual. name is normally the name of the manual page, which is typically the name of a command, function, or file.

The output of man ls command:

The apropos command can be used before man in order to find all the man pages for commands which contain a certain word.

The same purpose has whatis command. whatis – searches the whatis database for complete words. Example of using whatis command:

To review all man pages related to the command use -a option. For example: man nano -a

We offer Whois Lookup option to check details associated with a domain. Information contained within the lookup depends on the Registry to some extent.

However, for most gTLDs/new gTLDs you’ll see details like who a domain is registered to, when it was registered, when it expires, and where the DNS is hosted. For the majority of ccTLDs, you will have to go to the Registry’s website to get more information.

The amount of information available in a record will depend on the type of TLD, and the Registrar of the domain.
Domain Registrars usually allow their customers to change their domain contact information directly from their accounts (without needing to contact the Registrar’s customer support). Updates to Whois information may take up to 24 hours.

Some domain Registries allow domain owners to hide certain details in their public Whois records. They do this by replacing the Registrant’s data with the one of the Registrar or hosting company.

This feature is called Domain Privacy Protection, or domain privacy. For example, in a user’s public Whois record with domain protection, their personal email is substituted with a string that looks like a7b594eb9f5d43c123123c82484363f81.protect@withheldforprivacy.com
Anyone wishing to contact the user would send email to this address, which would be privately redirected to the user’s personal email.

Did you know?

The Core Hosting offers the privacy protection tool provided by the Withheldforprivacy.com company. We offer this service free of charge for the registration, renewal, transfer, and reactivation for domain names that support it.

That’s it!

For example the following IP addresses are in the same C class subnet:

4.4.3.5 and 4.4.3.118

Class B – first 2 octets are the same:

4.4.3.5 and 4.4.7.45

Class A – first octet is the same:

4.2.4.6 and 4.87.97.110

Also there are classless subnets that are used to isolate subnets that are out of A, B and C classes. There are several subnets provided for private usage and has no route on the internet, so called private networks. They are 192.168.0.0/16; 172.16.0.0/15 and 10.0.0.0/8 – for use on a local area network (LAN) – or others (public) – for use on the Internet or other wide area network (WAN); static (also known as a permanent IP allocation; it is always the same and is associated as a characteristic of the local IP module) or dynamic (temporary IP address, which changes every time you connect to your ISP; usually it’s dialup or DSL networks). Formally we’ve described current IP standard called IPv4 (based on number of octets) and new IP v6 standard are already in use/implementation. This newer IPv6 standard is planned to replace it and starting to be deployed. There are several organizations – regional Internet registries that assign Internet addresses for these 3 classes: ARIN, RIPE NCC, LACNIC and APNIC.

For more information regarding IP standardization and requirements, please, visit the following links:

http://tools.ietf.org/html/rfc950

http://tools.ietf.org/html/rfc1812

http://tools.ietf.org/html/rfc917

http://tools.ietf.org/html/rfc1101

http://tools.ietf.org/html/rfc1878

For WordPress, managed means we handle some basic administrative tasks, such as installing WordPress, automated daily backups, WordPress core updates, and server-level caching.

Here are some key features Managed WordPress offers:

• The latest version of WordPress is automatically installed.
• Automatic WordPress core updates.
• Performance-enhancing caching.
• Enhanced security through restricted file access.
• Secure access to your files and database with sFTP and phpMyAdmin.
• Automatic, daily backups (last 30 days).
• Integrated SSL is included for the life of your hosting account.
• One-click migration tool.

Because of these optimizations, there are also some limitations you should know:

• Managed WordPress does not support WordPress multisite networks.