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
