剑三狼牙情报箱没有:SSH Public Key (/w RSA) Authentication and SSH Tunneling – Part 1

We can say that the primary advantage of the public key authentication is a higher level of security being provided as it doesn’t need a password input that will be transferred over the network and as the “private” one which constitutes the public-private key pair doesn’t need to be transferred or revealed to remote site or a 3rd party during the authentication process or in any time period.

Especially if clear text password authentication is entirely disabled and the private key is protected well, we’ll be risen to a satisfying level of security owing to the authentication process that shall only be enforced bound to this key. Also it can be valuated as a method that will ensure convenience in addition to achieving sufficient security for access from the public areas, particularly for people that are in need of a frequent mobile remote management under circumstances where a restriction via static IP address can not be applied within both a firewall at a gateway or with just ssh-wrapping on the server side. Moreover, contrary to clear text password authentication and unencrypted data transfers, practicabilities such as setting prevention to brute force attacks and defense against man-in-the-middle attacks (where public key authentication is combined and used with ssh tunneling), automation of authentication process, distribution and management of the authorization between different user accounts can be listed as its other pluses.

Among encryption algorithms, ones that use the same secret key for both encryption and decryption are called symmetric algorithms. Within the framework of “public key” cryptography, ones that use a key for encryption and a separate key for the decryption are called asymmetric algorithms. AES (Advanced Encryption Standard), RC2, RC4, DES (Data Encryption Standard), 3DES (Triple-DES), IDEA (International Data Encryption Algorithm), BLOWFISH, TWOFISH are symmetric algorithms and when they’re used, both parties (client and the server) share the same secret key. For continuity of the security, that single key must be protected. In consideration of the necessity of shared usage of the relevant key, while especially transferring encrypted data to excessive targets, no matter how so secure the key is distributed over the network whenever a single user compromises or loses the key hence all the client keys involved inside the relevant communication substructure and foregoing communications are risked, that key must be regenerated and redistributed.

The methodology of authentication by RSA (or alternatively DSA) which is an asymmetric public key cryptography algorithm leans on the key pair that is generated on client system. Public key can be seen by everyone and is only used for encrypting the data. Private key only steps in during the decryption of data encrypted by matching public key. In order to achieve the authentication, public key has to be copied to SSH server that is needed to be accessed and has to be appended to a file (default $HOME/.ssh/authorized_keys) which contains the list of authorized keys. This file’s location is specified by the ssh server configuration (sshd_config). In this way, by creating only one key pair we can distribute public key to unlimited number of servers and accomplish authentication on multiple servers. In this context, private key is the one that must actually be protected.

By reason of complicated mathematical calculations, computation speed of asymmetric algorithms is much slower and the resource usage is plenty more than the symmetric ones. Therefore in practice, a combination (e.g. RSA/IDEA) leaning on the utilization of the asymmetric methods during the authentication process, where the data traffic is not heavy thus there is no need of high speed despite the preservation sensitivity of the key, and the utilization of the symmetric ones for the encryption process of ongoing data flow would be logical to prefer and use. In order to benefit by the advantages of both systems, modern hybrid cryptosystems (SSL, PGP, GPG) that are constituted by combining the convenience of public key cryptosystem with the efficiency of symmetric key cryptosystem bottoms the distribution of the symmetric keys encrypted by the asymmetric algorithms. The bulk of the encryption work is committed by the symmetric keys in hybrid cryptosystems.

Because we shall be doing an authentication at the beginning of the session while connecting to our SSH server, we will be acting in accordance with public key cryptography and will be using RSA algorithm in light of the advance information I briefly conveyed thus far.

In general, we may define the configuration aspect with the diagram shown below.

We have to generate public-private key pair at first. For this purpose, we will use SecureCRT terminal emulation software which we will also use while making connection to SSH server. You may pick a free software like PuTTY if you like.

We’re running the Public key generation wizard and selecting the type of public key as RSA.

Even though the passphrase corresponding the private key is optional as the private key will be kept on the client side solely, a passphrase surely have to be provided and the usage must be prevented without this password against especially the probability of intrusive physical access to key itself and indirect access to the remote servers granted with this key. Furthermore, for particularly serious implementations, it is recommended to pick the password in accordance within the known common criteria of strong password generation; without using personal details like username, name-surname, birthday, address/geographical location, dictionary words, repetitive or sequential chars/numbers but instead using lengthy (~min. 12 characters) combination of numbers + symbols + upper and lower case letters that will have a high entropy value.

We’re setting our key length as 2048 bits.

We’re moving our mouse inside the wizard window untill the first bar fills up in order to provide the random input that is needed for key generation. Then, we’re waiting the key generation to be finalized.

We’re selecting the “OpenSSH Key format” if OpenSSH application is running on the server that we want to get connected and we’re designating the name for key pair with the folder path where the keys will be saved. We can generate the key in standard format and do the conversion by hand on SSH server if you’re using an older version of SecureCRT (e.g. version 5.2) which doesn’t have a format option or if the terminal emulation software you use hasn’t got a feature to convert the keys to OpenSSH format. I will touch this point in the next step while I speak for the server side configuration.

When we completed the wizard instructions, our key pair will be saved under the designated location. Now we can continue with the configurations that have to be made on the server side. For this purpose, we have to transfer our public key which is Identity.pub to our server via any secure method. Alternatively, we can copy the content of the key file opening it locally with notepad and past it inside a file which we create with same name on server;

Copy

ONLY THE HIGHLIGHTED KEY DATA PART IN STANDARD KEY FORMAT:

---- BEGIN SSH2 PUBLIC KEY ---- Subject: Sezgin Bayrak Comment: "sbayrak@SBMobile" ModBitSize: 2048 AAAAB3NzsC1yc2EcA8ADAQABAA5BAQDJrOQ7BkfG9NuWqU4nAK6W5/UsDu6bLy8Y g9IxfbE/lc7QjA9p9T8aGAG03JSLJWSr4rCflm8VUsqSkh24XxyWx5829OD3OVOO 1tbDQLaF84LefC5k6eLtOsBniLlh5DRoLx4YUZtzaeGHd5EWgINSDK22VCIonLTZ r4h6dDmp6Gn3aHZkAP5mQwhi/lXV3Ys5BaefyVkulpXCbaprs/jOMw5TyWUrsm4S 4Gjluoxc/OIAD5Sc6UMTVgj438JxwVbDfgNbERAzvpe+sccTREqZ/Q9Z8hFqc1FB u+G+OkstH0/ZVGxLxOfeAA6FpCvsYjCFe39cDFEoa4gJu/SLXDHJ ---- END SSH2 PUBLIC KEY ----

ALL THE CONTENT IN OPENSSH FORMAT:

ssh-rsa AEQAB3NzsC1yc2EcA8ADAQABAAABAQDGN9ZZl+LKRd7JYWmKsdh9cdnYYrljsFAw7LrM9y3puCsr3iOQBNQc74Ss316gXU9e/nQ2jl/6CI4t4f9UF XiR54scdJB5Ds4dDjsfCPOC/o9hBQ1wf/U9GUmvLS1giV/Xd2KAYPle6KokcGGyadPkrZksjI8I88LB1gqD6IF560Qvr39risYdOZyPbGxVS9HFyDMjUKSJ9Z A3Kn10yn0yjno97kKPuZQFjjKUfkQrmTUXFPQitKW5VELICQ7Fge41t5u2vbnlB5owChadRY4zBCO9/t05D1V4uIp2F6ItJimCN8mzA7H/mAwXkXKGRZ5eqLD XSUHO/VdiQ7vBFRBN sbayrak@SBMobile

and complete pasting by using the command shown below.

# cat > /home/user/Identity.pub <paste key data here> ^D (CTRL-D)

Afterwards, we have to create “.ssh” folder under /home/user directory location if it doesn’t exist and we have to append our key file to /home/user/.ssh/authorized_keys file that we’ll create. We mustn’t forget ownership and permission settings in order to prevent other users to access key data. I used wheel group assuming that our example user belongs to this group. Change it appropriately for your user in implementation;

IN STANDARD KEY FORMAT:

We will append our key (which is in RFC 4716 Secure Shell (SSH) Public Key File format) to authorized_keys file converting it to OpenSSH format by using ssh-keygen command;

# cd /home/user/# mkdir .ssh # chown user:wheel .ssh # chmod 700 .ssh # ssh-keygen -i -f Identity.pub >> .ssh/authorized_keys # chown user:wheel .ssh/authorized_keys # chmod 600 .ssh/authorized_keys # rm Identity.pub

If you preferred manually copying and pasting method from the notepad and paste unessential character parts instead of absolute key data by mistake or if you forget to delete these parts after transferring the key to server via ftp, you’ll get “input line too long.” error when you run ssh-keygen command highlighted above at 4th line. At that moment make sure that you just copy and paste only the key data as shown earlier.

IN OPENSSH KEY FORMAT:

As our key is already in OpenSSH format, we’ll append it directly to authorized_keys file.

# cd /home/user/# mkdir .ssh # chown user:wheel .ssh # chmod 700 .ssh # cat Identity.pub >> .ssh/authorized_keys # chown user:wheel .ssh/authorized_keys # chmod 600 .ssh/authorized_keys # rm Identity.pub

Now by making couple of modifications inside OpenSSH server configuration file, we’ll enable our server to let authentication held by RSA public key. After being sure that public key authentication takes place, we’ll disable password authentication completely. The said configuration file is /etc/ssh/sshd_config on FreeBSD but it can be found at various locations such as usr/local/etc/sshd_config , etc. at other *NIX derives. Change the relevant parameters in file as shown below and save;

RSAAuthentication yes AuthorizedKeysFile      .ssh/authorized_keys

In order to have changes take place, locate and restart the sshd deamon;

# ps aux | grep ssh root    73467  0.0  0.1 25108  3864  ??  Is   11:30PM   0:00.00 /usr/sbin/sshd# kill -HUP 73467

To establish a SSH connection to our server and make the authentication done by our new public key, set the authentication method as PublicKey inside Session Options after creating a new connection on SecureCRT. Then specify the recently created Identity.pub key location in its properties.

When the authentication for the connection succeeds, you’ll notice the log below at server side. Hereafter you can use public key authentication with RSA regarding further connections.

# tail -f /var/log/auth.log Jan 29 22:43:08 your_ssh_server sshd[59286]: Accepted publickey for user from y.y.y.y port 64723 ssh2

As we feel confident of the public key authentication, we can completely disable password authentication by switching the parameters inside sshd_config to below ones. You may totally loose connectivity to your server if you switch them before completing the public key test successfully!

PasswordAuthentication no ChallengeResponseAuthentication no# ps aux | grep sshd root     976  0.0  0.1 25108  2916  ??  Is   17Feb10   0:00.37 /usr/sbin/sshd# kill -HUP 976

All we spoke till now were about how to generate and use public key on a Windows client. Now let’s touch on how the same exercise would be accomplished when a *NIX OS will be used as a “client”. At first, let’s check whether OpenSSH is installed as a ssh application;

client# ssh -V OpenSSH_5.2p1 FreeBSD-20090522, OpenSSL 0.9.8k 25 Mar 2009

We’ve to create “.ssh” folder if it doesn’t exist under /home/user directory location;

# mkdir .ssh # chown user:wheel .ssh # chmod 700 .sshclient# cd /home/user/.ssh

Let’s generate 2048 bits RSA public-private key pair inside this folder (as mentioned before, it is certainly important to take care not to leave empty when it is asked to provide a passphrase for the private key in terms of security);

client# ssh-keygen -b 2048 -f id_rsa -t rsa Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): passphrase Enter same passphrase again: passphrase Your identification has been saved in .ssh/id_rsa. Your public key has been saved in .ssh/id_rsa.pub. The key fingerprint is: 5a:13:69:ed:14:ce:c2:e9:a2:34:75:41:c4:b3:4d:fd user@host.yourdomain.com

We need to transfer the public one of the key pair to the server which we want to connect (e.g. your.remote_ssh_server.com). You’ll always be warned that your SSH installation doesn’t recognize the remote part if any host is contacted for the first time. When you confirm that you want to continue the connection with the answer “yes” to question asked following the warning, the name of the host and DSA data will be added into ~/.ssh/known_hosts file. When you connect to the same host later, you’ll not be prompted again.

client# scp id_rsa.pub user@your.remote_ssh_server.com: The authenticity of host 'your.remote_ssh_server.com (212.x.x.x)' can't be established. DSA key fingerprint is 58:14:29:ac:6d:94:8d:48:89:3a:cf:95:36:1b:a3:72. Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added 'your.remote_ssh_server.com' (DSA) to the list of known hosts. Password: passphrase (PAM password of a user on ssh server) id_rsa.pub                                            100%  406     0.4KB/s   00:00

We have transferred id_rsa.pub public key to our SSH server via “scp” and have added our server’s DSA key into ~/.ssh/known_hosts permanently. By the way, instead of using “scp” command, we might transfer our key to SSH server via copy/paste method as we mentioned before.

In case you get “Error reading response length from authentication socket.” error when you run “scp” command, delete the id_rsa and id_rsa.pub keys generated, truncate the known_hosts file corresponding to active user with # cat /dev/null > //.ssh/known_hosts command and copy new key to SSH server by scp once more after regenerating them.

If id_rsa.pub public key is transferred to SSH server successfully, we have to append this key to .ssh/authorized_keys file with the command below like we have done before;

server# cat id_rsa.pub >> .ssh/authorized_keys

Now we can make ssh connection that is going to be initiated via RSA authentication by using the command line below on the client;

client# ssh -o PreferredAuthentications=publickey -i /home/user/.ssh/id_rsa -l user your.remote_ssh_server.com

When prompted, enter the password you determined for your private key.

In PART 2, while we’ll be handling the details like agent-forwarding and port forwarding, we’ll be inspecting the cases we can actualize with SSH tunneling in conjunction with PKI supported sessions.