Difference between "PasswordAuthentication yes" and "AllowedAuthentication password" ?
h.wulff
AFAIK the "PasswordAuthentication yes" enables cleartext passwords. But
what happends to the passwd if AllowedAuthentication is password and
PasswordAuthentication is no?
I'm asking because I have to enable PasswordAuthentication to let an
older version of cryptlib work. And this raises the question where the
difference is...
Thank you for your efforts!
--
h.wulff
[dont send me an email]
Richard E. Silverman
hw> Hello, AFAIK the "PasswordAuthentication yes" enables cleartext
hw> passwords.
The user authentication protocol is carried inside an SSH transport
session, which is normally encrypted -- so this does enable cleartext
passwords, at least as far as the network is concerned. It does reveal
the password to the server, which is a weakness publickey authentication
avoids.
hw> But what happends to the passwd if AllowedAuthentication is
hw> password and PasswordAuthentication is no?
You haven't said what software you're using, or whether you're talking
about the client or the server... and, this sentence is
self-contradictory: "AllowedAuthentications" is a Tectia keyword, while
"PasswordAuthentication" belongs to OpenSSH.
However, I don't think it much matters to answer your specific question.
These various keywords in either product do not affect what happens to the
password: it is encrypted if and only if the underlying SSH session uses
encryption.
--
Richard Silverman
r...@qoxp.net
h.wulff
thanks for your reply.
In article <m2r7dd8...@darwin.oankali.net>, r...@qoxp.net says...
> >>>>> "hw" == h wulff <zuh...@aol.com> writes:
>
> hw> Hello, AFAIK the "PasswordAuthentication yes" enables cleartext
> hw> passwords.
>
> The user authentication protocol is carried inside an SSH transport
> session, which is normally encrypted -- so this does enable cleartext
> passwords, at least as far as the network is concerned. It does reveal
> the password to the server, which is a weakness publickey authentication
> avoids.
<sshd_config>
# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication no
</sshd_config>
Thats why I assumed the clear text passwd.
Taken from sshd_config of OpenSSH_3.8.1p1 Debian-8.sarge.4. Btw: I know
that ssh is quite secure and there are no plain password. I wonder about
the comment...
>
> However, I don't think it much matters to answer your specific question.
> These various keywords in either product do not affect what happens to the
> password: it is encrypted if and only if the underlying SSH session uses
> encryption.
>
So, let me ask the question another way round:
What is the difference between "PasswordAuthentication no" and
"PasswordAuthentication yes"?
I can login with a password in both cases.
Darren Tucker
><sshd_config>
> # Change to yes to enable tunnelled clear text passwords
> PasswordAuthentication no
></sshd_config>
>
> Thats why I assumed the clear text passwd.
> Taken from sshd_config of OpenSSH_3.8.1p1 Debian-8.sarge.4. Btw: I know
> that ssh is quite secure and there are no plain password. I wonder about
> the comment...
The "tunnelled" part implies that it's encrypted on the wire (which it
is) but as Richard noted the server must decrypt it to process it.
> So, let me ask the question another way round:
> What is the difference between "PasswordAuthentication no" and
> "PasswordAuthentication yes"?
> I can login with a password in both cases.
Debian's sshd is built with PAM, so I suspect what you see as logging
in with a password is actually challenge-response authentication from a
SSH protocol perspective.
Last time I looked, the version of OpenSSH Debian uses doesn't use PAM
for PasswordAuthentication, that capability was (re)introduced in 3.9p1
and I don't think they've backported the patch. This may or may not
matter in your case.
--
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.
Richard E. Silverman
hw> Hello, thanks for your reply.
hw> In article <m2r7dd8...@darwin.oankali.net>, r...@qoxp.net
hw> says...
>> >>>>> "hw" == h wulff <zuh...@aol.com> writes:
>>
hw> Hello, AFAIK the "PasswordAuthentication yes" enables cleartext
hw> passwords.
>> The user authentication protocol is carried inside an SSH
>> transport session, which is normally encrypted -- so this does
>> enable cleartext passwords,...
Ack -- that was supposed to read, "does NOT enable..."
>> concerned. It does reveal the password to the server, which is a
>> weakness publickey authentication avoids.
hw> <sshd_config> # Change to yes to enable tunnelled clear text
hw> passwords PasswordAuthentication no </sshd_config>
hw> Thats why I assumed the clear text passwd. Taken from sshd_config
hw> of OpenSSH_3.8.1p1 Debian-8.sarge.4. Btw: I know that ssh is quite
hw> secure and there are no plain password. I wonder about the
hw> comment...
The comment refers to the fact that the password is sent as-is to the
server, where it is revealed, as opposed to a more sophsticated technique
like SRP. It is cleartext in the userauth protocol, but protected on the
wire by being "tunnelled" inside the transport protocol.
hw> So, let me ask the question another way round: What is the
hw> difference between "PasswordAuthentication no" and
hw> "PasswordAuthentication yes"? I can login with a password in both
hw> cases.
Ah, now I understand your confusion. As Darren indicated, it is using a
different form of authentication in this case. It still ends up with the
user typing in a password, but it is not "password authentication" in the
strict meaning of that phrase within the SSH protocol. An ssh -v trace
would show the difference.
--
Richard Silverman
r...@qoxp.net
h.wulff
thanks for your reply.
In article <m2hde97...@darwin.oankali.net>, r...@qoxp.net says...
> Ah, now I understand your confusion. As Darren indicated, it is using a
> different form of authentication in this case. It still ends up with the
> user typing in a password, but it is not "password authentication" in the
> strict meaning of that phrase within the SSH protocol. An ssh -v trace
> would show the difference.
>
>
After I used "ssh -v" I should ask where is the difference between
password and keyboard-interactive.
Is this easy to explain?
Richard E. Silverman
hw> After I used "ssh -v" I should ask where is the difference between
hw> password and keyboard-interactive. Is this easy to explain?
hw> Thank you for your efforts! --
"password" simply accepts a password from the client.
"keyboard-interactive" engages in a dialog of prompts and responses which
can accomodate more general mechanisms, such as OTP, and be easily
connected to a framework such as PAM.
http://www.snailbook.com/docs/keyboard-interactive.txt
--
Richard Silverman
r...@qoxp.net
Paul Bramscher
(debian-based) server at work. The default /etc/ssh/sshd_config
settings are set up with keyboard-interactive and I'm not that familiar
with it in practice -- coming from a Red Hat world.
The doc. you site below is too low-level, as are other standards-setting
type whitepapers I've read on it. Is there a good general discussion on
the differences from a security standpoint?
In practice, assuming you've just set up a linux box -- no additional
mechanisms (pam, otp, etc.) -- which is the more secure method: password
or keyboard-interactive?
Does it make any difference?
-Paul Bramscher
Darren Tucker
[...]
> In practice, assuming you've just set up a linux box -- no additional
> mechanisms (pam, otp, etc.) -- which is the more secure method: password
> or keyboard-interactive?
>
> Does it make any difference?
If you're using the normal pam_unix modules then it won't make much
difference.
Password authencation is simpler and is supported by more clients.
On the other hand, that includes the current crop of ssh-based worms
which don't understand challenge-response.
If I had to pick one and it was an internal host, I'd use password
authentication. If it was an exposed host I wouldn't allow either,
only pubkey.
Paul Bramscher
> On 2005-08-04, Paul Bramscher <brams00...@tc.umn.edu> wrote:
> [...]
>
>>In practice, assuming you've just set up a linux box -- no additional
>>mechanisms (pam, otp, etc.) -- which is the more secure method: password
>>or keyboard-interactive?
>>
>>Does it make any difference?
>
>
> If you're using the normal pam_unix modules then it won't make much
> difference.
>
> Password authencation is simpler and is supported by more clients.
> On the other hand, that includes the current crop of ssh-based worms
> which don't understand challenge-response.
>
> If I had to pick one and it was an internal host, I'd use password
> authentication. If it was an exposed host I wouldn't allow either,
> only pubkey.
I popped open Ethereal, started the capture process and logged into a
box with keyboard-interactive. The last thing I saw in plaintext was a
list of various ciphers. It settled on one of them, presumably, and was
all garbled after that point. In none of the packets could I see the
password.
What do you mean by "exposed?"
Darren Tucker
> I popped open Ethereal, started the capture process and logged into a
> box with keyboard-interactive. The last thing I saw in plaintext was a
> list of various ciphers. It settled on one of them, presumably, and was
> all garbled after that point. In none of the packets could I see the
> password.
Barring bugs or the explicit use of the "none" cipher (which OpenSSH
doesn't support) then everything after the cipher negotiation, including
the authentication, is always encrypted. This is what you're seeing in
the packet capture.
> What do you mean by "exposed?"
"on the Internet or other untrusted network rather than behind a firewall".
Peter Gutmann
>AFAIK the "PasswordAuthentication yes" enables cleartext passwords. But
>what happends to the passwd if AllowedAuthentication is password and
>PasswordAuthentication is no?
>I'm asking because I have to enable PasswordAuthentication to let an
>older version of cryptlib work. And this raises the question where the
>difference is...
This is with OpenSSH 3.8 or 3.9, right? The problem is that SSH has two types
of password authentication which are exactly the same only different, password
authentication, and password authentication with PAM. When you connect to
OpenSSH 3.8 or 3.9 and ask for "password" authentication, it thinks you want
password authentication rather than password authentication, and disconnects
saying you need to use password authentication. If you disable password
authentication then it falls back to password authentication, and everything
is OK (as I said, the two are exactly the same, only different).
Why are you still using an old version of cryptlib? Apart from sundry other
updates, the newer versions also detect the problematic OpenSSH versions and
fudge the authentication type they're using, so they'll use password
authentication instead of password authentication and everything will work.
Peter.
Richard E. Silverman
PB> In practice, assuming you've just set up a linux box -- no
PB> additional mechanisms (pam, otp, etc.) -- which is the more secure
PB> method: password or keyboard-interactive?
These days PAM is not an "additional mechanism;" it's usually on by
default and an integral part of systems management.
Usually if keyboard-interactive is enabled by default, it is equivalent to
password.
PB> Does it make any difference?
PB> -Paul Bramscher
PB> Richard E. Silverman wrote:
>>>>>>> "hw" == h wulff <zuh...@aol.com> writes:
hw> After I used "ssh -v" I should ask where is the difference
>> between
hw> password and keyboard-interactive. Is this easy to explain?
hw> Thank you for your efforts! --
>> "password" simply accepts a password from the client.
>> "keyboard-interactive" engages in a dialog of prompts and responses
>> which can accomodate more general mechanisms, such as OTP, and be
>> easily connected to a framework such as PAM.
>> http://www.snailbook.com/docs/keyboard-interactive.txt
>>
--
Richard Silverman
r...@qoxp.net
Richard E. Silverman
PG> h.wulff <zuh...@aol.com> writes:
>> AFAIK the "PasswordAuthentication yes" enables cleartext
>> passwords. But what happends to the passwd if AllowedAuthentication
>> is password and PasswordAuthentication is no?
>> I'm asking because I have to enable PasswordAuthentication to let
>> an older version of cryptlib work. And this raises the question
>> where the difference is...
PG> This is with OpenSSH 3.8 or 3.9, right? The problem is that SSH
PG> has two types of password authentication which are exactly the
PG> same only different, password authentication, and password
PG> authentication with PAM.
It is not at all clear what you mean by "password authentication with
PAM." If you are referring to the "password" method in the SSH user
authentication protocol, there is only one, and there is no confusion. An
implementation may be configured to check the password in various ways,
including PAM, but that is not visible at the protocol level.
On the other hand, perhaps you mean using "keyboard-interactive" rather
than "password", since the intention of keyboard-interactive is to
accomodate an arbitrary authentication exchange with a user typing at a
keyboard, as PAM can do. That may be equivalent to "password" in effect,
but need not be -- it can be configured to use more complex PAM methods,
such as OTP.
PG> When you connect to OpenSSH 3.8 or 3.9 and ask for "password"
PG> authentication, it thinks you want password authentication rather
PG> than password authentication, and disconnects saying you need to
PG> use password authentication. If you disable password
PG> authentication then it falls back to password authentication, and
PG> everything is OK (as I said, the two are exactly the same, only
PG> different).
This is too confused for me to make any sense of.
--
Richard Silverman
r...@qoxp.net
Peter Gutmann
>It is not at all clear what you mean by "password authentication with
>PAM." If you are referring to the "password" method in the SSH user
>authentication protocol, there is only one, and there is no confusion. An
>implementation may be configured to check the password in various ways,
>including PAM, but that is not visible at the protocol level.
I meant the password authentication that's called keyboard-interactive, as
opposed to the password authentication that's called password authentication.
> PG> When you connect to OpenSSH 3.8 or 3.9 and ask for "password"
> PG> authentication, it thinks you want password authentication rather
> PG> than password authentication, and disconnects saying you need to
> PG> use password authentication. If you disable password
> PG> authentication then it falls back to password authentication, and
> PG> everything is OK (as I said, the two are exactly the same, only
> PG> different).
>This is too confused for me to make any sense of.
Yup, and that's probably the same reaction a typical user would have to two
password authentication techniques that do the same thing but aren't
interchangeable.
Peter.
h.wulff
In article <3m0t0nF...@individual.net>, pgu...@cs.auckland.ac.nz
says...
> Why are you still using an old version of cryptlib? Apart from sundry other
> updates, the newer versions also detect the problematic OpenSSH versions and
> fudge the authentication type they're using, so they'll use password
> authentication instead of password authentication and everything will work.
>
Because I use cryptlib 3.1 in Windows NT kernel mode and I don't have
time to port a newer release to the kernel mode.
But its still on my todo list. =)
Peter Gutmann
Well if you'd sent me the diffs for your changes to 3.1 (which is sort of
assumed from the GPL-compatible license you're using it under) then they'd
automatically be part of 3.2. 3.1 is out of date, you really shouldn't be
using it any more.
Peter.