How to make SSH work Faster?

Here are some tricks to boost your pro­duc­tiv­i­ty when work­ing withSSH.

Au­to Lo­gin

OpenSSH has a great fea­ture “key-based au­tho­riza­tion” which us­es RSA/DSA key pair to do au­tho­riza­tion in­stead of pass­word. With the help of it, lo­gin can be done au­to­mat­i­cal­ly.

Here are the steps:

  1. Cre­ate ssh key pair, if you have’t one. Check ~/.ssh. If you find a fine with nameid_dsa.pub or id_rsa.pub, you are done since the key pair is ready to use. Oth­er­wise, cre­ate it sim­ply by typ­ing ssh-keygen and fol­low­ing the in­struc­tions. Keep in mind that there are two kinds of key pairs, RSA or DSA. I al­ways use RSA. You can choose one on your own. If you choose RSA with oth­er op­tions as de­fault, you will getid_rsa and id_rsa.pub in ~/.ssh. The for­mer file is the pri­vate key and lat­ter one is the pub­lic key.
  2. Make sure your ~/.ssh is pri­vate. I want to em­pha­size that here that the pri­vate key, i.e. id_rsa, is the equiv­a­lent with your pass­word since peo­ple who can ac­cess this file can lo­gin the re­mote ma­chine eas­i­ly as they got your pass­word! So make it pri­vate first.
    chmod 700 ~/.ssh
  3. Trans­fer your pub­lic key to the re­mote ma­chine which you want to lo­gin au­to­mat­i­cal­ly. SCP may be a pre­ferred way:
    scp ~/.ssh/id_rsa.pub user@remote.machine.com:~/my_key.pub
  4. Ap­pend your pub­lic key to the ~/.ssh/authorized_keys on the re­mote ma­chine.
    cat my_key.pub >> ~/.ssh/authorized_keys
  5. Done! Check whether you can lo­gin in­to the re­mote ma­chine au­to­mat­i­cal­ly by sim­ply type
    ssh user@remote.machine.com

    on your lo­cal ma­chine. If it works, re­move the pub­lic key on the re­mote ma­chine.

  6. For geek­ers who’d like to do it in one-line fash­ion, here it is:
    cat ~/.ssh/id_dsa.pub | ssh -l user remote.machine.com ‘cat >> ~/.ssh/authorized_keys’

Even Faster

Even au­to lo­gin is set up, in some cas­es you have to wait for sev­er­al sec­onds be­fore the shell prompt bombs out. Still frus­trat­ing, right? In some worse cas­es, you have wait more than 10 sec­onds or even longer! Why? Each time you con­nect a re­mote ma­chine, sshd would like to use your IP ad­dress to ap­ply re­verse DNS lookup to de­ter­mine your host­name. If the DNS serv­er goes slow, it may take sec­onds to re­turn the re­sults. The longer the lookup takes, the longer you have to wait.

Two tricks can be ap­plied to solve this prob­lem:

  1. Ed­it /etc/hosts on the re­mote ma­chine and add the IP ad­dress of your lo­cal ma­chine to it with an ap­pro­pri­ate host­name. So if you lo­gin the sys­tem, your IP ad­dress is re­solved lo­cal­ly, which is def­i­nite­ly faster.
  2. Dis­able DNS lookup on the re­mote ma­chine. Ed­it /etc/ssh/sshd_config and add one line:
    UseDNS no

    Restart the sshd serv­er then. If ev­ery­thing goes well, you will see the save of time.

Both tricks re­quire root priv­i­lege. If do not have root ac­cess, ask your ad­min­is­tra­tor to help you.

Trou­bleshoot­ing

Use ssh -v or ssh -vvv to out­put de­bug in­for­ma­tion and di­ag­nose the prob­lem.

Advertisements

How ssh works

Ssh works by the exchange and verification of information, using public and private keys, to identify hosts and users. It then provides encryption of subsequent communication, also by the use of public/private key cryptography.

SSH is designed to provide a secure method of authentication and data transport. This is accomplished via three main stages during the connection setup: SSH-TRANS, SSH-AUTH, and SSH-CONN.

As a user, you generate an “identity” on the client system by running the ssh-keygen program. This program creates a subdirectory $HOME/.ssh and inserts in it two files named identity and identity.pub which contain your private and public keys for your account on the client system. This latter file can then be appended to a file $HOME/.ssh/authorized_keys that should reside on any/all servers where you will make ssh connections.

As a system administrator, you generate a public and private key pair for the system itself. By use of this information contained within the system itself, the possibility of someone spoofing the system’s identity by faking IP addresses or munging up DNS records that associate IP addresses and domain names is removed. You would have to break into the system and steal its private key in order to sucessfully pretend to be that system. This is a big improvement in security.

Once you generate your public/private key on your local system you can place your public key in the authorized_keys of the server so you can bypass the login procedure and directly login into the server without the password.

When you ssh to a machine by the following command :

ssh -l admin -p 78 svrxx.domain.com

The first step performed is authentication of the server to the client and client to the server i.e first the server checks whether its publci key is contained in the file $HOME/.ssh/known_hosts this procedure is known as host validation if the key is present in the known_hosts file it will proceed with the subsequent authentication.

Else if it is not matching or not present will display the following message :

The authenticity of host ’svrxx.domain.com (67.75.52.50)’ can’t be established.
RSA key fingerprint is bd:e7:14:30:13:ba:74:77:47:b3:2a:b3:a1:07:2e:7a.
Are you sure you want to continue connecting (yes/no)?

Once you say yes then the public key of the server will be placed in the known_hosts file and you will not see this message again.

And once the host validation is complete the subsequent communcication will be encrypted using the private key that was generated from ssh-keygen command.