49 new of 57 responses total.
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.
Anything you highlight in PuTTY is copied onto the clipboard and right clicking will paste everything in the clipboard.
Oh, right. Still not fixed, eh? Accidental copies followed by accidental pastes into a command line interface can have unfortunate consequences. Regardless what you think of Windows, applications for it *should* follow standard user interface behavior.
Fixed implies it is broken, John. I kinda like that behavior. :-)
Yeah, that's one thing about PuTTY that I do NOT like.
I love it. What I hate about PuTTY is that it's only necessary on Windows!
I don't mind the behavior either, but then I'm an X Window veteran, where it's standard. But if you're going to make a product that's friendly to the poor folks who are stuck on Windows, you shouldn't have unpleasant little traps waiting for them. I guess a user preference for X Window behavior or standard Windows behavior, with the latter being the default, would be ok.
I agree with remmers here.
It appears that my version of PuTTY allows you to turn this feature off. Window --> Selection --> (Options controlling copy and paste)
I kind of prefer the Windows behavior, and I configure my X systems to follow it.
It also occurrs to me that maybe it should be referred to as "Mac behavior," since it originated there and Windows copied it. ;)
I think the Principle of Least Surprise would dictate that PuTTY would use the Windows behavior by default under Windows. When in Rome, and all that....
OTOH, maybe the developers figure that the majority of people who use PuTTY will be familiar with X11 anyway, and thus TPOLS dictates that X11 behaviour by default is necessary?
That's entirely possible, too. I wonder what the rationale is....
Re #51: That assumption may have been valid when PuTTY was new, but I'm doubtful that it's still valid.
resp:53 For those of us who have been using PuTTY for years, the X11 way of doing it is ingrained in our brains, If they changed it to a Windows behaviour, it would break the kinesthetic processes for long- time users. I think that it might benefit from a large-print warning on the webpage and a smaller-print explanantion of how to make it more Windowsish (Windowsy? Windowsesque?).
Oh, I have no objection to the X-like behavior remaining but don't think it should be the default.
I tend to agree with Remmers on this. As long as the Windows behavior is available, however, I don't particularly care about the default.
Re: #53. Why's that? Most Windows users I know would consider typing commands into a text window, at best neolithic, and at worst bonkers.
You have several choices: