|
Grex > Garage > #23: Telnetd removal from OpenBSD >= 3.8 and grex. | |
|
| Author |
Message |
| 25 new of 57 responses total. |
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.
|
steve
|
|
response 25 of 57:
|
Jan 3 05:51 UTC 2006 |
The issue isn't if telnetd will work with future versions of
OpenBSD or not. There are others doing what we did, so I'm not
too concerned about being able to run it. The real question is
how do we best do this. I think giving several months notice
about a telnet phase out is the way to go, along with a web
page here explainging how to get ssh clients for Windows/MacOS.
|
cross
|
|
response 26 of 57:
|
Jan 3 15:40 UTC 2006 |
That sounds reasonable.
|
remmers
|
|
response 27 of 57:
|
Jan 4 16:47 UTC 2006 |
Re #25: Mac OS X comes with an ssh client.
|
bhoward
|
|
response 28 of 57:
|
Jan 12 09:22 UTC 2006 |
I get a lot of "helper" write sessions and just got a relevant one
today. Person logged in, wanted to be able to sign in with ssh but
didn't have a clue about unix/linux -- did not know what a shell
is, how to edit a file, make a directory but he did know about
putty...apparently was using it with other systems though how, I
don't know.
We will need to have clear instructions on how to locate and/or
generate your public key under putty and have a dead simple way for
them to cut-n-paste it to something that will properly configure
their .ssh/authorized* files.
Based on my conversation just now, this is something we will need
to transition very carefully and slowly. I would not want to scare
away non-technical users or those lacking exposure to unix. The
first of those two groups are often the ones that make the best
conferencing participants!
|
cross
|
|
response 29 of 57:
|
Jan 12 15:16 UTC 2006 |
Why not just start with passwords under PuTTY?
|