Re: keys not recognized in Unixware --> RedHat Connection - openssh

This is a discussion on Re: keys not recognized in Unixware --> RedHat Connection - openssh ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: keys not recognized in Unixware --> RedHat Connection

  1. 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
    > 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@allantgroup.com


  2. Re: keys not recognized in Unixware --> RedHat Connection

    In the last episode (Sep 26), COHEN, STEVEN M (ATTSI) said:
    > 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


    no; s/key is a one-time-password login scheme that's rarely used
    anymore. ChallengeResponseAuthentication is a generic login method
    that just means the server sends a string ("Password:", for example)
    and the client responds with another string. It or
    PasswordAuthentication is required for regular Unix password-based
    logins to work.

    There shouldn't be any server-side flags that can disable
    passphraseless key authentication, since the server has no knowledge of
    or control over how the the private key is encrypted on the client.
    It's possible there's a security setting in Attachmate that disallows
    the use of ssh keys without a passphrase. If you can enable a debugging
    or logging mode on the client when you connect, it may give you some
    more info as to why the login is failing.

    --
    Dan Nelson
    dnelson@allantgroup.com


+ Reply to Thread