The Magnet Blog

magnet June 23rd, 2008

If you’re reading this article, you probably use SSH (Secure Shell). If you don’t know what SSH is, or you want to know more about it, go to SSH or type “man ssh” on a Linux/Unix environment. Typical implementations of SSH use a username and password to authenticate users. This method has considerable drawbacks:

* Any password can be guessed over time

* Most people don’t watch their secure.log for failed login attempts

* By default, the root account may be remotely logged into via SSH, leaving the system completely vulnerable if someone is able to brute-force the login credentials .

If you run SSH on the standard port 22/tcp, and it’s listening on our public UNT network, and password authentication is enabled, then malicious users outside the UNT domain are attempting to log in. By trying every possible character combination (and especially common ones), they will succeed eventually.

$: So what are SSH keys ?

Ans:* SSH keys are a pair of cryptographic keys used to authenticate users instead of (or in addition to) a username/password. One key is private and goes on your source device in the ~/.ssh directory, and the public key goes in the destination device’s ~/.ssh/authorized_hosts file.

$: How long does it take to generate SSH keys ?

Ans *:- Just Seconds …

But there are Two of them RSA & DSA !!!!!

$: So do I use RSA or DSA ?

Ans *:- RSA has undergone more public cryptanalytic scrutiny, and

is tried and true.

DSA is based off a different encryption algorithms (privately developed by the NSA), and can sign faster, but verifies slower. Keep in mind this means 300 milliseconds of difference. RSA can be used to encrypt or sign. DSA is only intended for signing.

$: What are the commands to create and implement SSH keys ?

For this instruction set, I’ll use RSA for simplicity. To use DSA instead, simply specify “-t DSA” when you use ssh-keygen.

>>First, type the ssh-keygen command to generate your ssh-key pair.

# ssh-keygen -t rsa

Generating public/private rsa key pair.

>>At this prompt, hit enter unless you want to specify a custom name.

Enter file in which to save key (/Users/exampleuser/.ssh/id_rsa):

Now you’ll be twice asked to create a passphrase. If you don’t use one, you can SSH to another machine without having to type anything. However, if anyone else ever has your private key, or a copy of it, they’ll have all the same connectivity privileges that you do. For this reason, we recommend that you use a passphrase, and you can use ssh-agent if you wish to only type your password once per day. If you are a system administrator and want to use blank passphrases for easy automated connections, you can bind certain commands directly to the SSH keys to limit privileges of those auto connecting accounts.

# Enter passphrase (empty for no passphrase):

# Enter same passphrase again:

After this, you’re done with creating the keypair. Now all that’s left is copying the *.pub key to your remote (destination) computer.

>>The following command will securely transmit the key to the destination host.

# scp id_rsa.pub user@host:/home/username/.ssh

OR

# scp id_rsa.pub user@ipaddr:/home/username/.ssh

>>Now SSH into that remote machine, and move into the .ssh directory.

If you don’t see a file called “authorized_hosts” or “authorized_keys“, then create it and move the *.pub key into it with the following command.

# cat id_rsa.pub > authorized_keys

If the file already exists and may contain other keys already, then type this to append your key to the existing contents.

# cat id_rsa.pub >> authorized_keys

You may need to chmod 700 the destination’s ~/.ssh directory and chmod 600 the actual authorized_keys file. These permissions requirements may vary depending on your UNIX/LINUX variant.

Now you should be able to ssh from your source to destination computer without having to use a password. At this point, to completely thwart brute-force login attacks, you can edit your destination host’s /etc/sshd_config file to disallow password authentication.

!!!! BE CAREFUL DOING THIS REMOTELY; CONSOLE ACCESS IS RECOMMENDED. BACK UP THE ORIGINAL SSHD_CONFIG FILE FIRST. !!!!

#PasswordAuthentication yes
PasswordAuthentication no

>>To Debug problems with SSH key connections, you can try the verbose switch with SSH.

# ssh -v user@ipaddr

Thank you

Magnet Systems Team

• Technology