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
