Walker News » SSH

How To Use Putty-generated RSA Key To Login Linux OpenSSH Server?

Walker — Sun, 10 May 2009 16:28:04 +0000

In order for Windows users to remotely login Linux servers via SSH protocol, I suggest the Putty freeware (a SSH client for Windows that is also supporting legacy, insecure telnet and rlogin protocol).

For the sake of better security, most system administrators enforce SSH authentication over Public-key cryptography based on RSA algorithm.

(Sounds complicated and high-tech? No worry. You don’t have to know all these scary terms to make this trick works – engineer is applying what the scientists have found).

So, How to use Putty-based RSA public-key with OpenSSH server?

The public-key generated by Puttygen is not compatible with the one generated by OpenSSH.

However, you can manually modify the Putty-based public key before appending it to authorized_keys file:

1) Open Puttygen (Putty Key Generator), click Generate button and move the mouse cursor randomly within the key section/frame to create the key with default settings (e.g. SSH-2 RSA of 1024 bits).

2) When the key generation completes, create a strong passphrase in the text box provided.

3) Then, click save Public Key and Save Private Key button, one after another, to save the pair of key to local hard disk.

4) Transfer the Puttygen-created public key to Linux server (in my test case, it’s RHEL 5.2).

Let’s say this public key is only meant for Walker user account, save that public key in Walker’s $HOME/.ssh directory.

5) Open the Putty public key with Vi editor (any text editor of your choice):

Delete the lines initial with four dash and “Comment”.
Join the remain lines into one, single line.
Initial that single line with ssh-rsa keyword (a space at the end).

Not get it? Take a look at my “silent” screencast:

How To Create Putty-based RSA Public-key For OpenSSH Server?

Walker — Sun, 03 May 2009 11:00:53 +0000

If you want to remote access Linux server via SSH protocol from Windows system, I recommend you to use Putty (a Telnet/SSH freeware for Windows and UNIX; developed by an English man called Simon Tatham).

To strengthen security, don’t ever use plain text password, try to use RSA-based Public-key cryptography for user authentication. The Puttygen (Putty Key Generator; another freeware of Simon) can generate both RSA and DSA-based key pair.

However, the RSA public-key generated by Puttygen is not 100% compatible with OpenSSH server (the dominant SSH server in most Linux distributions).

To make it work, you need to modify the Putty-based RSA public-key before appending it to authorized_keys file.

Steps to generate Putty-based RSA key pair to login Linux OpenSSH server

1) Open Puttygen program and click Generate button to create a 1024-bit, SSH-2 RSA key pair. After clicking the Generate button, move the mouse cursor inside the Key frame repeatedly (Puttygen need these movements to create a “perfect random key pair”).

2) Once the key pair generation complete, think of a “strong” password and enter it twice in the Key Passphrase and Confirm Passphrase text boxes provided in Key frame.

3) Click Save Public-key and Save Private-key buttons to keep these two keys in local hard disk.

4) Transfer the public-key to your Linux home directory (assuming this public-key is made for yourself) and open it with vi editor (any text editor of your choice).

5) The original Putty-based RSA public-key is similar to this:

You need to delete the lines started with “4 dash” and “Comment:” (i.e. first two and the last line).

Next, join all the remaining lines into one, single line.

Then, insert this ssh-rsa keyword (with a trailing space) in front of the single line.

The final, modified Putty-based RSA public-key will looks like this:

6) Now, append the modified Putty-based RSA public key to $HOME/.ssh/authorized_keys file and you’re ready to use Putty to access Linux OpenSSH server with private and public key generated by Puttygen.

How To Regenerate Putty-based RSA Public-key From Its Private-key?

Walker — Sat, 02 May 2009 14:27:56 +0000

We have a server installation checklist but lacking of one for server reinstallation. It could be easily compiled by referring to the installation guide, but none of us bothers to do it.

When the server reinstallation case happened on last few days ago, we drafted a copy in no time. We checked and checked again, to ensure the backup was completed.

However, as what the Murphy’s law stated, “anything that can go wrong will go wrong” – we forgot to backup the Putty-based RSA public key :-(

Was that careless happened because we do not have an approved/certified checklist? If you ask me, I say no and that is why I quote the Murphy’s law in the incident report :-)

Now, missing those putty-based public-key is not something serious, unless we have lost the private key. If happen so, there is no choice to regenerate the new pair of keys.

Using Puttygen to regenerate RSA public-key from its private-key

Putty suite, the Windows-based SSH freeware, contains a key generator called Puttygen to create public-key and private-key.

Puttygen, a.k.a. Putty Key Generator, can also used to regenerate a missing public-key, if

1) the private-key is not missing and valid
2) the passphrase (password) is known

As shown in the following screenshot – open the Puttygen program, click Load button to import private-key.

After the private-key is selected, the Enter Passphrase dialog box pops up. As long as the private-key password is correct, Puttygen is ready for you to save a copy of public-key that based on the given private-key:

Therefore, we have no choice to get all affected users to recreate respective public-key with Puttygen and rewarded by some with “lousy sysadmin” :-(

How To Fix: SCP And SSH Login Prompt Is Very Slow In Linux

Walker — Mon, 06 Apr 2009 15:48:11 +0000

Apparently, today is not a good day for me. But it’s not too bad too as I still have enough fingers to count all these bad incidents :-)

OK, back to topic. How to find out that what cause the SSH or SCP login prompt to slowdown? How could you fix this so-called slow or delayed SSH and SCP login prompt?

This is one of the “bad incident” happened on me today – as the boss was looking at me to scp program patches to a remote Linux-based application server, the SSH login prompt took more than 1 minute to appear on screen.

To be precise, the stopwatch showed that it took exactly 1 minute and 25 seconds to display SSH login prompt!

Luckily, I do not have to Google for more than a minute to find the cause and solution :-)

What causes SCP and SSH login prompt to slowdown?

For my case, the GSSAPI authentication feature was causing the delayed SSH login prompt!

You can confirm the causes of your case by using the -v option switch. For example, the following is the verbose response of SSH login process started with -v option:

dev01 [/home/devstl]$ ssh -v appssupp@10.50.100.111
......
......
......
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Trying private key: /home/devstl/.ssh/identity
debug1: Trying private key: /home/devstl/.ssh/id_rsa
debug1: Trying private key: /home/devstl/.ssh/id_dsa
debug1: Next authentication method: password
appssupp@10.50.100.111's password:

How to fix SCP and SSH delayed login prompt?

The answer for my case is apparently by disabling GSSAPI authentication, which can be done in one of these three ways:

The “fix” is tested with SSH clients installed by openssh-clients-3.9p1-8.RHEL4.15 RPM file.

1) Specify the option to disable GSSAPI authentication when using SSH or SCP command, e.g.:

ssh -o GSSAPIAuthentication=no appssupp@10.50.100.111

2) Explicitly disable GSSAPI authentication in SSH client program configuration file, i.e. edit the /etc/ssh/ssh_config and add in this configuration (if it’s not already in the config file):

GSSAPIAuthentication no

3) Create a file called config in .ssh directory of respective user home directory (or whichever user home directory that need to get rid of this show login prompt). For example, edit /home/devstl/.ssh/config (create the config file if it’s not currently exist) and add in the GSSAPIAuthentication no option.

1) /etc/ssh/ssh_config is a global SSH client configuration file that affects all system users who are using SSH client programs.

2) /home/devstl/.ssh/config is local SSH client configuration file that only affects the user account called devstl. Whatever SSH client options specified in this local file overwrite the options stated in global SSH client configuration file.

After disabling GSSAPI authentication, SSH login prompt is back to “normal” now:

dev01 [/home/devstl]$ ssh -v appssupp@10.50.100.111
......
......
......
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/devstl/.ssh/identity
debug1: Trying private key: /home/devstl/.ssh/id_rsa
debug1: Trying private key: /home/devstl/.ssh/id_dsa
debug1: Next authentication method: password
appssupp@10.50.100.111's password:

As you can see, the SSH login is not currently authenticated via public key cryptography method, which I’ve to fix it later :-(

How To Fix “Server Refused Our Key” Error That Caused By Putty Generated RSA Public Key?

Walker — Sun, 22 Mar 2009 08:16:40 +0000

The SSH-2 protocol supports few user authentication types, one of which is public-key cryptography.

Other than security benefit, using public-key cryptography in SSH protocol is relatively easier to implement password-less or non-interactive authentication.

For example, a scheduled shell script can use scp (secure copy) to automate file-transfer between hosts seamlessly in background, without user interaction during authentication stage.

With OpenSSH, default SSH client/server software bundled with most Linux distributions, the ssh-keygen program is used to generate a pair of such cryptographic keys.

As for Putty, popular SSH client suite for Windows, there is this Puttygen program to provide similar functions of ssh-keygen.

However, there is incompatibility issue between RSA type of public key generated by ssh-keygen and Puttygen.

Having said that, you can’t install OpenSSH-generated private key in Putty program. Otherwise, the public-key authentication failed with message that says “Unable to use key file “E:\id_rsa” (OpenSSH SSH-2 private key)”.

Similarly, it’s not possible to install a Puttygen-generated public-key directly into OpenSSH authorized_keys file. If you do so, Putty fails with “Server refused our key” error message during authentication.

So, how to install a Putty-generated RSA type of Public-key in OpenSSH authorized_keys file?

This is the latest “silent” screencast in WalkerNews Channel @ YouTube (alive with background music from AudioSwap):

If you’re on fast and stable connection, please click the HQ button on for watching this screencast in high quality video mode.

As you’ve seen, the trick is to modified a Puttygen-generated public-key to the format of OpenSSH-generated public-key:

1) Edit Putty-generated public-key file with Vi editor,

^{Original RSA type of public-key generated by Puttygen program.}

2) Delete the first two and the last line,

3) Join the remaining lines into one single line, by using the Shift+J command shortcut. Remember to trim space between two line joined by CTRL+J command.

4) Insert ssh-rsa keyword (with one trailing space) in front of the single line.

5) [ OPTIONAL ] Append Login_ID@Host_name keyword (with a initial space) at the end of the single line (replace Login_ID and Host_name with your SSH login ID and host name accordingly).

^{Modified, tweak RSA type of public-key generated by Putty client program, to be installed into OpenSSH authorized_keys file.}

6) Append the modified, tweaked Putty-generated public-key (RSA type) to OpenSSH authorized_keys file.

Now, Putty is able to login OpenSSH server with its own set of public-key and private-key pair:

How To Install And Start Telnet Server In Red Hat Linux?

Walker — Tue, 18 Nov 2008 17:26:48 +0000

Every server administrators should and must know that telnet protocol is not secure, because data packets transfer between telnet server and client not encrypted.

That’s to say, anyone who use sniffer to capture network packets can read the plain text transfer over the network. If the packets captured contain login credentials, the server access and security control will be compromised.

Thus, by default, most Linux distributions install SSH server and not telnet. Red Hat Linux even explicitly categorize telnet server as one of the “legacy network servers”.

However, what if you really want the Linux machine running such insecure protocol?

How to install and start the insecure telnet server (in Red Hat Linux Enterprise 4)?

Look for the telnet-server RPM file in the installation CD/DVD and install it from command line, e.g. rpm -Uvh telnet-server-0.17-31.EL4.3.
Alternatively, login to GNOME Desktop, go to Application menu, System Settings, and click Add/Remove Applications to bring up Package Management window:

^{How to install and start telnet server in Red Hat Linux?}

Select Legacy Network Server (tick the check box), click Details link to bring up Legacy Network Server Package Details window, and select Telnet-Server to proceed with the installation.
At Linux command prompt, execute chkconfig telnet on to allow the xinetd spawns telnet-server processes upon client requests.
Alternatively, edit the telnet configuration file (/etc/xinetd.d/telnet) and change disable = yes to disable = no.
Make sure the xinetd is running on your Linux default runlevel. To be sure, configure xinetd to start at runlevel 3, 4, and 5:
```
chkconfig --level 345 xinetd on
```
If xinetd is not currently running (run ps -elf | grep xinetd), execute service xinetd start or service xinetd restart to start/restart it.

The running xinetd (extend Internet service daemon) listens to telnet client request on port 23 and spawn the telnet-server (/usr/sbin/in.telnetd) upon request, shut it down when telnet client drop the connection.

To confirm xinetd is listening to port 23, execute the netstat utility:

netstat -tulpan | grep 23

Linux: How To Backup And Restore Directory With Tar Over SSH Connection?

Walker — Wed, 05 Nov 2008 17:53:44 +0000

As per internal disaster recovery code, we have to redo DR server setup exercise every year, as to get sysadmins familiar with processes that are not frequently done and take chance to confirm latest updates deployed to live server are also working well in DR server.

So, it’s unavoidable to backup some directories on live machine and restore them to DR box. Problem is that the live system has insufficient free disk space to create tarball (tar archive or .tar file), as some of the directories are bulky.
In this situation, flexibility of Linux system comes into picture. Instead of creating the tarball at live system, we opt to backup and restore over network!

In brief, it’s a method called tar over SSH, where we are going to create tarball of directories on live server, pipe it over SSH connection (secure shell connection), and untar the tarball on remote DR server at one go (i.e. enter a series of Linux commands on one line and press ENTER key to execute them).

How to backup and restore Linux file system with Tar command over SSH connection?

This is the commands template:

tar -zcvpf - dir1 dir2 | ssh root@walkernews.net "cd /usr/local/share/lib; tar -zxvpf -"

where

tar option switch
- -z and -c meant to create (-c) a compressed tarball using gzip (-z)
- -v meant to verbosely list files processed
- -p meant to preserve file permission information
- -f meant the tarball output location. In this example, the tarball is created to – (i.e. stdin or standard input).
dir1 and dir2 are the target directories to be backup
| is the pipeline, meant the Linux inter-process communication (IPC).
the SSH remote shell command execution group the series of commands in double-quotation mark, in which it login to remote DR server (e.g. walkernews.net) using root user account, changes working directory to /usr/local/share/lib follow by untar the tarball data stream from stdin input of first tar command (the tarball creation that initiated on live server).

Now, what about if you want to tar backup directories of local system onto remote DR server? I.e. to create tarball of local directories onto remote server over SSH connection (use either one of these two commands; where backup.tgz is a gzip-compressed tarball file name):

tar -zcvpf - dir1 dir2 | ssh root@walkernews.net "cd /backupdir; cat > backup.tgz"

tar -zcvpf - dir1 dir2 | ssh root@walkernews.net "cd /backupdir; dd of=backup.tgz"