Kerberos Support In OpenSSH

sad. by Anonymous Coward · 2003-06-30 01:44 · Score: 1, Funny

What's sad is that at first glance I thought draft-ietf-secsh-gsskeyex said goatsecx. It is quite a jumble of acronyms, isn't it though?

Re:sad. by Anonymous Coward · 2003-06-30 01:57 · Score: 0

Don't worry, it's natural to be goatse-aware. Just imagine tripping over one of those landmines while your boss is watching. Your apprehensiveness is well-deserved.
Re:sad. by Anonymous Coward · 2003-06-30 02:39 · Score: 0

Sadly enough I thought the same thing

RSA? by paranode · 2003-06-30 01:44 · Score: 3, Insightful

Is there any advantage to using this over the already-usable RSA key authentication in SSH?

Re:RSA? by Mark+Bainter · 2003-06-30 02:14 · Score: 5, Insightful

Yes. Scenario: 500 *nix servers, team of 10 administrators. Solution 1: Each user gets a login created on each machine, and then they login, create an ssh key, and distribute the public key to all other machines. Later, when that person leaves, all those keys and all those user accounts get deleted. (Given, you could use NIS/LDAP/etc to try and alleviate the user-account side of the issue. But you didn't mention that as part of your RSA solution, and note that each of these solutions has potential inherent security problems.) Solution 2: Setup kerberos. Authenticate all users for all machines securely from one location. Add and delete user accounts from one location.

--
"No nation could preserve its freedom in the midst of continual warfare."
--James Madison
Re:RSA? by hbo · 2003-06-30 02:16 · Score: 5, Informative

The main advantage of using Kerberos for key exchange is the elimination of the known_hosts file, and the tendency for ssh users to accept any
old key offered by the server the first time they connect. This common behavior exposes the user to the risk of man-in-the-middle attacks. If I've tricked your stack into connecting to me instead of the host you thought you were getting, I can spoof both ends of the connection and intercept your traffic in the clear. Also, Kerberos authentication is two-way (server to client AND client to server)

--
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
Re:RSA? by coyote-san · 2003-06-30 02:40 · Score: 2, Informative

Yes. Many of them.

SSH is great for what it does, but it really doesn't do that much. Most people don't notice this since they don't need it to do much - for them it's just a better telnet.

But it scales horribly, look at the other comments.

Worse, SSH drops authentication information. This doesn't sound like much until you've worked in an environment where clients and servers can perform mutual authentication "beneath the surface," but once you have going back is painful.

--
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Re:RSA? by The+Vorlon · 2003-06-30 02:44 · Score: 4, Informative

If you're deploying SSH in an environment that already uses Kerberos, there absolutely is an advantage. GSSAPI external key exchange means that, if you're authenticated to the Kerberos realm, you have tickets that will let you connect to any other machine in the realm (or in a trusted realm) without having to do out-of-band verification of the RSA key's fingerprint.

With traditional RSA key authentication in SSH, the security of the SSH connection requires that either the user is diligent enough to check every new RSA fingerprint when it pops up, or that the site admin has stored all of the machine fingerprints in /etc/ssh/ssh_known_hosts. With Kerberos, mutual authentication is done for you. This is a very big advantage for anyone with a lot of machines, particularly if Kerberos is in use anyway.
Re:RSA? by yandros · 2003-06-30 03:24 · Score: 2, Informative

Kerberos is used (although not as uniformly as might be wished) in a few decent remote filesystems as well. This can be a real boon for such setups (which should be more common, IMHO). Without it, you can get a secure login to a remote machine, but still need to provide that machine with an authenticator for secure network services (such as afs, nfs, ftp, imap, etc.).

At MIT, at least a year or two back, we had people using a mixture of ssh and kerberized rlogin just to deal with the ticket-forwarding issues.
Re:RSA? by More+Trouble · 2003-06-30 04:43 · Score: 2, Insightful

Solution 2: Setup kerberos. Authenticate all users for all machines securely from one location. Add and delete user accounts from one location.

Depends what you means by "accounts". Any way you look at it, you'll want to set up something like LDAP for distributing the equivalent of /etc/passwd data. Kerberos gives you user authentication, and the ability to disable user accounts globally -- though not within the ticket lifetime! Kerberos doesn't give you much in the way of provisioning accounts, which is what your statement implies.

:w
Re:RSA? by More+Trouble · 2003-06-30 04:47 · Score: 2, Interesting

The main advantage of using Kerberos for key exchange is the elimination of the known_hosts file, and the tendency for ssh users to accept any old key offered by the server the first time they connect. This common behavior exposes the user to the risk of man-in-the-middle attacks. If I've tricked your stack into connecting to me instead of the host you thought you were getting, I can spoof both ends of the connection and intercept your traffic in the clear.

Sadly, recent implementations of MIT Kerberos automatically reverse DNS names. So, if I can spoof the user's target DNS name to point to my blackhat machine, the Kerberos libraries will cheerfully reverse my IP address to get the Kerberos principle for authentication.

:w
Re:RSA? by Wolf+Eyelash · 2003-06-30 05:18 · Score: 2, Informative

Sadly, recent implementations of MIT Kerberos automatically reverse DNS names. So, if I can spoof the user's target DNS name to point to my blackhat machine, the Kerberos libraries will cheerfully reverse my IP address to get the Kerberos principle for authentication.

But what does that buy you? I assume that a KDC must encrypt part of it's reply with the host principal's secret key that must also be stored and read from a local keytab file that typically only root can update. How can you spoof this part of the validation?
Re:RSA? by The+Vorlon · 2003-06-30 13:09 · Score: 1

That still doesn't get you anywhere unless you manage to subvert the host key of some machine that's a member of the Kerberos realm. Once an attacker has managed to compromise both a host key and the DNS, yes, it's possible to fool a client; but an almost equivalent exploit is possible with non-Kerberized ssh as well.
Re:RSA? by More+Trouble · 2003-06-30 18:00 · Score: 1

I assume that a KDC must encrypt part of it's reply with the host principal's secret key that must also be stored and read from a local keytab file that typically only root can update.

Sure, so the blackhat machine must have a host principal. That might be secure enough in a small environment. In an enterprise, it's not. You can't guarantee that the trustworthiness of every machine in an enterprise. If you could, you would need Kerberos much less.

:w

ssh and telnet by ih8apple · 2003-06-30 01:47 · Score: 3, Interesting

To avoid moronic passwords being captured over cleartext telnet or ftp sessions, I think telnet and ftp should be disabled across the world with very limited exceptions. All UNIX and Linux distros should have cleartext protocols disabled by default. Once one account is comprised, the rest of a system usually goes very easily. Regardless of adding Kerberos support in OpenSSH, any kind of ssh or sftp connection immediately improves the worldwide crackability situation. (and yes, I just made up the word crackability=ease of access for crackers)

--

Why do I h8 apple?

Re:ssh and telnet by Anonymous Coward · 2003-06-30 01:52 · Score: 2, Insightful

We'd also better disable ESMTP and POP3 too. You don't mind waiting for your mail while we write a secure replacement, do you?
Re:ssh and telnet by Surak · 2003-06-30 01:54 · Score: 4, Insightful

Secure IMAP with Kerberos support. :-P

--
My journal has hot /. gossip.
Re:ssh and telnet by lysander · 2003-06-30 01:56 · Score: 3, Informative

there exists kerberos authenticated SMTP and also kerberos authenticated POP (KPOP). both are in use at MIT, but the former is a relatively new service.

--
GET YOUR WEAPONS READY! --DR.LIGHT
Re:ssh and telnet by jarkko · 2003-06-30 01:57 · Score: 5, Insightful

All UNIX and Linux distros should have cleartext protocols disabled by default.

I still use telnet, ftp and even rsh as well and I don't feel insecure about it. Transport-mode IPSec between hosts really helps a lot here...

The "moronic passwords"-issue comes mainly from pop3 and different web-sessions these days. What the world really needs is opportunistic IPSec.
Re:ssh and telnet by isa-kuruption · 2003-06-30 02:04 · Score: 5, Insightful

I will paraphrase a quote from Mr Bruce Schneier:

"No matter what security measures you implement, the end users are still the weakest link in the chain."

I think it speaks for itself. Passwords can be brute forced via secure protocols as well. Passwords can be copied from stick-it notes on people's monitors, or from knowing their maiden name.

While cleartext protocols should be disabled, many places use them... a LOT. And while I know SSH can replace most of their functionality, many places have scripts that have been running for years that would need man power to rewrite (even if changing only one line) which makes it difficult for many organizations decide this is a priority.

Heck, I had a hell of a time convincing our organization to move from SSHv1 to SSHv2 due to the man-in-the-middle attacks.
Re:ssh and telnet by sporty · 2003-06-30 02:10 · Score: 2, Funny

Crackability. Sounds like a word nabisco would use.

"Ritz.. now with more crackability." /bored

--
-
ping -f 255.255.255.255 # if only
Re:ssh and telnet by Anonymous Coward · 2003-06-30 02:26 · Score: 2, Informative

Absolutely agreed.

From what I've seen, the main reason people use telnet etc. is simply because it's enabled by default. They are too clueless to install SSH (and often too clueless to enable telnet if it were disabled), sometimes they haven't even heard of it.

Many open source OS distributions (at least the *BSDs, probably most if not all Linux distributions) already include SSH and disable almost everything in inetd.conf by default.

MacOS X also includes (but doesn't enable) SSH and disables everything in inetd.conf, and only makes SSH easy to enable (checkbox in the system configuration app).

But Solaris, HP-UX, AIX, Tru64...no such luck (disclaimer - I haven't looked at the most recent versions of some of those systems).
Re:ssh and telnet by ave19 · 2003-06-30 02:28 · Score: 1

or, for the not so paranoid, you could use kerberos and ftp/filezilla. no moronic passwords in the clear at all.

--
...or maybe not.
Re:ssh and telnet by ave19 · 2003-06-30 02:38 · Score: 3, Insightful

Would it be more accurate to say, you wish to see all cleartext services disabled by default? Since ftp, telnet, rlogin, etc. all have ciphered, non-cleartext authentication methods with mutual authentication?

Where I work, we allow kerberized telnet, but not cleartext telnet. Same for ftp.

-ave

--
...or maybe not.
Re:ssh and telnet by killmenow · 2003-06-30 03:32 · Score: 2, Informative

What the world really needs is opportunistic IPSec.
Done.
Re:ssh and telnet by iabervon · 2003-06-30 04:12 · Score: 1

SMTP doesn't have passwords at all, and POP3 (like IMAP) can be run over SSL in a standard way. SMTP can't be made more "secure" in any particularly clear sense, because it doesn't involve any recipient authentication (in any case, the most common reason for the wrong person getting an email message is that it's sent to the wrong address, and delivered correctly).
Re:ssh and telnet by iabervon · 2003-06-30 04:23 · Score: 3, Insightful

You really mean cleartext authentication, not cleartext protocols. Cleartext ftp is fine for anonymous downloads; cleartext HTTP is fine so long as you don't use passwords or authentication cookies (note that you and I are both posting in violation of what we're saying. But anyway...); cleartext telnet is fine for rainmaker.wunderground.com; and so forth.

I find it odd that systems package together telnet (a nice wrapper for TCP, with a few extra features; very useful for a number of things, including getting the weather) with telnetd (a program for providing shell access to attackers, simply based on the few extra features over TCP. Similarly ssh and sshd. Programs that make connections are very different from programs that provide shell access.

Personally, I think Linux distros should have remote login disabled by default. Anyone who actually wants it will know how to enable it, and will hopefully pick a sane protocol to use to do so.
Re:ssh and telnet by noahm · 2003-06-30 06:20 · Score: 2, Informative

Part of what you need in a security system is a guarantee that a communications session will be encrypted. Without that guarantee, you can not trust the connection. Opportunistic IPsec does not provide you with any guarantee that communication with a given host is encrypted. If possible, it will be, but it just as well may not.
One must understand the rationale for developing opportunistic encryption. It is not to provide for secure communication. It exists to clog the spooks' sniffers with as much unusable data as possible. There is a distinction there. Yes, for the purposes of the data contained within that IPsec payload the result is the same, but users would be absolutely insane to switch from ssh to telnet+opportunistic IPsec and expect the same level of protection.
IPsec in general is a very different story, and something that I use extensively in production.
noah
Re:ssh and telnet by oddityfds · 2003-06-30 07:24 · Score: 2, Informative

There's KRB5/GSSAPI/IMAP support in Ximian Evolution nowadays. You need version 1.2.4 or later. It's enabled in the binaries for RHL9 from Ximian. A nice single-sign-on mail solution for sites with a Kerberos infrastructure.
Re:ssh and telnet by Anonymous Coward · 2003-06-30 15:13 · Score: 0

Well, your organization is dumb because there are
no MITM attacks against ssh1 that are not going to
work against ssh2 as well.
Re:ssh and telnet by kasperd · 2003-06-30 21:25 · Score: 1

Passwords can be copied from stick-it notes on people's monitors, or from knowing their maiden name.

I tell you, I have no stick-it notes on my monitor, and I am not married. Now you tell me, what is the new password I got from /dev/random yesterday?

--

Do you care about the security of your wireless mouse?
Re:ssh and telnet by Jellybob · 2003-07-01 12:50 · Score: 1

Congratulations. You are not a retard.

However when it comes to passwords most of the people on a corporate network will be, and it doesn't have to be *your* password I crack, just *a* password.
Re:ssh and telnet by Vengeful+weenie · 2003-07-02 05:47 · Score: 1

This goes back to a conversation I was having the other day over the design philosophy of secure TCP. I would prefer the design of IPsec, where the security is layered into the network itself. The problem arises from the fact that there is no way programmatically to ask for a secure connection. All of the work needs to be done by an admin., and all of the details need to be worked out ahead of time (what keys, distribution, etc.) IPsec also doesn't have user key support last time I checked.
The ideal secure connection would allow secure authentication, and no data confidentiality, like Kerberos; a known host connection w/ no user auth; or a fully secured connection (like ssh), or open security (ie. no security). The problem is that the socket abstraction (which has a few basic flaws in it) no longer stretches to compensate for the network underpinnings. ssh/ssl suffer from this in that the application has to take on the security problem.
All of the network security methods lack a good, fundamental authentication model. I think that this is where Kerberos works as a good add-on. Until a better trust model can be designed network security seems doomed to be a complicated mess.

Re:Time for Linux to catch up? by tempmpi · 2003-06-30 01:50 · Score: 4, Insightful

Linux has had Kerberos and IPSec for long time, too. This is not a Linux vs. Windows thing, it is about the best way to use Kerberos authentification for SSH.

--
Jan

Re:Time for Linux to catch up? by axxackall · 2003-06-30 01:50 · Score: 2, Informative

Forever? Do you mean since Win2k?

By the way, I've been using Kerberos in Slackware Linux in 1996. Does it fell to your definition of "forever"?

--

Less is more !

Re:Time for Linux to catch up? by coyote-san · 2003-06-30 01:55 · Score: 4, Informative

Moderators on crack again?

Unix systems have had Kerberos forever, via both commercial implementations and the MIT reference implementations. Linux DISTRIBUTIONS largely haven't had them, but that's because of the hassles with US export controls in place until recently. Anyone likely to use Kerberos also knew how to build the MIT reference implementation from scratch, if necessary.

Windows is actually a "Johnny-come-lately" - I had been working on unofficial Debian packages of the MIT Krb5 packages for about 3 years when MS announced Windows would use Kerberos in new products, and as usual they attempted to add their own unpublished proprietary crap to it. I (and many other people) didn't mind them adding add'l field specific to the W2K client model, but there was no need for the initial draconian non-disclosure policies.

--
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken

PicoBSD by Anonymous Coward · 2003-06-30 01:55 · Score: 0

PicoBSD

Well that's a start ... but ... by SuperDuG · 2003-06-30 01:59 · Score: 0, Redundant

OpenSSH is named Open for good reason. It's Open Sourced! The great thing about it is that you can go ahead and put kerberos support in at any time you want and re-release it. I'm not quite sure what license OpenSSH runs on (guessing BSD, but to lazy to confirm), but you might even be able to release binary only versions and make some dough off of it all as well.

Sorta just food for thought.

--
Ignore the "p2p is theft" trolls, they're just uninformed

Re:Well that's a start ... but ... by Spyder · 2003-06-30 02:06 · Score: 3, Informative

Yes it is BSD, it's an OpenBSD project.

--
Spyder

Re:Goatse Receiver, ass contortionist, dead at 55 by Anonymous Coward · 2003-06-30 02:02 · Score: 2, Funny

it would be funny if there was a goatse article on slashdot, and all the goatse trolls were on topic.

Windows 2K/XP and KErberos by tigersha · 2003-06-30 02:03 · Score: 4, Interesting

IS is possible to log in to an Active Directory Domain and use those credntials for Kerberos. I am not an expert on this but AFAIK Microsft uses a somewhat bastartized version of Kerberos for Active Directory. I am interested in tusing thos tickets to authenticate with Normal SSH (the Windows version from SSH Labs) from my Windows box. Is this possible?

--
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism

Re:Windows 2K/XP and KErberos by Anonymous Coward · 2003-06-30 02:13 · Score: 3, Informative

I believe recent Kerberos for Windows distributions from MIT include ms2mit.exe, which you can use to do that conversion.

MIT has single-signon working (the conversion happens automatically) but I don't know if they released the code.
Re:Windows 2K/XP and KErberos by deranged+unix+nut · 2003-06-30 02:43 · Score: 0

Microsoft Active Directory is compatibe with MIT Kerberos version 5.
Re:Windows 2K/XP and KErberos by Anonymous Coward · 2003-06-30 05:16 · Score: 2, Informative

Yes, Non-MS kerberos systems will ignore the MS data in the Kerberos ticket and accept it as authentication if you are part of a Kerberos realm that uses a MS KDC. For example, OS X can use an Active Directory server as a KDC and pass the TGT to a cyrus IMAP server. The IMAP server will ignore the MS junk in the ticket and as long as you check out, you can get your mail. The problem is going the other way. You cannot, get a TGT from a MIT KDC and pass it to a MS Kerberized service.
Re:Windows 2K/XP and KErberos by Directrix1 · 2003-07-02 04:48 · Score: 1

No AD is compatible with MIT Kerberos version 5 clients. Conversely, windows cannot authenticate to an MIT KDC.

--
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF

Other parties? by Nissyen · 2003-06-30 02:05 · Score: 5, Funny

...on behalf of the MIT Kerberos team and several other parties interested in the availability of Kerberos authentication...

There are other parties interested in Kerberos?

--
Idol Star Astronomer

Re:Other parties? by finkployd · 2003-06-30 02:33 · Score: 3, Informative

There are other parties interested in Kerberos?

Yeah, most large Universities.

Finkployd
Re:Other parties? by ave19 · 2003-06-30 02:41 · Score: 1

The DOD is big on it, also.

--
...or maybe not.
Re:Other parties? by azimir · 2003-06-30 05:15 · Score: 2, Insightful

Yes, the OpenAFS guys use it for authenticating users of AFS mounts. Getting Kerberos working is vital to a third-party ticket/key/token/whatever system right now.

Re:Which is worse? by Anonymous Coward · 2003-06-30 02:08 · Score: 0

worse are the morons who pick something to bitch about that they don't jack about, nor probably have the capability to know jack about.

kerberos+ssh+putty by ave19 · 2003-06-30 02:10 · Score: 5, Informative

i have a mod for putty that can do gssapi+kerberos auth for users. windows client to the linux/unix openssh servers.

we're beta testing (or will start soon) but it works!

respond if you're interested...

--
...or maybe not.

Re:kerberos+ssh+putty by Raleel · 2003-06-30 02:48 · Score: 1

um, ya!

hello, this would be awesome! Definately interested.

--
-- Who is the bigger fool? The fool or the fool who follows him? --
Re:kerberos+ssh+putty by ave19 · 2003-06-30 02:57 · Score: 2, Interesting

Okay, I made a throw away email address for this. Send me a note and I'll hook you up the best I can:

kputty@jaccard.us

Thanks!

--
...or maybe not.
Re:kerberos+ssh+putty by ave19 · 2003-06-30 03:08 · Score: 1

Drop me a note at kputty@jaccard.us

-ave

--
...or maybe not.
Re:kerberos+ssh+putty by ave19 · 2003-06-30 03:52 · Score: 1

If you tried this earlier and it didn't work, try it again. I botched something, but it's working now. :)

Sorry!

-ave

--
...or maybe not.

Re:ssh and telnet, sftp and ftp by Endareth · 2003-06-30 02:18 · Score: 3, Insightful

I think telnet and ftp should be disabled across the world with very limited exceptions. All UNIX and Linux distros should have cleartext protocols disabled by default.

I would agree 100% with this, some *NIX flavours do this already, notable NetBSD and OpenBSD, and I suspect FreeBSD does also, though TBH that's guessing. With SSH available there really is no need that I can think of off hand (I'm sure someone can think up a counter argument) for telnet to still exist, and the only reason for plain ftp to still exist is because all those fully featured ftp clients (download managers, resumers, etc) are implemented with plain ftp instead of sftp. If they are well enough written however, it shouldn't take much effort to re-write these to use sftp instead. While Kerberos is a definate improvement, the difference between telnet and SSH is far huger than the difference between SSH without Kerberos and SSH with Kerberos.

--
Disclaimer: The above comment was made while under the influence of too much coding and not enough sleep.

AFS token forwarding for SSHV2? by dpilot · 2003-06-30 02:25 · Score: 2, Interesting

Does this mean we might get afs token forwarding for SSHV2? (I actually *read* the article, and couldn't glean that out of it.) Currently it appears to be possible to get afs token forwarding, but only for SSHV1. Proper token forwarding would enable ssh deployment in an afs shop.

Or with Kerberos authentication does token forwarding no longer matter, because it's not needed?

--
The living have better things to do than to continue hating the dead.

Anything to get K5 in the openssh core ... by jlrobins_uncc · 2003-06-30 02:29 · Score: 1

Maintaining installations of K5-ticket-passing OpenSSH at a university level (i.e. multiple client / server platforms) is just that much harder when having to match the exact openssh codebase to the exact K5 patchsuite. Being able to ultimately say to all university subunits that want to play ball (and esp. students / faculty and their home boxen) "just cook ossh v3.2x with '--withk5'" would be ever so nice.

Re:ssh and telnet - POP3 by drasfr · 2003-06-30 02:33 · Score: 4, Informative

Well, Pop3 can be fairly secure, pop3 over ssl.

I have my own SMTP & pop3 server, and I have compiled my POP3 daemon with ssl support, and I use outlook to connect, securely on pop3, at least no cleartext password exchange there.
Althought it doesn't change anything in the man-in-the-middle problem.
One problem only, as the SSL certificate has been signed by myself, when outlook reconnect to the server first time it is run, it says the certificate is unknown.

Advantage? by quantum+bit · 2003-06-30 02:33 · Score: 2, Interesting

So exactly what advantage does this have over

rlogin -x $HOSTNAME

? I'm talking about the Kerberized rlogin, of course (possibly known as krlogin to some of you linux users). The -x means to force encryption of the entire session.

Re:Advantage? by ave19 · 2003-06-30 04:23 · Score: 1

You can tunnel through ssh, including X for secure remote displaying. Our users favorite feature. :)

-ave

--
...or maybe not.
Re:Advantage? by Anonymous Coward · 2003-06-30 05:05 · Score: 0

Better security. A more functional program. The ability to, e.g. `ssh -t vi foo' and have it work because you've told it to allocate a tty even though you've given it a command.

Re:FaggotBSD by Anonymous Coward · 2003-06-30 02:34 · Score: 0

well that puts the ports software into a whole new light, doesn't it?

Re:Which is worse? by Anonymous Coward · 2003-06-30 02:38 · Score: 0

So its Gentoo users for you then? Or just Slashdot in general?

Re:Time for Linux to catch up? by ave19 · 2003-06-30 02:45 · Score: 2, Informative

kerberos authentication via gssapi in openssh was available in linux before it was available in windows. i know, cause i did some of the work.

--
...or maybe not.

Globus Grid Support too! by Zach+Garner · 2003-06-30 02:48 · Score: 2, Informative

OpenSSH has also been modified to support the Grid Security Infrastructure (GSI) used by Globus.

Isn't this old? by Tony+Hoyle · 2003-06-30 02:49 · Score: 2, Informative

The ssh-krb5 package has been in debian for, well, years... it works OK .. ironically I'm ditching kerberos soon because it's a lot of hassle, since the token keeps expiring at precisely the wrong moment just as I want to do something, plus it's difficult to switch users since you can only have one ticket at a time - PKI with forwarding is a lot easier.

There is already a patch by voicebox · 2003-06-30 02:49 · Score: 5, Informative

I am unable to get to the article (slashdotted) but there is an already existing GSSAPI patch for OpenSSH here: patch.

Kerberos + Windows AD by Anonymous Coward · 2003-06-30 03:02 · Score: 1, Interesting

Personally I would LOVE to see OpenSSH with Kerberos support, but to be honest I'm sure a lot you guys have Windows desktops (or at least a lot of your users do) like me. What I would like to see is a Windows SSH client that supports the Kerberos TGT that Windows gets for you when you sign into an AD domain and actually works. The one from Reflection doesn't seem to work with OpenSSH+kerberos patch.

Re:Kerberos + Windows AD by lkaos · 2003-06-30 09:48 · Score: 1

Ah, well, that assumes that Active Directory Kerberos is interoperable with the kerberos specifications (which it isn't). Not to mention the fact that Windows likes to not use gss-api and prefers to instead use gss-spnego (which allows them to negotiate down to ntlmssp the minute the network even hiccups slightly).

See, the thing most people don't realize about AD, is that while it sort of supports Kerberos, the minute something goes even slightly wrong (some UDP packets get lost, a time skew's detected, misconfigured DNS, etc.) it falls back to NTLMSSP authentication without saying anything to the user.

In fact, the only way to know if you're using Kerberos at all is if you bust out ethereal and take a look. The funnier thing is the client caching. I've seen Windows clients fail on a Kerberos negotiation and just never try to negotiate Kerberos again.

And we won't even start talking about realm name canonicalization...

--
int func(int a);
func((b += 3, b));

The previous flamefest over this.. by Tuck · 2003-06-30 03:08 · Score: 4, Informative

.. is two doors down on the left.

--
$ find /pub -beer "James Squire Amber Ale" -drink

Re:The previous flamefest over this.. by Anonymous Coward · 2003-06-30 06:41 · Score: 1, Interesting
And has there been any attempt by anyone to either
1. Audit the GSSAPI patch and GSSAPI libraries?
2. Split the one large patch into managable, incremental changes?
If not, then Theo's objections still apply, and this whole thing is just more pissing and moaning that "we have a patch and those bastard developers are ignoring us."
Re:The previous flamefest over this.. by smooge · 2003-07-01 05:03 · Score: 1

There have been audits of the code, but I am not sure any of the auditors have been blessed by the OpenSSH developers so it doesnt mean much.

I can understand their reluctance, but meeting people half way is needed.

--
-- SJS smooge at smoogespace dot com

it's been there for a while by uslinux.net · 2003-06-30 03:09 · Score: 4, Informative

Kerberos authentication has been in openssh for a while, IIRC. What openssh lacks is kerberos ticket passing. Authentication works by validating your kerberos ticket against a KDC, or validating your password against the KDC. #2 has been there. I believe #1 has as well. Ticket passing allows your ticket to be forwarded to the next server, so you can *again* login in to another system. If you don't pass tickets, you need to kinit on each system before you can ssh.

And BTW, kerberos 5 sysadmins can disable non-encrypted services, so rsh/rlogin/telnet/ftp/etc can mandate encryption or fail the connections.

Re:it's been there for a while by Anonymous Coward · 2003-06-30 05:02 · Score: 1, Informative

The article is not about the lack of Kerberos support in OpenSSH, but rather the lack of reasonable Kerberos support. OpenSSH will forward tickets and all that, but the problem is that it uses Kerberos improperly and doesn't derive all of the benefits that one should (such as protection from MITM attacks, etc.)
Re:it's been there for a while by Anonymous Coward · 2003-06-30 15:15 · Score: 0

you have no idea what you're talking about.
ticket passing has been there forever.
The problem at-hand is different.
Re:it's been there for a while by smooge · 2003-07-01 04:57 · Score: 1

There has been ticket passing for SSH version 1 only. The problem is with SSH version 2. There are 2 ways of doing KRB (Heimdal/MIT/etc) with sshv2 currently.

The first way is using a rather 'quick but broken' method that ssh.com used. This method cleans up the major problem in sshv1 krb passing (which was sending a TGT before you were verified), but does not do any sort of verification of the server to the client or much vice versa. This was implemented into the CVS of SSH.com last month or so.

The second way is using the GSSAPI patches that Simon Wilkinson(sp) has developed. It does a large amount of the proposed IETF standard with only a few 'odd' bits not completed. However, it is a large patch that Openssh doesnt want to look at because they dont trust large outside code patches. They would like it broken into smaller parts.. and then they might look at it.

In the end, a lot of large universities, government installations, and major corporations are using kerberos in their systems. Getting the GSSAPI patch would be useful for me.. since I wouldnt have to patch it by hand every release :).

--
-- SJS smooge at smoogespace dot com

what's wrong with by Anonymous Coward · 2003-06-30 03:12 · Score: 0

...kerberized rlogin/rcp ?

next step by scrytch · 2003-06-30 03:45 · Score: 2, Informative

Now all they have to do is make Kerberos as easy to install as openssh. Last time I had to deal with kerberos, it was like removing my own spleen. And it never even worked well when I used it -- like most other MIT standards, it was a pig and had an archaeic interface. And the expiration mechanism still sucks.

--
I've finally had it: until slashdot gets article moderation, I am not coming back.

Re:next step by Anonymous Coward · 2003-06-30 14:07 · Score: 0

Leave it to Apple. Panther server features and integrated MIT KDC. No hassel no fuss... it just works.

Cussed out in Klingon by sdjunky · 2003-06-30 03:49 · Score: 3, Funny

"draft-ietf-secsh-gsskeyex"

Yeah! Well, your mother!

Ahh, yes.. draft-ietf-secsh-gsskeyex.. by RubberChainsaw · 2003-06-30 03:55 · Score: 2, Funny

..implementing draft-ietf-secsh-gsskeyex in addition to ..

Ahh yes. draft-ietf-secsh-gsskeyex.
Encryption so secure you need a key just to decipher the name!

:)

--
I welcome our new 99% overlords.

Man-in-the-middle by smallpaul · 2003-06-30 04:24 · Score: 2, Insightful

I often hear about man-in-the-middle attacks in theory but I've heard of one in practice. Can someone point me to some documentation about an incident where data was compromised by a MITM?

Re:Man-in-the-middle by Anonymous Coward · 2003-06-30 08:05 · Score: 1

How about this story.

The Confusion by batkins · 2003-06-30 04:25 · Score: 1

... he says that they would like to reduce user confusion..

and yet he mentions draft-ietf-secsh-gsskeyex...

Re:ssh and telnet, sftp and ftp by autechre · 2003-06-30 04:32 · Score: 2, Interesting

I know that telnet is still necessary in some settings due to legacy accounting systems (the particular one I have in mind is by HP, IIRC) that simply don't have a replacement. It can also be used to remotely configure some printers and routers, which shouldn't be accessible (via login) from the outside anyway.

The telnet client can also be used as a diagnostic tool, though netcat is better.

--
WMBC freeform/independent online radio.

Big win for government by morrison · 2003-06-30 05:52 · Score: 2, Interesting

This is great news for government sites/labs where Kerberos with pre-hardware authentication (SecureID) is standard or even mandated. As it is, many sites have to remove the existing ssh installation, only to install a custom Kerberized version of ssh.

(e.g. http://kirby.hpcmp.hpc.mil/)

Having Kerberos in the default install should ease one of the many headache's government sysadmins have to endure.

--
Cheers!
Sean

Yes SCO now owns Kerberos by Anonymous Coward · 2003-06-30 05:56 · Score: 2, Funny

Since Kerberos was clearly developed with intent to run on the Unix platform, it is therefore a "derivative work" of Unix, and hence automatically becomes the Intellectual Property of SCO. You can be certain SCO is now *very* interested in the matter.

GSSAPI works already by Eric+Seppanen · 2003-06-30 05:59 · Score: 1

GSSAPI patches for openssh are here. The openssh maintainers aren't real impressed with the GSSAPI spec, and aren't terribly enthusiastic about supporting it, so there's some resistance to merging it.

--
314-15-9265

Pardon? by Ed+Avis · 2003-06-30 05:59 · Score: 1

draft-ietf-secsh-gsskeyex

Am I the only reader who did a double-take of that phrase?

--
-- Ed Avis ed@membled.com

openssh and kerberos by joe_bruin · 2003-06-30 06:22 · Score: 1

seems like the story submitter jumped the gun a bit. from http://www.openbsd.org/plus.html

Add kerberos-over-ssh2 support to ssh(1).

though, reading some openbsd mailing lists, i get the following:

the openssh maintainers would like to have full kerberos support in openssh. however, the mit kerberos code is full of bugs and poorly maintained. the openbsd and openssh developers are sick of dealing with it, and are trying to minimize use of kerberos in the system.
kerberos 4 has been pulled out of openssh and openbsd for the above reasons.

Support OpenSSH development... by Anonymous Coward · 2003-06-30 07:22 · Score: 1, Interesting

Support the OpenSSH developers by getting a 3.3 CD $40 or for Europe EUR 45

There is a new Tshirt: 3 .3 Tshirt $20 or for Europe EUR 20

The new 3.3 poster is very nice too, get it for $10 US or EUR 14 in Europe

Support OpenSSH, have a look at this new Tshirt OpenSSH 2 $20 or for Europe EUR 20

thank you.

Re:Binary-only restrictions by linefeed0 · 2003-06-30 07:52 · Score: 2, Informative

I'm not sure about other methods, but if you use Wilkinson's GSSAPI patch with credentials delegation enabled, krb5 TGTs will be forwarded when the user authenticates with krb5/gssapi.

The problem is that the current version of OpenSSH does an aklog with krb4, which may or may not work without additional patching (i.e. changing the aklog code to use krb5) depending on how your sshd handles the krb libs.

Broader Kerberos adaption. by noselasd · 2003-06-30 08:40 · Score: 1

Why isn't kerberos used more(on Linux, not counting MS AD here) ? It's great for offices and similar, especially the single sign-on "feature".
Would be very nice if the desktops(KDE/Gnome) had wider support for kerberos.. e.g. (GUI/Nautilus/Konqueror) ftp client with kerberos support and similar to.. After all, why provide username/password every damn time I have to access a resource within the "domain" I'm already logged on to ?
People.. use kerberos... demand kerberos support..

Time to retire Kerberos? by Anonymous Coward · 2003-06-30 09:41 · Score: 0

After all, public-key cryptography has been around for decades.

a typo by Anonymous Coward · 2003-06-30 11:30 · Score: 0

The article supposed to be:
"draft-ietf-secsh-goatsex"

GNU lsh support for GSS by Anonymous Coward · 2003-06-30 14:18 · Score: 0

There are recent patches for a free ssh implementation at http://josefsson.org/gss/gss-lsh.html that implement this, if you don't like OpenSSH.

A use for telnet by Stephen+Samuel · 2003-06-30 14:29 · Score: 1

I think telnet and ftp should be disabled across the world with very limited exceptions.

I use the telnet client to test connectability to various ports...
telnet somehost 25
is a nice way to make sure that the SMTP server is running.

Other than that, I agree that telnet servers should be disabled by default (RH8 and up no longer install it by default). If I have to login to a machine with telnet, the first things I do on it are install SSH and ask permission to change passwords.

FTP servers are OK if they are only used for anonymous FTP. Enabling FTP for anything else is just asking to be hacked.

About the only thing I've used RSH for in the last few years is to show Solaris students just how insecure it is (ethereal is such a nice tool).

--
Free Software: Like love, it grows best when given away.

Re:ssh and telnet - POP3 by Directrix1 · 2003-07-02 04:42 · Score: 1

The problem with protecting a generic connection with SSL is that the password is actually passed over the connection. This means if the SSL is ever comprimised it would be fairly simple to crack the password. Use of Strong Authentication mechanisms such as SRP eliminates this problem.

--
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF

Re:ssh and telnet - POP3 by Directrix1 · 2003-07-02 04:44 · Score: 1

Of course there is an SRP on SASL authentication mechanism so SMTP can use it with fairly few extensions.

--
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF

there are rumors... by BigBadDude · 2003-07-02 09:35 · Score: 1

about a brand new 0day in the OpenSSH krb5 code.

(SSH team did a minor cleanup on the SSH code and introduced some vulnerbility somehow).

now, go figure!

Re:ssh and telnet, sftp and ftp by Anonymous Coward · 2003-07-08 01:14 · Score: 0

I know that telnet is still necessary in some settings due to legacy accounting systems (the particular one I have in mind is by HP, IIRC)that simply don't have a replacement.

What is it running, MPE? HP-UX runs SSH just fine, in fact you can download an official build of OpenSSH from HP's ITRC web site.
Even a machine incapable of running SSH binaries can be routed through a cheap box that encapsulates the telnets in SSH sessions. It's a trivial hack...
Telnet clients are excellent diagnostic tools, agreed. But there aren't any good reasons to run a telnet server... the most popular reasons (lack of vision and inordinate greed) are not good reasons.

No rewrites required by Anonymous Coward · 2003-07-08 02:12 · Score: 0

Spend ten minutes getting your keys straightened out, then create symbol links to the OpenSSH binaries under the names rlogin and rsh.

No scripts need to be rewritten, all function remains intact. "Functionality" isn't a word, BTW.

122 comments