How To: Update your hosts file

Firstly the /etc/hosts file is the primary resource for name resolution without DNS. The /etc/hosts file has priority over the DNS in the process of addressing network nodes. This is a table lookup file of host names and IP addresses. Our host name as well as others may be stored, in this file which we may edit.

The general file format should look like the following, and can include multiple host names for one IP:

       # The following lines are desirable for IPv4 capable hosts
       127.0.0.1       localhost

       # 127.0.1.1 is often used for the FQDN of the machine
       127.0.1.1       thishost.example.org   thishost
       192.168.1.10    foo.example.org        foo
       192.168.1.13    bar.example.org        bar

       # The following lines are desirable for IPv6 capable hosts
       ::1             localhost ip6-localhost ip6-loopback
       ff02::1         ip6-allnodes
       ff02::2         ip6-allrouters

So we use our favorite text editor, and update this file to fully implement any recent network updates.
We may also use the /etc/hosts file to include address changes to our LAN and implement network resolution restrictions.

If we remove a host name from /etc/hosts, we also will potentially render a service inoperable due to a defunct host name. Therefore each administrator may consider system integrity, with respect to any installed software (i.e. software may not start properly, without a valid host name).

You can also alter the order of name resolution, in the case you find /etc/hosts having priority to be inconvenient. The /etc/nsswitch.conf file can be edited, and should contain an entry like the following:

        hosts:          files dns

Given these options, we can take a flexible approach to managing the systems host name resolution.

How To: Change a hostname in *nix

The hostname of most Linux and UNIX systems is a unique identifier set during OS installation. The process of changing this hostname can be accomplished through several methods.

Step 1: Checking the Current Hostname

Before you make any changes, find your current hostname. Use the following command:

hostname

 

Note alternatively you can use 'cat', 'echo', or 'printf' to print hostname too:

echo "$HOSTNAME"

 
printf "%s\n" $HOSTNAME 

cat /etc/hostname

This command will display your current hostname.

 

 

Note there is another command 'hostnamectl' which will print hostname, along with the Chassis, Machine ID, Boot ID, OS (Operating System), Kernel, Architecture, Hardware Vendor & Model:

 

hostnamectl 

 

This command will display additional information your current hostname and the machine.

 

Step 2: Changing the Hostname Temporarily

If you want to change your hostname temporarily (meaning it will revert back to the original after a system reboot), use the following command:

sudo hostname new_hostname

Replace "new_hostname" with your desired hostname.

 

 

Step 3: Changing the Hostname Permanently

To permanently change your hostname, you'll need to edit a specific file (/etc/hostname). To do this, use the nano text editor with the following command:

sudo nano /etc/hostname

hostnamectl

Once inside the file, delete the existing hostname and replace it with your new one. Save and exit by pressing Ctrl+X, then Y, and finally Enter.

Note: In some Linux distributions, you may also need to edit the /etc/hosts file for changes to take effect properly.

 

Step 4: Reboot and Apply Changes

For these changes to take effect we will complete a system reboot, use the following command:

sudo reboot

Now, if you check your hostname again using the "hostname" command, it should display your new hostname.

Please refer to your distribution's documentation for the most accurate instructions. 

To finalize your changes in the entire system, see the next article:

How To: Update your hosts file (it bypasses DNS)

 

Using the RSA Algorithm for Encryption and Signatures

During performance testing DSA is actually faster during signature generation, but slower during the validation process. Suprised? The title of this article is not misleading. With DSA it is also slightly slower when encrypting, but faster when decrypting data so security here is very close to RSA at equal key lengths.

However, since the RSA algorithm is based on the idea that large integer factorization is "difficult". Within the DSA security mechanism is an example of the discrete logarithm problem. ECDSA utilizes elliptic curve cryptography in a variant of DSA.

There is no clear winner. However, we can remember that the NIST Special Publication 800-57 (Jul 2012) recommends 2048-bit private keys. This will be important later, as it will be a factor which will elucidate the reasons for my recommendation.

If you have OpenSSL installed on your machine, you may execute :

openssl speed

You will see that the statements discussed in this article are true. Except that we did not mention that verification is what you want to be the fastest. The signature only happens once, but the verification happens an indefinite number of times. RSA also supports out of the box encryption, whereas DSA is dependent on third party encryption and is slower here as well.  However, DSA is faster at decrypting so we are still only tipping the scale a tiny bit.

However, for commercial entities considering organizational security policies which will last into the future should consider RSA or ECDSA. Overall RSA is clearly the winner for the moment, even though ECDSA is actually computationally lighter than all three it is not traditionally supported (RFC 4251) for SSH. Also, being a young encryption algorithm; it has had some serious critical vulnerabilities in the recent past. Most professionals are steering away from using this type of key for the time being.

In commercial terms, RSA is clearly the winner, commercial RSA certificates are much more widely deployed than DSA certificates.

Now we reach the final decision. A DSA key has to contain a 1024-bit keystrength in order to comply with NIST FIPS 186-2.  Unfortunately, while longer DSA keys are possible (FIPS 186-3) ssh-keygen restricts you to 1024 bits. When you take this article into consideration, we are no longer able to reasonably secure data with 1024-bit keys for either RSA or DSA.

How To: Manage Digital RSA keys for SSH

Now each organization must ask itself roughly about: digital key creation and expiration. Does the client create the key pair? All the private keys have a passphrase? If so, what's the minimum length? Do the keys expire? What types of keys are allowed/accepted? The private keys can be copied and then cracked so these are all things to keep in consideration. In the IT world, it is important to stay abreast of security and on ahead of new vulnerabilities.

Passphrases that have also few (or too easily guessed) alphanumeric characters (including spaces) don't last. Changing the password in one private key doesn't changes it in all other copies either. In other words, changing the passphrase in the "private" official key doesn't create a ripple effect that changes the passphrase in all other copies.

You will need to also figure out your key strength.

Right now, there is no serious reason to prefer one type over any other, assuming large enough keys (2048 bits for RSA or DSA, 256 bits for ECDSA). You may specify the key size in ssh-keygen using the -b argument.

ssh-keygen -t rsa -b 4096 ~/.ssh/id_rsa

A remaining question to ask, is: how will your organization associate any key pair with each specific user? Will they use one private key to access all of your infrastructure? Will there be a separate key for each system? How many keys are allowed to access each account? What kind of accounts are allowed to be shared? This organization specific detail is best mapped  out with a security professional.

How To: Create a new RSA keyfile for SSH

When you consider creating a new RSA or DSA keyfile, you do it with the knowledge that it will provide increased security when logging into a server using SSH. Requiring a RSA key as a security credential in the SSH authentication process is a more secure access management policy. Properly managing your credentials to maintain access and security can prevent problems, and increase profitability. 

There are at least three potential security related problems with traditional SSHD configuration.

1. Credential loss/theft
2. Potential Bruteforcing
3. Out of date access

We also discussed some solutions for eliminating and minimizing the risk of these problems.

1. Encrypted credentials (PGP encrypted username, password, key file)
2. Requiring a key, as well as a username and password
3. Rotating keys, audits

For those of you who are new to ssh keys, you can create a create a new key easily using the ssh-keygen command. This command allows the generation, management, and conversion of authentication keys. You only need to enter the ssh-keygen command to create an RSA keyfile, where the -t flag is used to specify the type of key to be generated, e.g.

ssh-keygen -t rsa
ssh-keygen -t rsa -f ~/.ssh/id_rsa         (default location)

When creating a new RSA key you can choose to leave the passphrase blank; press enter when asked to put in a passphrase. This will allow you to log into an SSH server without entering a passphrase. For stronger security add a second factor of authentication on the private keyfile and choose a passphrase.

How To: Requiring RSA keys for SSHD

Many organizations or individuals make a best effort to prevent hackers from gaining access to their systems. However, some don't consider what kind of damage can be done when someone has obtained their password, using the traditional or default SSH daemon configuration.

In the case you are using a key alone, or a password -- when someone obtains either piece of information they can access your account through SSH. You can use PGP to encrypt your private key or an encrypted password database for your password, and always use a password that is never stored to add an additional layer of security. However, with both methods of authentication you have an additional piece of information a hacker must obtain to gain access to sensitive information.

Ignoring security leaves a system at the greatest risk to the most severe attacks. A strict access control schema for systems with sensitive data is essential even for when only one person is accessing that system. Investments into proactive security far outweigh the losses that happen with a breach, and the result is an overall increased profitability. If you are running a server that allows access for your organization only then this is the ideal place to implement this SSH security schema.

You can configure your SSH to require RSA keys, in sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

and

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

and

UsePAM no

This makes it virtually impossible to brute force your account. If your organization or personal best practice does not include key management on your systems then it may be time for an adjustment in your security posture. Out of date keys belonging to accounts which no longer require access, or have too much access can prove problematic. Key management policies should be robust and require keys to be rotated out and audited on a regular frequency to eliminate any out of date security credentials, and find any accounts with access that is no longer required.

Seasons Greetings!

Hi there! I'm Dan and I'm a new addition to the community staff. I'm used to the cold winters of my hometown London, in the UK this time of year. However, I'm currently residing in lovely tropical Bolivia and everyday is a party, especially these last few weeks. Tonight, of course is the biggest party of all!

I feel the need to really take time to appreciate everyone around me, after not being crushed by some huge intergalactic alien 10 days ago. I'm grateful to share my joy of the new coming year (and the non-destruction of the earth!) with you all.

Here at Recompiled Networks we're working hard to improve our services and to provide quality to all of our customers all year round. While we sit around the fireplace, sharing good moments with our families and friends -- we can't help but think of all our customers. So as this year ends, and a fresh one begins, we hope success and prosperity comes to you, and your loved ones.

Thanks for being with us, have a happy new year!