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

31–40 of 57 posts

Re: KeyBox: A better way to SSH

#31

Post by cpach »

rdl wrote: post #29

Forcing all traffic through a bastion host (especially for things like logging) can be a good practice -- especially if it's uncommon for users to need to be able to log into machines (e.g. a production network), but where you want to retain access. For something where it's more "lots of users need to connect to lots of boxes regularly", I'd prefer kerberos or LDAP/AD (to manage keys). There's also a good argument ag…

There are solutions in place to combine SSH keys with 2FA. E.g. Duo Security has a solution for that: https://www.duosecurity.com/blog/ssh-keys-that-call-you-back

[Edit: Removed redundant comments.]

Re: KeyBox: A better way to SSH

#32

Post by jpgvm »

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.

More correctly AuthorizedKeysCommand is in mainline OpenSSH, thus every recent release of all major distros have it.

Re: KeyBox: A better way to SSH

#33

Post by jpgvm »

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…

Kerberos is also acceptable, it is however much more complicated than LDAP for the average sysadmin to understand.

You also need to teach your users how to get kerberos tickets and setup keytab etc. Chances are if you are using kerberos you also have LDAP however.

Re: KeyBox: A better way to SSH

#34

Post by jpgvm »

kavanutz wrote: post #21
_cbdev wrote: post #16

Earlier quoted context omitted.

I especially like the absurdity presented in this diagram: http://sshkeybox.com/img/keybox_dia.jpg Not only does it create a single point of failure in the Administration, but the third case illustrates that this is some kind of feature, advertising blocking normal SSH traffic to the server network, instead replacing it with HTTPS traffic. Please don't do this. Just accept SSH and learn to deal with it. If you can't,…

It's definitely not for everyone. Inbound/outbound SSH is usually blocked on corp networks. One of the reasons is you can tunnel/forward ports and expose the internal network. HTTPS takes that away. Plus you can't copy files off the server and the idea is you can audit what is being done. Depends on what the threat is in IMHO.

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 any of it's port forwarding or other juicy features.

If you feel like you really need to embarass them you can ofcourse run something like sshuttle over the top providing automatic VPN routing over this rogue SSH tunnel.

Worse yet they might install KeyBox on their AWS deployment because they don't have SSH outbound, which then promptly gets pwned because it's a relatively unproven Java web application rather than a battle-hardened unix staple (i.e sshd).

Corp networks and infosec departments are a joke.

In terms of auditing all you need to do is make proper use of *nix permission model and then enable sudo input/output logging and control access to sudo via LDAP groups. Send all of your sudo logs to centralized logging system like Splunk/ELK/fluentd/Flume etc.

Re: KeyBox: A better way to SSH

#35

Post by devonkim »

jpgvm wrote: post #34
kavanutz wrote: post #21

Earlier quoted context omitted.

It's definitely not for everyone. Inbound/outbound SSH is usually blocked on corp networks. One of the reasons is you can tunnel/forward ports and expose the internal network. HTTPS takes that away. Plus you can't copy files off the server and the idea is you can audit what is being done. Depends on what the threat is in IMHO.

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…

I'm all for your contempt of corporate network security policies honestly, but I think they're typically trying to stop most users that are not particularly sophisticated and basically assume that anyone with half a brain will get around eventually. That's why audit policies are much more rigorously enforced than network tunneling restrictions, for example.

I regularly defeat most policies if I really have to get work done but the real deterrent, sadly, is for employees to be fearful of getting caught and having to deal with the immense mountain of bullshit paperwork and training that is likely to follow. Completely meaningless paperwork filling is a form of disciplinary action in my opinion.

Re: KeyBox: A better way to SSH

#36

Post by e12e »

rdl wrote: post #29

Forcing all traffic through a bastion host (especially for things like logging) can be a good practice -- especially if it's uncommon for users to need to be able to log into machines (e.g. a production network), but where you want to retain access. For something where it's more "lots of users need to connect to lots of boxes regularly", I'd prefer kerberos or LDAP/AD (to manage keys). There's also a good argument ag…

I'd say ssh keys generally don't have 2fa.

A passphrase doesn't really turn a ssh-key into 2fa. It's still really only "something you have (access to)": the plaintext of the private half of the key. Granted, you can use ssh-keys with tokens -- my recommendation is to use encrypted ssh-keys paired with a recent[1] openssh server that allows stacking OTP on top, for 2fa with the RequiredAuthentication-directive (well, OTP is generally code for: can demonstrate access to OTP secret) -- but at least it is rather easy to store the two on separate devices (say a phone, and on the filesystem of your workstation/laptop). Not really maximum security, but quite a lot better than traditional passwords.

Until you store both the key and the authenticator on your phone, in order to use ssh from your phone. At which point you end up with "rather convoluted 1fa" -- which might still be marginally better than traditional passwords (along with a warm fuzzy feeling of false security :-).

Other than that I've been looking into using openssh certificates with openssh, but it still looks like it's rather complicated -- and for a single-/few-user setup it's questionable if the expiration etc really adds much actual security.

Maybe the best would be to apply some of the kerberos design lessons to openssh with certificates, issuing short-lived certs much like kerberos ticket-granting tickets (so have an easy way to get a user certificate that's valid for 8 hours or so...). Not sure the added complexity would be worth it, though...

[1] https://blog.flameeyes.eu/2013/03/openssh-6-2-adds-support-f...

Re: KeyBox: A better way to SSH

#38

Post by iancarroll »

rdl wrote: post #29

Forcing all traffic through a bastion host (especially for things like logging) can be a good practice -- especially if it's uncommon for users to need to be able to log into machines (e.g. a production network), but where you want to retain access. For something where it's more "lots of users need to connect to lots of boxes regularly", I'd prefer kerberos or LDAP/AD (to manage keys). There's also a good argument ag…

I've loaded SSH keys onto SafeNet tokens before. That's hardware 2FA (you need a password to use the token)

Re: KeyBox: A better way to SSH

#39

Post by ryan-c »

gfodor wrote: post #14

Does anyone know of a web-based ssh solution that has good enough termcaps to allow me to enjoyably use vim + tmux inside of a web browser? Also, it can't use browser extensions (but can use plugins like flash/java/etc.)

https://github.com/macton/hterm

I use the chrome extension version on my chromebook quite heavily, no real complaints.

Re: KeyBox: A better way to SSH

#40

Post by STRML »

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.

This is a great perl script that makes for an easy AuthorizedKeysCommand [1]. SSH with LDAP is definitely an easier way to distribute keys and manage permissions than logging into each box. It's also a single point of failure in a way, but you can at least keep it completely inside a private network, and LDAP is well-known and easy to secure.

1. https://github.com/AndriiGrytsenko/openssh-ldap-publickey

Post reply on HN