Teleport – Simple SSH Login and Access Management | Hacker News Reader

Teleport – Simple SSH Login and Access Management

conjurinc.github.io

13 pointsnikolay12 comments

Open articleView on HN

Maybe worth of changing name ?

SSH for Clusters and Teams http://gravitational.com/teleport/

https://github.com/gravitational/teleport

Previous discussion https://news.ycombinator.com/item?id=11355976

Yeah, but Gravitational's project is a newer one.

not according to github:

gravitational initial commit in 2015/03 conjurinc initial commit on 2015/06.

Source code: https://github.com/conjurinc/teleport

What is the point of this? Shouldn't your configuration management tool be pushing the right accounts to the right servers?

You shouldn't be relying on your config management system for access control -- requiring a config push each node each time you hire, fire, forget a passphrase, or rotate a key is just asking for disaster.

Push your access controls out to a central directory. Personally I'm a fan sssd/ipa for this, but teleport looks like a neat solution too.

You can rely on config management if it pulls from a central service and that central service reports failures and hosts not checking in.

  > requiring a config push each node each time you hire,
  > fire, forget a passphrase, or rotate a key is just asking
  > for disaster.

What's the reason for this paranoia? You have plenty of lead time before a new employee joins, or a key needs to be rotated (and you want to have the keys be valid for an overlapping period anyway). Even forgotten/replacement keys can be pushed out quickly.

I guess it's the fear of a disgruntled ex-employee trashing the systems in the minutes before the config management system removed their key? They could still keep an authenticated session open, but I feel that civil/criminal charges for unauthorized access are more effective protection than technology enforcement.

It's less about paranoia, and more about reducing change operations on hosts. Why should I constantly update each host with information about who can access what resource with which credentials, when I can configure them a single time to delegate access control to a directory service?

Despite the best intentions I've seen quite a few organizations crippled by having a directory service die. I'd much rather have a push based service (like configuration management) where downtime means people can't change their passwords. Having every login fail because a directory service is down seems silly. Not like the mapping of users <-> systems is particularly large, even for the largest organizations.

Do you take the same approach with DNS?

If you have that high of churn within your operational staff, your problem has expanded beyond what any tool can fix. (or in an enterprise environment you should be using something like Centrify anyway)

Reply on news.ycombinator.com