RE: keys not recognized in Unixware --> RedHat Connection



Thank you.

I didn't realize that putting the passphrase in the key meant you would
always be asked for it. I make dozens of connections from this Unixware box
to this and other similarly configured RedHat servers (which requires its
own ssh passphrase for me to get into) every day and typing this passphrase
was getting very old. Now, by creating keys without passphrases, this step
is eliminated.

I find, though, that I cannot accomplish the same on the connection from my
Windows PC to the initial Unixware box (using the Attachmate application).
On that connection, a key with a passphrase is accepted when I type the
passphrase, but a key without a passphrase is rejected. Is this
controlled by the ChallengeResponseAuthentication configuration parameter
(which is yes on the Unixware box and no on the Linux boxes)?

If so, then I would say that the ChallengeResponseAuthentication comment in
the standard sshd_config file is a little confusing. That comment is:

# Change to no to disable s/key passwords

This is confusing since it seems that what is actually being disabled here
is logon via keys WITHOUT passphrases.



-----Original Message-----
From: Dan Nelson [mailto:dnelson@xxxxxxxxxxxxxxx]
Sent: Thursday, September 25, 2008 10:06 PM
To: COHEN, STEVEN M (ATTSI)
Cc: secureshell@xxxxxxxxxxxxxxxxx
Subject: Re: keys not recognized in Unixware --> RedHat Connection

In the last episode (Sep 25), COHEN, STEVEN M (ATTSI) said:
I am trying to connect via ssh from a box running UnixWare 5 7.1.3
which has OpenSSH installed at version OpenSSH_5.0p1, OpenSSL 0.9.8g
19 Oct 2007 to a box running Linux 2.6.9-78.0.1.EL #1 Tue Jul 22
17:50:01 EDT 2008 which has OpenSSH installed at version
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003.

I find that the keys generated on the Unixware box are not accepted on
the Linux box. This authentication always fails and I am forced to
type the passphrase in every time.

I did the following (using non-standard key name since I did not want
to mess up existing connectivity):

$ ssh-keygen -t dsa -f id_dsa2
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_dsa2.
Your public key has been saved in id_dsa2.pub.
The key fingerprint is: ...

Ok, so at this point (assuming you did enter a passphrase here; you didn't
say) you have an SSH key with a passphrase required to decrypt the private
half...

Then, I copied id_dsa2.pub to the Linux box.

and did the following on that box

$ mv authorized_keys authorized_keys.bak $ cp id_dsa2.pub
authorized_keys

Then, back on unixware box, I do the following

$ ssh -v -i id_dsa2 ip2
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to ip2 [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file id_dsa2 type 2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ip2' is known and matches the RSA host key.
debug1: Found key in /home/myusername/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: id_dsa2
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown> Enter passphrase for
key 'id_dsa2':
debug1: No more authentication methods to try.
Permission denied (publickey).

.. and here, you are prompted for that passphrase so your ssh client can
sign the public key and send the signature to the remote server, so the
remote server will authenticate you (see
openssh/sshconnect2.c:sign_and_send_pubkey for the details). Until that
happens, all the remote server knows is that you /might/ have the private
half of a public key that's in its authorized_keys file.

If I had entered my passphrase I would have gotten in.
Can someone explain why this happens?

Because your private key is encrypted with a passphrase. If you want to be
able to log in without entering a passphrase for your private key, either a)
run ssh-agent so you only have to enter the passphrase once, or b) remove
the passphrase on that private key.

--
Dan Nelson
dnelson@xxxxxxxxxxxxxxx

Attachment: smime.p7s
Description: S/MIME cryptographic signature



Relevant Pages

  • Re: keys not recognized in Unixware --> RedHat Connection
    ... Enter passphrase: ... Your public key has been saved in id_dsa2.pub. ... debug1: Connection established. ... can sign the public key and send the signature to the remote server, ...
    (SSH)
  • Re: passwordless login with same user id across box
    ... Enter passphrase: ... Also the .ssh folder permissions are, ... debug1: Authentications that can continue: publickey,password ...
    (SSH)
  • Re: passwordless login with same user id across box
    ... Enter passphrase: ... Also the .ssh folder permissions are, ... debug1: Authentications that can continue: publickey,password ...
    (SSH)
  • keys not recognized in Unixware --> RedHat Connection
    ... I am trying to connect via ssh from a box running UnixWare 5 7.1.3 which has ... Enter passphrase: ... debug1: Connection established. ... debug1: Authentications that can continue: publickey ...
    (SSH)
  • Re: SSH Passphrase
    ... An SSH-passphrase doesn't relate to the security of the connection, ... The ssh-agent does indeed request the passphrase at the beginning of the ... session, but nothing prevents you from setting up a session at any given ...
    (Security-Basics)