>
> hi all,
>
> i've spent about 4 hours now googling around, trying to figure out why
> solaris 8 install of ssh and my solaris 10 install behave differently.
> the problem i'm having is that i cannot turn off password access to my
> solaris 10 machine.
>
> i'm using the same version of ssh in both cases, OpenSSH_4.3p2,
> OpenSSL 0.9.8a 11 Oct 2005 and i'm using the same sshd_config file with
> "PasswordAuthentication no" in both
>
> when i ssh to the solaris machine is does prompt me for my private key
> passphrase but if i just hit return it comes back with a prompt for my
> unix passwd
>
> eg:
> where host2 is a solaris 10 machine
> [host1:~] steve% ssh host2
> Enter passphrase for key '/Users/steve/.ssh/id_rsa':
> Password:
>
> where host3 is a solaris 10 machine
> [host1:~] steve% ssh host3
> Enter passphrase for key '/Users/steve/.ssh/id_rsa':
> Permission denied (publickey,keyboard-interactive).
>
> i'm using sshd -f /usr/local/etc/sshd_config when i start ssh in
> /etc/init.d so there's no confusion over which sshd_config i should be
> using..
>
> can anyone suggest why i can't turn off ssh password access on my
> solaris 10 machine?

Possibly it is not using the SSH "password" authentication method, but
rather "keyboard-interactive", whose behavior is usually configured via
PAM, and by defalt usually just prompts for a password. Try this in
sshd_config:

KbdInteractiveAuthentication no

--
Richard Silverman
res@qoxp.net

On 2006-04-22, Richard E. Silverman wrote:
>> i've spent about 4 hours now googling around, trying to figure out why
>> solaris 8 install of ssh and my solaris 10 install behave differently.
>> the problem i'm having is that i cannot turn off password access to my
>> solaris 10 machine.
[...]
>> [host1:~] steve% ssh host2
>> Enter passphrase for key '/Users/steve/.ssh/id_rsa':
>> Password:
[...]
> Possibly it is not using the SSH "password" authentication method, but
> rather "keyboard-interactive", whose behavior is usually configured via
> PAM, and by defalt usually just prompts for a password.

That is certainly what it looks like.

> Try this in sshd_config:
>
> KbdInteractiveAuthentication no

That will turn off keyboard-interactive in Protocol 2 but you probably
want to also set "ChallengeResponseAuthentication no" turn off the
equivalent authentication (PAM via TIS challenge-response) for Protocol 1.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

>>>>> "DT" == Darren Tucker writes:
>> Try this in sshd_config:
>>
>> KbdInteractiveAuthentication no

DT> That will turn off keyboard-interactive in Protocol 2 but you
DT> probably want to also set "ChallengeResponseAuthentication no"
DT> turn off the equivalent authentication (PAM via TIS
DT> challenge-response) for Protocol 1.

Good point. I try to forget that SSH-1 exists.

--
Richard Silverman
res@qoxp.net

"Richard E. Silverman" wrote in message
news:m2fyk4vt5q.fsf@darwin.oankali.net...
>>>>>> "DT" == Darren Tucker writes:
> >> Try this in sshd_config:
> >>
> >> KbdInteractiveAuthentication no
>
> DT> That will turn off keyboard-interactive in Protocol 2 but you
> DT> probably want to also set "ChallengeResponseAuthentication no"
> DT> turn off the equivalent authentication (PAM via TIS
> DT> challenge-response) for Protocol 1.
>
> Good point. I try to forget that SSH-1 exists.

Richard, are we anywhere near the point where SSH 1 should be disabled by
default in sshd_config? I'm under the impression that it's really fallen out
of favor: I haven't used it in years except by accident.

>>>>> "NKG" == Nico Kadel-Garcia writes:

>> Good point. I try to forget that SSH-1 exists.

NKG> Richard, are we anywhere near the point where SSH 1 should be
NKG> disabled by default in sshd_config? I'm under the impression that
NKG> it's really fallen out of favor: I haven't used it in years
NKG> except by accident.

I think so, unless there's some specific need for it; certainly if it's
for use by/inside your own organization. If you're an ISP or other entity
like, say, anonymizer.com, then perhaps you still want to leave it on to
accomodate your more archaic customers. Or, if you think your associates
may have to log in from random locations with whatever SSH client they can
find -- although of course, there are bigger problems with that than your
choice of protocol. And, SSH-1 is especially to be avoided in such a
case, since its weak key exchange allows the client to force an insecure
session key.

--
Richard Silverman
res@qoxp.net