telnetd: Authorization failed & Connection closed

[Hubert Feyrer]

When trying to telnet[1] to a NetBSD 5.0/i386 machine, I do not always get
a login prompt. It seems that it depends on the machine/setup that I come
from if this behaviour is shown or not.

The line in /etc/inetd.conf is:

telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a valid


Example logins:

* From NetBSD 4.0/i386 I get a Login-prompt as expected

% telnet 192.168.1.3
Trying 192.168.1.3...
Connected to 192.168.1.3.
Escape character is '^]'.
Trying SRA secure login:
User (feyrer):

* From a Windows Vista machine that's part of an AD domain it fails:

C:\> telnet 192.168.1.3
<clears screen>
telnetd: Authorization failed.
Connection closed by foreign host.
C:\>

* From a Juniper SSG5 running ScreenOS 6.2.0r4.0 it fails, too:

ssg5> telnet 192.168.1.3
Trying 192.168.1.3...
Connected to 192.168.1.3.
Abort the connection with CTRL+D
telnetd: Authorization failed.

Connection closed by foreign host.
ssg5>

It seems the "valid" setting in telnetd does not fall back to login(1) as
it should, following the documentation.

I've tried running telnetd -s with no change.
For the various values for telnetd -a, it seems that "debug" and "off"
get things into a working condition.

I wonder if the default should be changed from "valid" to "off",
to make telnet logins work again, at least until someone fixes the "valid"
behaviour.


- Hubert


[1] I know it's considered insecure. Let's not go there now.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Iain Hibbert]

It seems the "valid" setting in telnetd does not fall back to login(1) as it
should, following the documentation.

I'm not sure that the documentation does say that, though its not greatly
clear.. I think it means you cannot connect at all without authorization,
and that login(1) may be called to get your password rather than allowing
automatic access.

more likely "none" does what you are hoping for? (allow auth, but fall
back to login(1) if none available)

iain



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Iain Hibbert

It seems the "valid" setting in telnetd does not fall back to login(1) as it
should, following the documentation.

I'm not sure that the documentation does say that, though its not greatly
clear.. I think it means you cannot connect at all without authorization,
and that login(1) may be called to get your password rather than allowing
automatic access.

My understanding of "valid" is that it'll try to automatically
authenticate, and if that doesn't work out fall back to asking login &
password. Which it unfortunately doesn't do.

Post by Iain Hibbert
more likely "none" does what you are hoping for? (allow auth, but fall
back to login(1) if none available)

Indeed, "none" works, too.

I do not have an environment where I can test the automated login,
so I'm not sure where to go from here. We know that "off" and "none" work,
but should we go and change the default inetd.conf for either now?

Is there anyone that has the "automated authentication" working that can
help test this?


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

We know that "off" and "none" work,

I've had another look:
Apparently "off" requires duplicate authentication:

% telnet 192.168.1.3
Trying 192.168.1.3...
Connected to 192.168.1.3.
Escape character is '^]'.
Trying SRA secure login:
User (feyrer): validlogin
Password: *****
[ SRA accepts you ]
login: validlogin
Password: *****
Last login: Tue Mar 9 10:47:42 2010 from 192.168.1.10 on ttyp0
...


So "none" really seems the better solution here:

% telnet 192.168.1.3
Trying 192.168.1.3...
Connected to 192.168.1.3.
Escape character is '^]'.
Trying SRA secure login:
User (feyrer): validlogin
Password:
[ SRA accepts you ]
Last login: Tue Mar 9 10:47:56 2010 from 192.168.1.10 on ttyp0
...


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Based on the discussion so far, do you object to commit the patch below,
replacing "valid" with "none"?


- Hubert

Index: inetd.conf
===================================================================
RCS file: /cvsroot/src/etc/inetd.conf,v
retrieving revision 1.58
diff -u -r1.58 inetd.conf
--- inetd.conf 16 Oct 2007 02:47:14 -0000 1.58
+++ inetd.conf 13 Mar 2010 10:44:46 -0000
@@ -8,8 +8,8 @@
#http stream tcp6 nowait:600 _httpd /usr/libexec/httpd httpd /var/www
#ftp stream tcp nowait root /usr/libexec/ftpd ftpd -ll
#ftp stream tcp6 nowait root /usr/libexec/ftpd ftpd -ll
-#telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a valid
-#telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd -a valid
+#telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a none
+#telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd -a none
#shell stream tcp nowait root /usr/libexec/rshd rshd -L
#shell stream tcp6 nowait root /usr/libexec/rshd rshd -L
#login stream tcp nowait root /usr/libexec/rlogind rlogind -L

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Iain Hibbert]

Post by Hubert Feyrer
Based on the discussion so far, do you object to commit the patch below,
replacing "valid" with "none"?

Well I don't ("-a none" is a no-op btw), but the commit message (v1.55,

Post by Hubert Feyrer
Add -a valid for PAM.

so I wonder if you should check with him if there is still a reason to
include it..

iain



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

On Mar 13, 12:02pm, ***@rya-online.net (Iain Hibbert) wrote:
-- Subject: Re: telnetd: Authorization failed & Connection closed

| On Sat, 13 Mar 2010, Hubert Feyrer wrote:
|
| > Based on the discussion so far, do you object to commit the patch below,
| > replacing "valid" with "none"?
|
| Well I don't ("-a none" is a no-op btw), but the commit message (v1.55,
| christos) says:
|
| > Add -a valid for PAM.
|
| so I wonder if you should check with him if there is still a reason to
| include it..

When I tested -a valid between two NetBSD machines, it worked fine.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bernd Ernesti]

Post by Christos Zoulas
-- Subject: Re: telnetd: Authorization failed & Connection closed
|
| > Based on the discussion so far, do you object to commit the patch below,
| > replacing "valid" with "none"?
|
| Well I don't ("-a none" is a no-op btw), but the commit message (v1.55,
|
| > Add -a valid for PAM.
|
| so I wonder if you should check with him if there is still a reason to
| include it..
When I tested -a valid between two NetBSD machines, it worked fine.

Only if you use PAM.

Bernd


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Christos Zoulas
When I tested -a valid between two NetBSD machines, it worked fine.

Please read the beginning of this thread:
http://mail-index.netbsd.org/tech-net/2010/03/09/msg001917.html


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

On Mar 14, 2:08am, ***@feyrer.de (Hubert Feyrer) wrote:
-- Subject: Re: telnetd: Authorization failed & Connection closed

| On Sat, 13 Mar 2010, Christos Zoulas wrote:
| > When I tested -a valid between two NetBSD machines, it worked fine.
|
| Please read the beginning of this thread:
| http://mail-index.netbsd.org/tech-net/2010/03/09/msg001917.html

As the documentation says:

valid Only allow connections when the remote user can pro-
vide valid authentication information to identify the
remote user. The login(1) command will provide any
additional user verification needed if the remote
user is not allowed automatic access to the specified
account.

So vista and juniper don't implement SRA and the connection is not allowed.
The default NetBSD telnetd configuration is more secure since passwords are
not sent in plaintext over the network. This is why valid is the default.
If you want to send your passwords in plaintext, feel free to change it for
your system, but I don't think that the change is appropriate for everyone.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Christos Zoulas
valid Only allow connections when the remote user can pro-
vide valid authentication information to identify the
remote user. The login(1) command will provide any
additional user verification needed if the remote
user is not allowed automatic access to the specified
account.
So vista and juniper don't implement SRA and the connection is not allowed.
The default NetBSD telnetd configuration is more secure since passwords are
not sent in plaintext over the network. This is why valid is the default.
If you want to send your passwords in plaintext, feel free to change it for
your system, but I don't think that the change is appropriate for everyone.

And I can't have a steak because a three-year-old can't chew it?
Seriously, it sounds pretty broken to rather not have a working telnet
than to do just what telnet is intended for.


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Hubert Feyrer

Post by Christos Zoulas
valid Only allow connections when the remote user can pro-
vide valid authentication information to identify the
remote user. The login(1) command will provide any
additional user verification needed if the remote
user is not allowed automatic access to the specified
account.
So vista and juniper don't implement SRA and the connection is not allowed.
The default NetBSD telnetd configuration is more secure since passwords are
not sent in plaintext over the network. This is why valid is the default.
If you want to send your passwords in plaintext, feel free to change it for
your system, but I don't think that the change is appropriate for everyone.

And I can't have a steak because a three-year-old can't chew it?
Seriously, it sounds pretty broken to rather not have a working telnet than
to do just what telnet is intended for.

Plus: I read the part about login(1) that it should fall back and ask me
for my login & password. Apparently it does not - a feature?


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

On Mar 14, 2:30am, ***@feyrer.de (Hubert Feyrer) wrote:
-- Subject: Re: telnetd: Authorization failed & Connection closed

| On Sun, 14 Mar 2010, Hubert Feyrer wrote:
| >> valid Only allow connections when the remote user can
| >> pro-
| >> vide valid authentication information to identify
| >> the
| >> remote user. The login(1) command will provide any
| >> additional user verification needed if the remote
| >> user is not allowed automatic access to the
| >> specified
| >> account.
| >>
| >> So vista and juniper don't implement SRA and the connection is not allowed.
| >> The default NetBSD telnetd configuration is more secure since passwords are
| >> not sent in plaintext over the network. This is why valid is the default.
| >> If you want to send your passwords in plaintext, feel free to change it for
| >> your system, but I don't think that the change is appropriate for everyone.
| >
| > And I can't have a steak because a three-year-old can't chew it?
| > Seriously, it sounds pretty broken to rather not have a working telnet than
| > to do just what telnet is intended for.
|
| Plus: I read the part about login(1) that it should fall back and ask me
| for my login & password. Apparently it does not - a feature?

I think you are mis-reading it; if there is not enough information from SRA
to log you in without a password, it will pass you to login to do it.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Christos Zoulas
I think you are mis-reading it; if there is not enough information from SRA
to log you in without a password, it will pass you to login to do it.

You mean it should run login(1) to ask for a login & passwort if no SRA
information is available, right? That's at least what I understand from
the manpage, and it's also what I think should happen.

From my understanding of the code, it does not fall back to login(1) but
call exit(1) instead, though (looking at startslave() in
src/libexec/telnet/sys_term.c):

if (!autoname || !autoname[0])
autologin = 0;

if (autologin < auth_level) {
fatal(net, "Authorization failed");
exit(1);
}


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Love Hörnquist Åstrand]

Post by Hubert Feyrer

Post by Christos Zoulas
I think you are mis-reading it; if there is not enough information from SRA
to log you in without a password, it will pass you to login to do it.

You mean it should run login(1) to ask for a login & passwort if no SRA
information is available, right? That's at least what I understand from

valid means that a telnet protocol (SRP, Kerberos, etc) have to validate you before you are handed over to login.

Love



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Iain Hibbert]

Post by Christos Zoulas
-- Subject: Re: telnetd: Authorization failed & Connection closed
| >> valid Only allow connections when the remote user can pro-
| >> vide valid authentication information to identify the
| >> remote user. The login(1) command will provide any
| >> additional user verification needed if the remote
| >> user is not allowed automatic access to the specified
| >> account.
| >>
| >> So vista and juniper don't implement SRA and the connection is not allowed.
| >> The default NetBSD telnetd configuration is more secure since passwords are
| >> not sent in plaintext over the network. This is why valid is the default.
| >> If you want to send your passwords in plaintext, feel free to change it for
| >> your system, but I don't think that the change is appropriate for everyone.
| >
| > And I can't have a steak because a three-year-old can't chew it?
| > Seriously, it sounds pretty broken to rather not have a working telnet than
| > to do just what telnet is intended for.
|
| Plus: I read the part about login(1) that it should fall back and ask me
| for my login & password. Apparently it does not - a feature?
I think you are mis-reading it; if there is not enough information from SRA
to log you in without a password, it will pass you to login to do it.

I think its not clear and you both misread it. There is no "if" here,
because the first sentence stands on its own. The "fallback to login(1)"
is what happens with "none" but Love got it right: "valid" requires SRA.

The page could have some clarifications as to what "authentication" means
in the context of telnetd and how "authentication" and "user verification"
are not the same.

As to whether we provide "none" as a useful example or a full security
"user" example that will have to be changed in the vast majority of cases
it probably doesn't matter, but "valid" is currently misleading and
probably the wrong setting to use for many..

iain



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alan Barrett]

Post by Hubert Feyrer

Post by Christos Zoulas
I think you are mis-reading it; if there is not enough information
from SRA to log you in without a password, it will pass you to login
to do it.

You mean it should run login(1) to ask for a login & passwort if no
SRA information is available, right? That's at least what I understand
from the manpage, and it's also what I think should happen.

By my reading of the man page, under "-a valid", the fallback to
login(1) applies only if the client has provided a valid username using
the AUTHENTICATION protocol option, but the client has not provided
sufficient other credentials to allow immediate access (e.g. a password
or kerberos ticket). If the client doesn't use the AUTHENTICATION
option at all, or if the client and server don't share any supported
AUTHENTICATION types, or if the client provides an invalid username,
then "-a valid" will not fall back to using login(1), and will simply
deny access.

If you need to handle clients that provide no AUTHENTICATION option
negotiation at all, then you need "-a none" or "-a off" at the server
side. I think this is all explained in the telnetd(8) man page, but
the wording could certainly be improved, especially in distinguishing
between information provided by the telnet AUTHENTICATION option (RFC
2941) and the more generic meaning of "authentication information".

--apb (Alan Barrett)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

On Mar 14, 2:27am, ***@feyrer.de (Hubert Feyrer) wrote:
-- Subject: Re: telnetd: Authorization failed & Connection closed

| On Sat, 13 Mar 2010, Christos Zoulas wrote:
| > valid Only allow connections when the remote user can pro-
| > vide valid authentication information to identify the
| > remote user. The login(1) command will provide any
| > additional user verification needed if the remote
| > user is not allowed automatic access to the specified
| > account.
| >
| > So vista and juniper don't implement SRA and the connection is not allowed.
| > The default NetBSD telnetd configuration is more secure since passwords are
| > not sent in plaintext over the network. This is why valid is the default.
| > If you want to send your passwords in plaintext, feel free to change it for
| > your system, but I don't think that the change is appropriate for everyone.
|
| And I can't have a steak because a three-year-old can't chew it?
| Seriously, it sounds pretty broken to rather not have a working telnet
| than to do just what telnet is intended for.
|

You have to edit /etc/inetd.conf to enable telnetd; we disable it by default
because it is insecure. We provide an example line for a more secure
configuration if you really want to use it as a hint. You are free to change
it to whatever you like, but the default is a suggestion for a secure
configuration. You should bother the vendors instead to implement SRA.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de