Answered by the Webhosting Experts
Tags +

Managed Services
at Hivelocity

Bare Metal Shouldn’t be a Grind
Let Hivelocity take the busy work out of your daily server maintenance with our Managed Services plans. Choose from 1 of 6 different managed service offerings. Standard and Premium plans available.

Questions about something specific? Chat now with one of our expert account managers and learn which plan is right for you and your customers!

With Managed Server Technicians on-site 24/7/365, your server is always in good hands.

Tags +

How can I secure / increase the security of SSH?

There are a few adjustments that can and should be made to the default SSHD configuration to increase security. Traditionally, this has been especially true of RedHat-based systems, which included weak default configurations. The main point of interest is the /etc/ssh/sshd_config file. To cause changes made in this file to take effect, SSHD will need to be restarted or sent a sighup. This can be achieved on Linux systems which use SysV init scripts like:
# /etc/init.d/ssh restart

# /etc/init.d/sshd restart

On FreeBSD systems there is often an init script located in /etc/rc.d :
# /etc/rc.d/ssh restart

In any case, you can just send the sshd process a sighup:
# kill -s HUP `ps aux | grep sshd | awk ‘{ print $2 }’`

As far as the settings concerning security, the first to look at is the port which SSHD listens on. There is a lot of debate on this matter, but often it is recommended to change the default port away from 22 to a random unprivileged port, the higher the better. While a simple port scan will still find SSHD running on a server, moving the default port will field many automated probes and brute-force attempts. To change this, find the following line:
Port 22

And simply change the 22 as previously mentioned. You can limit the address which sshd listens on with the “ListenAddress” directive. Typically this is commented out by default; if you have several IP’s available to you, you could tell it to only listen on one which is being used for nothing else, or you could set it to only listen on an IPv6 address:
ListenAddress xx.xx.xx.xx

Next is the “Protocol” directive, which tells SSHD what protocol to allow. Protocol 1 is deprecated and known for its many security issues, so this should be limited to protocol 2:
Protocol 2

The “HostKey” settings typically include both RSA and DSA keys for protocol 2, and may also include an RSA key for protocol 1. DSA keys are currently considered more secure, so by removing the protocol 2 RSA setting you force the daemon to use the DSA key. The “PermitRootLogin” directive is another which should be set to “no”. This means you will have to ssh in as a regular use, then use the “su -” command to become root. It also means no one else can ssh into your server as root:
PermitRootLogin no

It is also highly desirable to setup key-based authentication. With PKI, a three-way challenge-response handshake is used, and if you also specify a passphrase during key creation, this complicates matters even more. Full details on setting this up can be found in the ssh-keygen manpage:
$ man ssh-keygen

Of course, if you’re connecting from a windows machine, the setup may be rather more complex. You’ll want to consult the documentation provided with the SSH client which you’re using to connect. Another setting of interest is “PasswordAuthentication”. With PKI setup and this set to “yes”, logging in via the standard password is still permitted for those who do not have a key infrastructure in place. Setting this to “no” forces PKI. While PKI is not the only option for replacing plaintext passwords, it is a good, strong method. There is also Kerberos, GSAPI, and PAM can also be added as another mechanism. For information, consult the sshd_config manpage:
$ man sshd_config



Need More Personalized Help?

If you have any further issues, questions, or would like some assistance checking on this or anything else, please reach out to us from your account and provide your server credentials within the encrypted field for the best possible security and support.

If you are unable to reach your account or if you are on the go, please reach out from your valid account email to us here at: [email protected] We are also available to you through our phone and live chat system 24/7/365.

Rapid Restore

Backup your entire server’s data every night and have access to 5 days of rolling restore points.  Restore your server’s data, OS and configuration any time you need it.

Our Rapid Restore service saves the day during accidental data loss, hardware failures and virus contraction. Simply pick your recovery point and restore the data from that day. 

DDoS Protection

While our competitors may advertise DDoS protection, most often, they are merely implementing easily evaded router rules or simply black-holing targeted servers. They consider this “DDoS protecting their network.” However, neither of these solutions should give comfort to any online business. Should your site be attacked, chances are likely both of these options will end with your server being taken offline. At Hivelocity, we take the responsibility of keeping your servers online very seriously. For this reason, we offer two very serious forms of DDoS protection.


Every solution we provide includes our Filtering Edge of Network System (FENS). FENS is a series of proprietary systems that proactively monitors and protects the entire Hivelocity Network from most common Denial of Service (DOS) and Distributed Denial of Service (DDoS) attacks.


For an extra fee, you can enhance your server’s protection further with the addition of our Server Defense System. Our Server Defense System sits in front of your server, inspecting inbound data and looking for malicious traffic. The moment an attack is detected, it instantly begins scrubbing each data packet. Hivelocity’s Server Defense System delivers business continuity even in the face of massive and complex attacks.

Our Server Defense System is like adding an alarm and armed guard to your business, alerting you to and destroying anything attempting to jump that fence. Our Server Defense System utilizes internally developed proprietary systems in addition to Corero’s Threat Defense Smartwalls for data packet scrubbing. Each of our data centers is a scrubbing center with Corero Smartwalls on-premise, allowing us to provide on-prem zero-lag data scrubbing.

SSL Certificates

The security of your online commerce and protecting your customers’ data is as important to us as it is to you. When your customers see the green bar, they will know their connection to you is protected. We offer single domain, multi-domain, and wild-card certificates.

We offer industry leading 128-bit encryption certificates, allowing you to conduct e-commerce with complete security. Inspire confidence in your customers by displaying any number of seals and indicators certifying that your site is secure.

Load Balancing

Adding this service to two servers with identical content will allow you to distribute your load evenly across your hardware. Don’t lose business because you couldn’t handle the demand. Load balance and handle your biggest resource spikes with ease.


Stop attacks, prevent unauthorized access, and achieve regulatory compliance. Our Juniper hardware firewalls offload the work so your server never has to consume resources protecting itself from malicious traffic. A single firewall can be used to protect multiple servers.

Cloud Storage

Cloud storage offers users redundancy and easy accessibility, ensuring your data remains secure and readily available. Scale to as much as you need for only a 20¢/GB.

Cloud Storage is distributed and replicated across many servers, protecting your data from hardware failure. Highly scalable, it can handle thousands of client connections via TCP/IP. Connect to your virtual drive with SFTP, FTP, and SSHMount and in the future NFS and AFP. Cloud Storage is based on a stackable design which is upgradeable up to 2TB per instance.