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.

The first of Grex's "Security Goals" is "Protecting the privacy of
users." Eliminating Telnet access would certainly be a part of this goal. 

Does eliminated telnet including eliminating similar daemons, like SSH? 
CAEN eliminated telnet some months back, but SSH is the replacement. 

I don't think eliminating telnet would mean eliminating SSH, since SSH
meets Grex's security goals.

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.

I would say either keep telnet around, or find a good SSH Java application and put it on the web page.

I vote for the later.

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. 

putty.ernie.org

PuTTY might be available in a UNIX compatibility package for MacOS too.

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/ .

Oh, it does? some people like GUIs too much.

Yes, but Darwin is a superb example of Intelligent Design.

<remmers ducks>

Oh, no. You've done it now, John...

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?

Well, if the users do not agree with the security goals, why don't we
change the goals, and not simply ignore them. :)

Todd, how does browser embedded SSH defeat the purpose of SSH key
exchange?

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.

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.

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.

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?

re #19
The problem is browser based SSH vs. host based telnet client has a miniscule
security enhancement but higher hinderance on the userbase.

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.

Does the FreeBSD port of telnetd compile on OpenBSD? I doubt FreeBSD will be eliminating it any time soon.

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.

   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.

That sounds reasonable.

Re #25:  Mac OS X comes with an ssh client.

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!

Why not just start with passwords under PuTTY?

I agree with resp:29. I wouldn't expect users to start using public key authentication right off the bat. Most people don't need that level of security, and most SSH clients lack a point-and-click way to do it.

I'm of the opinion to keep the telnetd going until major OS's ship with SSH
in the base system. I like the idea of security but not at the expense of
causing troubles for newbies. In my circumstance I am often on grex at work,
which uses Windows, and which has a corporate policy of not allowing
installation of software of company computers (see my point?), a web based
solution, like a java ssh would be nice, then theres the pesky surfcontrol

Can you execute a third-party command if it does not require
installation? If so, look into putty. You can have full ssh capabilities
with 2 files without having to install anything. As another alternative,
I think you can download MindTerm for free if you just want it for
personal use. You can then simply execute "java -jar mindterm.zip
cyberspace.org". 

Maybe a bit late in the discussion, I do hope telnet stays for awhile for us
non-techies on board. Though I've heard of ssh here, I have absolutely no idea
what that [or putty] is.  So an easy, non-techie based option for being on
grex would be cool.  :-)

Denise, I would say that using PuTTY is actually less "techie" than
using Windows telnet to access Grex.

Download a copy of PuTTY and give it a try.

I agree with nharmon; PuTTY is actually easier to use than Windows telnet.
Grab a copy from here: http://www.putty.nl/latest/x86/putty-0.58-installer.
exe
and give it a whirl....

What IS putty? Or does it explain what it is on the web site?  I guess its
just something that I haven't ever been exposed to [but am willing to try and
learn].

In a nutshell, PuTTY is a "terminal program" that allows you to connect to
remote systems (like grex) over the Internet.  It provides a superset of the
functionality of Windows telnet, which you might currently be using to connect
to grex.

Ok, thanks. I'll definitely check it out sometime in the next day or two when
I have a bit more time.  :-)

In circumstances where I've been forced to use Windows, I used PuTTY a
lot for connecting to systems with a terminal interface.  Definitely
recommended.

One downside was non-standard copy-paste behavior (borrowed from X
Windows, if I recall correctly) that could have unfortunate consequences
if you weren't aware of it.  I don't recall the exact details - it's
been a few years - and maybe it's been fixed.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss