Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KeyBox: A better way to SSH

sshkeybox.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: KeyBox: A better way to SSH

#51

Post by kgilpin »

subway wrote: post #30
pmoriarty wrote: post #8

Earlier quoted context omitted.

"These days it's super easy to use SSH keys with LDAP" Are there any articles that go in to detail on exactly how to do this?

FreeIPA has provided this for a while: https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_... More recently the AuthorizedKeysCommand patch has made it's way into Ubuntu's sshd, similarly allowing sshd to call script that looks up a user's authorized keys from LDAP.

The IPA in FreeIPA stands for "Identity, Policy, and Audit". Yet on the Roadmap page (http://www.freeipa.org/page/Roadmap), enjoy this statement:

"The audit component of the project will remain deferred until further notice. You can see the reasoning in the About page."

Therefore, for enterprise purposes, I can't see why anyone would take FreeIPA seriously.

Re: KeyBox: A better way to SSH

#52

Post by csirac2 »

devonkim wrote: post #24
jpgvm wrote: post #6

Single point of compromise. :( I wish people would just stop with these things. The appropriate way to be able to manage many users is called LDAP, it's been LDAP for decades and it's unlikely to change. These days it's super easy to use SSH keys with LDAP, still using the standard openssh-lpk schema but now not requiring any patches to OpenSSH itself, just need to use the AuthorizedKeysCommand and an appropriate hel…

Some people use Kerberos instead of LDAP but there's far less people that have actually rolled out a Kerberos implementation that's not related to Active Directory than LDAP. Either way, LDAP and/or Kerberos are just re-inventing wheels that have not a whole lot of value in re-inventing / "innovating" partly because disparate identity and authorization management systems are an immense pain to deal with scaling beyon…

The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an account on?

Re: KeyBox: A better way to SSH

#53

Post by devonkim »

csirac2 wrote: post #52
devonkim wrote: post #24

Earlier quoted context omitted.

Some people use Kerberos instead of LDAP but there's far less people that have actually rolled out a Kerberos implementation that's not related to Active Directory than LDAP. Either way, LDAP and/or Kerberos are just re-inventing wheels that have not a whole lot of value in re-inventing / "innovating" partly because disparate identity and authorization management systems are an immense pain to deal with scaling beyon…

The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an account on?

I'm not quite sure what you mean with this concern but Kerberos is really flexible and a Kerberos realm could act a lot more like roles than by domains (which is the typical correlation). Most enterprise networks I've worked with are extremely fragmented from decades of competing business units rolling their own thing and so the default in most enterprise networks is already quite restricted in many respects, and that is ironically a bit of a help for security by reducing the impact crater of an intrusion. Also, we have plenty of different accounts used by one physical user all the time, so nothing keeps administrators from requiring different accounts for different roles on top of realms. I don't necessarily mean that you need to create user1.support and user1.dev in the same domain but Kerberos solves a lot of problems that ssh alone just doesn't answer, which is a big reason why I reach for that after I have an ok ssh setup.

Nothing says you can't put resources in multiple Kerberos realms either. Then you can establish a digraph of trust chains across Kerberos realms to transfer tickets across realms based upon some business rules.

There's many reasons that Active Directory (LDAP + Kerberos + some magical bits of quirks and features) is the gold standard for large corporations and the reason is not "nobody got fired for buying Microsoft."

Re: KeyBox: A better way to SSH

#54

Post by skavanagh »

kgilpin wrote: post #50
jpgvm wrote: post #34

Earlier quoted context omitted.

Corp networks are almost never a shining example of network design or security. Most people that work doing that sort of thing are the checkbox type and will block SSH (and other protocols) because it gives them some sense of warm and fuzzies. The reality is this is stupid and just leads to people working around the problem. Take for example corkscrew, which allows you to tunnel SSH over HTTPS proxies, without losing…

For example, at the US Air Force, the following policies are in place: * Use of SSH is discouraged, because the traffic is encrypted, and the Air Force wants to be able to read all the traffic in and out of boxes. * If you do get a waiver for SSH, the system admins require you to hand over all your SSH private keys, so that they can decrypt the traffic, read it, and re-encrypt it.

Yup! Make administration less confidential, but try and keep it as secure as possible. Inside attacks are a big problem in the financial industry too. I like the idea of controlling it through a hardened web-app, but may need a little help getting there.

Re: KeyBox: A better way to SSH

#55

Post by skavanagh »

VieElm wrote: post #12

It's a neat system, but I also like that it's written in Java. Given all the new things coming out with Go, Scala, clojure node.js and what not it's inspiring to see people still also building things on top of the Java platform with just straight up Java. I haven't used struts but it doesn't look that crazy when looking at this code. It looks pretty sane.

Awesome, appreciate that!!!

Re: KeyBox: A better way to SSH

#56

Post by jpgvm »

skavanagh wrote: post #54
kgilpin wrote: post #50

Earlier quoted context omitted.

For example, at the US Air Force, the following policies are in place: * Use of SSH is discouraged, because the traffic is encrypted, and the Air Force wants to be able to read all the traffic in and out of boxes. * If you do get a waiver for SSH, the system admins require you to hand over all your SSH private keys, so that they can decrypt the traffic, read it, and re-encrypt it.

Yup! Make administration less confidential, but try and keep it as secure as possible. Inside attacks are a big problem in the financial industry too. I like the idea of controlling it through a hardened web-app, but may need a little help getting there.

Why? You can protect against insider threat by auditing the target system itself and streaming said audit logs to write only media.

Building a single point of compromise has no advantages over this and many disadvantages beyond just security.

Re: KeyBox: A better way to SSH

#57

Post by skavanagh »

jpgvm wrote: post #56
skavanagh wrote: post #54

Earlier quoted context omitted.

Yup! Make administration less confidential, but try and keep it as secure as possible. Inside attacks are a big problem in the financial industry too. I like the idea of controlling it through a hardened web-app, but may need a little help getting there.

Why? You can protect against insider threat by auditing the target system itself and streaming said audit logs to write only media. Building a single point of compromise has no advantages over this and many disadvantages beyond just security.

Auditing can be a deterrent to an attack, but won't necessarily protect you against it. It's a good way of letting you know what has happened after the fact.

Think if you had a DB with financials (credit cards and such) in a isolated DMZ with SSH inbound/outbound blocked

How can you dump the DB and copy it off if all the traffic was "proxied" through this?? It's not like you can scp a tarball anywhere.

You can't forward ports and expose the DB outside of the DMZ either.

And it doesn't take admins to setup auditing or disable forwarding, you have physically disabled it.

I got to say I don't understand the single point of compromise thing. A single point of failure is a bad, but the less points of compromise the better. You identify your critical systems, you protect your critical systems. Spreading things out doesn't make you more secure.

Here is an old white paper on some things to think about SSH in your infrastructure.

http://www.sans.org/reading-room/whitepapers/vpns/security-i...

Your right in saying this is an unproven application!

Post reply on HN