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@xxxxxxxxxxxxxxx
