|
Grex > Garage > #23: Telnetd removal from OpenBSD >= 3.8 and grex. | |
|
| Author |
Message |
cross
|
|
Telnetd removal from OpenBSD >= 3.8 and grex.
| 
Dec 19 14:13 UTC 2005 |
The new version of OpenBSD (version 3.8 and, presumably, future
releases) have removed the telnet daemon from the distribution.
However, a number of grex users use telnet to connect to grex.
I'd like to see more information about how grex is dealing with
this basic OS change. Now, it's not terribly hard to just copy
the telnet source code from an older version of OpenBSD, but that's
a step that shouldn't be neglected, and yet there's no mention at
all of this change in grexdoc. So what's up with it?
|
| 57 responses total. |
nharmon
|
|
response 1 of 57:
|
Dec 19 15:48 UTC 2005 |
The first of Grex's "Security Goals" is "Protecting the privacy of
users." Eliminating Telnet access would certainly be a part of this goal.
|
rcurl
|
|
response 2 of 57:
|
Dec 19 18:39 UTC 2005 |
Does eliminated telnet including eliminating similar daemons, like SSH?
CAEN eliminated telnet some months back, but SSH is the replacement.
|
nharmon
|
|
response 3 of 57:
|
Dec 19 19:09 UTC 2005 |
I don't think eliminating telnet would mean eliminating SSH, since SSH
meets Grex's security goals.
|
bhoward
|
|
response 4 of 57:
|
Dec 19 23:47 UTC 2005 |
Integrating the telnet sources we used is on my short list. It is
blocked pending some answers to questions I've raised regarding
grexsoft and its reintegration with grexdoc.
We've made good progress since the upgrade cleaning up various loose
ends that never made it into or were not kept updated in grexdoc. I'd
love to finish off telnetd and grexsoft ASAP.
As for the other question, whether to retire telnetd entirely...I'd
be very happy to do that but it won't fly unless we write up some
very easy-to-understand instructionas for newusers on how to install
and configure PuTTY (or its moral equivalent). Restricting network
logins to ssh may raise the technical bar too high for some of our
newusers without decent documentation.
|
gull
|
|
response 5 of 57:
|
Dec 21 02:58 UTC 2005 |
I would say either keep telnet around, or find a good SSH Java
application and put it on the web page.
|
nharmon
|
|
response 6 of 57:
|
Dec 21 03:11 UTC 2005 |
I vote for the later.
|
rcurl
|
|
response 7 of 57:
|
Dec 21 03:15 UTC 2005 |
When I travel I'm often forced to use Windows machines. I download PuTTY
to them. (You can follow my trail that way.) Why not just include a link
to the PuTTY site on the web page? You don't have to do anything to install
it after downloading. Just run it as an app.
|
naftee
|
|
response 8 of 57:
|
Dec 21 05:01 UTC 2005 |
putty.ernie.org
|
twenex
|
|
response 9 of 57:
|
Dec 21 11:16 UTC 2005 |
PuTTY might be available in a UNIX compatibility package for MacOS too.
|
remmers
|
|
response 10 of 57:
|
Dec 21 13:22 UTC 2005 |
OS X comes with ssh. Why would you need PuTTY?
I agree with Bruce's #4, last paragraph. Re the suggestion in #5 for
browser-embedded SSH - I think that's a cool idea. There's some
interesting work on using JavaScript and XMLHTTPRequest for that, which
might be a better way to go than Java applets. See for example
http://anyterm.org/ .
|
twenex
|
|
response 11 of 57:
|
Dec 21 13:23 UTC 2005 |
Oh, it does? some people like GUIs too much.
|
remmers
|
|
response 12 of 57:
|
Dec 21 15:13 UTC 2005 |
Yes, but Darwin is a superb example of Intelligent Design.
<remmers ducks>
|
twenex
|
|
response 13 of 57:
|
Dec 21 15:56 UTC 2005 |
Oh, no. You've done it now, John...
|
tod
|
|
response 14 of 57:
|
Dec 27 21:26 UTC 2005 |
Browser embedded SSH defeats the purpose of SSH key exchange. Why not
continue using older telnet source rather than shoving "Security Goals" down
the throat of users that may not care that much?
Perhaps requiring SSH of members(i.e. outbound telnet) could meet the security
goals without infringing on the vast array of users?
|
nharmon
|
|
response 15 of 57:
|
Dec 27 22:32 UTC 2005 |
Well, if the users do not agree with the security goals, why don't we
change the goals, and not simply ignore them. :)
|
bhoward
|
|
response 16 of 57:
|
Dec 28 00:51 UTC 2005 |
Todd, how does browser embedded SSH defeat the purpose of SSH key
exchange?
|
cross
|
|
response 17 of 57:
|
Dec 28 01:30 UTC 2005 |
Presumably, the user who logins in via browser embedded SSH is transient
in nature, and not likely to login from the same computer that often. Then,
they can't tell if the host key changes easily.
The SSH model allows one to test the validity of a host key because it
presumes the keys change rarely and are widely published. The embedded
browser model does away with some of those assumptions.
|
tod
|
|
response 18 of 57:
|
Dec 28 16:09 UTC 2005 |
In addition to what Dan said, applet based SSH would leave behind information
such as hostname, public host key, username, and possibly even password
(assuming someone before you had loaded the applet on the machine with the
"record" function enabled.)
I'm still not sure how the majority of the userbase would benefit from being
denied telnet unless future versions of Windows(which the majority of Grexers
use) include SSH.
|
gull
|
|
response 19 of 57:
|
Dec 28 20:30 UTC 2005 |
The problems listed in resp:18 are inherent with using a public
computer. They're not particular to SSH; it just doesn't solve them.
He's right, though, that you lose SSH's resistance to "man in the
middle" attacks this way. About all it protects you from, then, is
packet sniffing.
|
bhoward
|
|
response 20 of 57:
|
Dec 29 06:14 UTC 2005 |
Couldn't we package up a special release of this browser ssh client
to be downloadable from grex with grex's public host key preloaded
into it to address the man-in-the-middle problem?
|
tod
|
|
response 21 of 57:
|
Dec 29 06:57 UTC 2005 |
re #19
The problem is browser based SSH vs. host based telnet client has a miniscule
security enhancement but higher hinderance on the userbase.
|
cross
|
|
response 22 of 57:
|
Dec 29 15:18 UTC 2005 |
Well, I think that protecting against packet sniffing has a big advantage,
but the point of this whole thread is getting rid of telnet in favor of SSH
only. The fact of the matter is, despite the foot stamping of the OpenBSD
crowd, it's just not going to happen any time soon (not, as Todd points out,
until there are widely available SSH clients bundled with the major OS
vendors). So how does one support telnetd on an operating system that's
made it clear has no intention of doing it itself going forward? That's
what's at issue.
Personally, I'm rather sad to see them remove telnetd. Maybe I can see
them removing the non-encrypted, non-Kerberized versions, but it's a bummer
to me to see those go away.
|
gull
|
|
response 23 of 57:
|
Dec 29 19:36 UTC 2005 |
Does the FreeBSD port of telnetd compile on OpenBSD? I doubt FreeBSD
will be eliminating it any time soon.
|
bhoward
|
|
response 24 of 57:
|
Dec 30 05:02 UTC 2005 |
We grabbed the telnetd from 3.7 and recompiled that for 3.8 when we
did the upgrade. Until we decide to retire telnet access, I suggest
sticking with that for the time being.
|