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

21–30 of 57 posts

Re: KeyBox: A better way to SSH

#21

Post by kavanutz »

_cbdev wrote: post #16
perlgeek wrote: post #9

Adding the browser to the mix won't make it much more secure, I fear.

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.

Re: KeyBox: A better way to SSH

#23

Post by gnosek »

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

You might give shellinabox a try.

Re: KeyBox: A better way to SSH

#24

Post by devonkim »

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 beyond a small to medium size company and everyone would rather use what's well known first before they think they're smart enough to roll their own. This is pretty typical with developers versus systems management folks though culturally though I'd gather. It just pisses me off when I have to fix something some smartass thought "simpler = better" meant that he should roll his own thing instead of learning how people do it first and THEN rolling his own.

Re: KeyBox: A better way to SSH

#25

Post by devonkim »

pmoriarty wrote: post #8
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…

"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?

Digital Ocean has a ton of systems management guides aimed at developers first, but they're pretty reasonable for small scale setups and when you have no clue where to start. https://www.digitalocean.com/community/tutorials/how-to-auth...

Re: KeyBox: A better way to SSH

#26

Post by opejn »

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.

You can tunnel through HTTPS too, given a client/server pair that supports HTTP CONNECT. Conversely it's possible to disable the SSH port forwarding function. From the firewall's point of view, they ought to be equally risky.

Re: KeyBox: A better way to SSH

#27

Post by xorcist »

If you have a large enough installation to make use of such a thing you should absolutely not go distributing keys in this homecooked way.

Either you already have an authentication infrastructure in place, such as Kerberos, in which case you should absolutely use that for SSH as well and not roll your own.

If haven't, and your problem concerns mainly SSH, you should absolutely use the PKI mode of OpenSSH unless you have some reason not to. It has existed since 5.3 and works like you would expect, with a central CA and CRL.

Start with a good overwiew such as http://blog.habets.pp.se/2011/07/OpenSSH-certificates (or some other Google hit), then consult the official documentation for a few more details.

Re: KeyBox: A better way to SSH

#28

Post by res0nat0r »

Argorak wrote: post #18
pritambaral wrote: post #2

So, fanterm[1] for the web. [1]: http://www.stearns.org/fanout/README.html

I've also seen clusterssh: http://freecode.com/projects/clusterssh

There are tons of parallel shells out there...each seem to have their good and bad features:

http://www.stearns.org/fanout/README.html

http://sourceforge.net/projects/mussh/

https://code.google.com/p/parallel-ssh/

https://github.com/ndenev/mpssh

https://code.google.com/p/csshx/

http://taktuk.gforge.inria.fr/kanif/

Re: KeyBox: A better way to SSH

#29

Post by rdl »

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 against ssh keys anyway -- they don't have expiration dates, don't necessarily provide 2fa, don't have good secure storage on client devices, etc.

(In the long run I'd probably go with a client-device managed credential, some kind of client-device-specific biometric or other auth through a secure path, and some scheme to ensure users don't authenticate via a tampered client device. It's a hard problem in a mobile/laptop environment.)

Re: KeyBox: A better way to SSH

#30

Post by subway »

pmoriarty wrote: post #8
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…

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

Post reply on HN