Feedback on change to rshd...

[Darren Reed]

In doing test development for ipfilter, I've become aware of what I'd
consider to be a bug in rshd: it does not force the use of the same
local address for the source of the stderr connection as was the
destination for the inbound connection - see PR#46703. This
behaviour seems to be common to BSD but not necessarily
other platforms. Details including a patch can be found here:

http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46703


Whilst the patch as it is works, I'm unsure as to whether that is
the correct patch or not. To be specific, whether the interface
that has been added to unistd.h should be rresvport_af_addr()
or something else - for example rresvport_fd(), where fd is
the original connection from which both the family and local
address can be determined.

Thoughts?

Darren


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

[Christos Zoulas]

Post by Darren Reed
In doing test development for ipfilter, I've become aware of what I'd
consider to be a bug in rshd: it does not force the use of the same
local address for the source of the stderr connection as was the
destination for the inbound connection - see PR#46703. This
behaviour seems to be common to BSD but not necessarily
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46703
Whilst the patch as it is works, I'm unsure as to whether that is
the correct patch or not. To be specific, whether the interface
that has been added to unistd.h should be rresvport_af_addr()
or something else - for example rresvport_fd(), where fd is
the original connection from which both the family and local
address can be determined.

af_addr seems more general to me.

christos


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

[Lloyd Parkes]

Post by Darren Reed
In doing test development for ipfilter, I've become aware of what I'd
consider to be a bug in rshd

Is there any way at all that anyone can justify shipping rshd and friends as part of NetBSD? The only justification I can think of would be if rsh can do host verification via Kerberos, but ssh could do that too with the appropriate patches. At least telnet is a useful network diagnostic tool. Hmm, if we stopped shipping telnetd, would anyone notice?

Cheers,
Lloyd


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

[Lloyd Parkes]

Post by Lloyd Parkes

Post by Darren Reed
In doing test development for ipfilter, I've become aware of what I'd
consider to be a bug in rshd

Is there any way at all that anyone can justify shipping rshd and friends as part of NetBSD? The only justification I can think of would be if rsh can do host verification via Kerberos, but ssh could do that too with the appropriate patches. At least telnet is a useful network diagnostic tool. Hmm, if we stopped shipping telnetd, would anyone notice?

There are (still) lots of systems that only can use rsh to communicate that nothing can be done about.

You are going to have to name them because the reason I suggested this is that I can't think of any. Even Cisco routers speak ssh these days. Also, as with telnet, shipping the server component is separate from shipping the client. The servers could all be moved to pkgsrc. Possibly with a new category called "insecurity" so people know everything in there is a bad idea. ;-)

And telnetd is very useful in a kerberized environment.

sshd works fine with Kerberos. I threw away my RSA key pairs on my home systems years ago and turned on the ssh Kerberos options. It took a few goes to find the right options, and it works just fine. As I alluded to in my previous email, ssh doesn't support Kerberos host verification, but there are patches floating around the net for that, and the Mac OS X ssh has those patches (or equivalent) applied, so this would be ground breaking.

Cheers,
Lloyd


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

[Mouse]

Post by Lloyd Parkes
Even Cisco routers speak ssh these days.

While I haven't paid any particular attention to manufacturers, if
they're anything like the routers I've had run-ins with recently, they
don't speak ssh, but rather some closely related protocol which does
not actually involve support for the DNS-based extensibility mechanism.
I routinely have to tell my client to shut off all extensions in order
to keep the other end from ungracefully closing the connection.

Post by Lloyd Parkes
Possibly with a new category called "insecurity" so people know everything i$

Why does everyone seem to think everything that's not suitable for the
open Internet is not suitable anywhere?!

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

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

[Lloyd Parkes]

Post by Mouse

Post by Lloyd Parkes
Possibly with a new category called "insecurity" so people know everything i$

Why does everyone seem to think everything that's not suitable for the
open Internet is not suitable anywhere?!

Because even when you aren't connected to the internet, you are still connected to the internet. You know those awful movies where they show people breaking in to computer systems with graphics of connections bouncing through half a dozen systems to get to their target? I've seen someone do that in real life, and it really does work that way, just with fewer CGI pictures of satellites. All you need to start the ball rolling is a funny cat picture.

The reason most of us don't get owned is because we don't have enough goodies to make it worth anyone's trouble. I'm pretty sure that's not a good security model. Just in case anyone's wondering, it's not a good security model because it assumes we know what other people want, and we only ever know that in general. Unfortunately, when someone attacks you, it's always a specific person, rather than the Internet in general that's doing it.

Cheers,
Lloyd


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

[Lloyd Parkes]

Is there any way at all that anyone can justify shipping rshd and friends as$

Why would they need justifying?

Their security mechanisms aren't actually security, and quite frankly aren't much of a mechanism either. The last thing TNF needs is to have 10,000 NetBSD based consumer NAS boxes start emailing out pharma spam.

Cheers,
Lloyd


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

[Darren Reed]

Post by Lloyd Parkes

Is there any way at all that anyone can justify shipping rshd and friends as$

Why would they need justifying?

Their security mechanisms aren't actually security, and quite frankly aren't much of a mechanism either.

Look, I don't know why you decided to get on the ssh soap box but quite clearly you have an oversubscribed opinion of how many security problems ssh fixes.

In certain environments the use of ssh is reduced to encrypted rsh. i.e lets slow down rsh and make it encrypted for no benefit other than there is no way to turn off the encryption. And sometimes you can't ever pretend that the encryption provides real secrecy.

Post by Lloyd Parkes
The last thing TNF needs is to have 10,000 NetBSD based consumer NAS boxes start emailing out pharma spam.

This statement has nothing to do with this project (NetBSD.)

Darren


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

[Jukka Ruohonen]

Post by Lloyd Parkes

Post by Darren Reed
In doing test development for ipfilter, I've become aware of what I'd
consider to be a bug in rshd

Is there any way at all that anyone can justify shipping rshd and friends
as part of NetBSD? The only justification I can think of would be if rsh
can do host verification via Kerberos, but ssh could do that too with the
appropriate patches. At least telnet is a useful network diagnostic tool.
Hmm, if we stopped shipping telnetd, would anyone notice?

Supposedly even something like rsh can be secure to some extent if done
via IPSec. But to accelerate: can anyone think of any use for phones(1) or
few other relics residing firmly in /etc?

- Jukka.

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

[Matthias Kretschmer]

Post by Lloyd Parkes
Is there any way at all that anyone can justify shipping rshd and friends as part of NetBSD? The only justification I can think of would be if rsh can do host verification via Kerberos, but ssh could do that too with the appropriate patches. At least telnet is a useful network diagnostic tool. Hmm, if we stopped shipping telnetd, would anyone notice?

There are (still) lots of systems that only can use rsh to communicate that nothing can be done about.

In addition to this, one shouldn't forget that with IPv6 IPSec is an
requirement. If you use IPSec for encryption and authentification of
two computers/systems anyway, why put ssh on top and do it again for the
communication of those two?

--
Matthias

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

[Matthew Mondor]

On Sun, 15 Jul 2012 11:15:49 +0300

Post by Jukka Ruohonen
Supposedly even something like rsh can be secure to some extent if done
via IPSec. But to accelerate: can anyone think of any use for phones(1) or
few other relics residing firmly in /etc?

Probably only because of its relation to tip(1), which is still useful
for serial consoles.

Possible issues with moving rsh and friends (or tip) to pkgsrc might be
that they could more easily become unmaintained, and their
cross-compilation could become harder...

[Christos Zoulas]

Post by Matthias Kretschmer
In addition to this, one shouldn't forget that with IPv6 IPSec is an
requirement. If you use IPSec for encryption and authentification of
two computers/systems anyway, why put ssh on top and do it again for the
communication of those two?

Its implementation is mandatory, its usage is not :-)

christos


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

[Brett Lymn]

Post by Lloyd Parkes

Is there any way at all that anyone can justify shipping rshd and friends as$

Why would they need justifying?

Their security mechanisms aren't actually security, and quite frankly aren't much of a mechanism either. The last thing TNF needs is to have 10,000 NetBSD based consumer NAS boxes start emailing out pharma spam.

This is not really much of an argument - there are dozens of ways that
someone could achieve this scenario including misconfiguring postfix.
You have to turn rexecd on, it is shipped disabled. As others have
pointed out there are still things that use rsh, being able to do a
remote dump from a legacy system to a tape drive on NetBSD is useful to
some. The r* commands may have their faults but in some circumstances
they are appropriate.

Personally, I think it arrogant that we (NetBSD) take the nasty sharp
tools away because they are "too dangerous", it sort of implies "no, you
are too stupid to know better so you cannot have these things".
--
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited. If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility. It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."



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

[Mouse]

[...]. But I personally prefer the use of ktelnet and krlogin.
Why? Well, due to ssh's complexity, it is very difficult to debug
problems when things go wrong. You have a hard time even getting the
real Kerberos error message out of ssh in a number of cases.

This is a quality-of-implementation issue, not anything inherent to
Kerberized ssh.

It's not clear whether you're talking about the protocol or the
particular implementation of it that NetBSD currently ships with. If
the former, this is unjustified; if the latter, it's justified but
there is then, at least potentially, a third option, that being to use
some other implementation. (What that `other implementation' might be
I don't know; the only other implementation I know anything significant
about is my own, and it currently has no Kerberos support.)

Also, the whole thing about the ssh developers hating Kerberos for
some strange reason doesn't really help things either.

This too is an implementation-specific issue.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

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

[Ken Hornstein]

Post by Mouse

Why? Well, due to ssh's complexity, it is very difficult to debug
problems when things go wrong. You have a hard time even getting the
real Kerberos error message out of ssh in a number of cases.

This is a quality-of-implementation issue, not anything inherent to
Kerberized ssh.

I agree ... but are we talking about "ssh the protocol" versus
"Kerberized telnet the protocol", or the actual code that you have
to use on a daily basis? Essentially there is one major ssh
implementation in widespread use (at least one that supports
Kerberos), so in my mind that's the real issue. And that has some
pernicious effects ... when the ssh developers hate Kerberos, the
distributed versions of ssh don't have good Kerberos support. That
makes it hard to deploy ssh with Kerberos support. Yes, you can
distribute your own versions, and I've been part of that ... but
that's a gigantic pain in the ass.

--Ken

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

[Lloyd Parkes]

Post by Matthew Mondor
On Sun, 15 Jul 2012 11:15:49 +0300

Post by Jukka Ruohonen
Supposedly even something like rsh can be secure to some extent if done
via IPSec. But to accelerate: can anyone think of any use for phones(1) or
few other relics residing firmly in /etc?

Probably only because of its relation to tip(1), which is still useful
for serial consoles.

I've used tip and /etc/remote a fair bit, but the /etc/phones file doesn't seem to be useful anymore.

Cheers,
Lloyd


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