Mailing List Archive

[Fwd: Question: sshd_config: combinations of PasswordAuthentication and ChallengeResponseAuthentication]
Dear all,

I have searched across Google for a while to try and understand the
security impact of certain changes in our sshd_config file, but because
I could not find the answer, I decided to post here. I hope that here is
the right place.

A developer uses SSH to connect to servers in his application, but it
cannot connect. The Dev has shown that if I change the these settings
in the sshd_config :-

From:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes


To:

ChallengeResponseAuthentication no
#PasswordAuthentication ...
(second one commented out, so the default setting is used)


I have tried to understand what the impact is for security and other
varibles across our systems, but cannot.
We use RSA and DSA keys to connect between servers, and UNIX password
authentication.
Some keys have passphases, and others do not.
Servers are SLES, Opensuse, Debian and HPUX.

Can anyone think of any, or even point me to a URL that could explain
these in near-layman's terminology as I am not an SSH expert?


Yours sincerely,
J.
Re: [Fwd: Question: sshd_config: combinations of PasswordAuthentication and ChallengeResponseAuthentication] [ In reply to ]
"PasswordAuthentication" is a built-in method of using a password.
This is where the client gets the password from somewhere and
passes it to the server, along with the user name.

"ChallengeResponseAuthentication" is a method to tunnel the
authentication process. The client opens the tty and gateways
it to the server's authentication process/library. This enforces an
interactive authentication scheme.

Using ChallengeResponseAuthentication is more secure, as it does
its best to not allow programmatic entering of the password. You must
enter the password via a tty device.

With PasswordAuthentication, you can:
$ echo $PASSWORD | ssh $HOST "cat /etc/passwd"

With ChallengeResponseAuthentication you have to use a chat script
or expect.

I would suggest forgoing passwords and just using keys. Unless your
requirement is to use both.

On Mon, Feb 15, 2010 at 12:43 AM, J4 <junk4@klunky.co.uk> wrote:
>
> Dear all,
>
>    I have searched across Google for a while to try and understand the
> security impact of certain changes in our sshd_config file, but because
> I could not find the answer, I decided to post here. I hope that here is
> the right place.
>
> A developer uses SSH to connect to servers in his application, but it
> cannot connect.  The Dev has shown that if I change the these settings
> in the sshd_config :-
>
> From:
>
> # To disable tunneled clear text passwords, change to no here!
> PasswordAuthentication no
>
> # Change to no to disable s/key passwords
> #ChallengeResponseAuthentication yes
>
>
> To:
>
> ChallengeResponseAuthentication no
> #PasswordAuthentication ...
> (second one commented out, so the default setting is used)
>
>
> I have tried to understand what the impact is for security and other
> varibles across our systems, but cannot.
> We use RSA and DSA keys to connect between servers, and UNIX password
> authentication.
> Some keys have passphases, and others do not.
> Servers are SLES, Opensuse, Debian and HPUX.
>
> Can anyone think of any, or even point me to a URL that could explain
> these in near-layman's terminology as I am not an SSH expert?
>
>
> Yours sincerely,
> J.



--
And, did Galoka think the Ulus were too ugly to save?
-Centauri
Re: [Fwd: Question: sshd_config: combinations of PasswordAuthentication and ChallengeResponseAuthentication] [ In reply to ]
Dear Robert,

This explains why the programmer's SSH library did not work correctly
because it cannot understand the tty. It is likely that it used
something akin to echo $PASSWORD | ssh $HOST "cat /etc/passwd" instead
of expect etali.

Many thanks for the explanation.

Best wishes,
J

Robert Hajime Lanning wrote:
> "PasswordAuthentication" is a built-in method of using a password.
> This is where the client gets the password from somewhere and
> passes it to the server, along with the user name.
>
> "ChallengeResponseAuthentication" is a method to tunnel the
> authentication process. The client opens the tty and gateways
> it to the server's authentication process/library. This enforces an
> interactive authentication scheme.
>
> Using ChallengeResponseAuthentication is more secure, as it does
> its best to not allow programmatic entering of the password. You must
> enter the password via a tty device.
>
> With PasswordAuthentication, you can:
> $ echo $PASSWORD | ssh $HOST "cat /etc/passwd"
>
> With ChallengeResponseAuthentication you have to use a chat script
> or expect.
>
> I would suggest forgoing passwords and just using keys. Unless your
> requirement is to use both.
>
> On Mon, Feb 15, 2010 at 12:43 AM, J4 <junk4@klunky.co.uk> wrote:
>
>> Dear all,
>>
>> I have searched across Google for a while to try and understand the
>> security impact of certain changes in our sshd_config file, but because
>> I could not find the answer, I decided to post here. I hope that here is
>> the right place.
>>
>> A developer uses SSH to connect to servers in his application, but it
>> cannot connect. The Dev has shown that if I change the these settings
>> in the sshd_config :-
>>
>> From:
>>
>> # To disable tunneled clear text passwords, change to no here!
>> PasswordAuthentication no
>>
>> # Change to no to disable s/key passwords
>> #ChallengeResponseAuthentication yes
>>
>>
>> To:
>>
>> ChallengeResponseAuthentication no
>> #PasswordAuthentication ...
>> (second one commented out, so the default setting is used)
>>
>>
>> I have tried to understand what the impact is for security and other
>> varibles across our systems, but cannot.
>> We use RSA and DSA keys to connect between servers, and UNIX password
>> authentication.
>> Some keys have passphases, and others do not.
>> Servers are SLES, Opensuse, Debian and HPUX.
>>
>> Can anyone think of any, or even point me to a URL that could explain
>> these in near-layman's terminology as I am not an SSH expert?
>>
>>
>> Yours sincerely,
>> J.
>>
>
>
>
>