
Teleport – Modern SSH server for clusters and teams - NickBusey
https://github.com/gravitational/teleport
======
tssva
There have been several comments regarding authentication but what I see as
the glaring issue is the lack of authorization. Without some sort of RBAC
implemented within Teleport and/or integration with external authorization
solutions the use cases for Teleport are going to be limited to very simple
scenarios. The suggestion mentioned within a couple of github issues of using
os logins as roles is a non-starter in a large number of environments due to
security and audit considerations.

I understand that trusted clusters were originally intended as a means to
allow Teleport to work through restrictive firewalls but the same type of
environments which are going to necessitate the use of trusted clusters are
also likely to require more restrictions regarding which users are allowed to
access the cluster from a trusted cluster. The current solution of specifying
individual allowed users is too limited and doesn't scale.

Gravity, which Teleport is ripped from, is a system to support SaaS providers
in deploying and managing onsite implementations within enterprise networks.
Maybe these issues are addressed at a different level within Gravity but if
not I would be hesitant to allow a SaaS provider to deploy within my network
using Gravity.

~~~
old-gregg
tssva, great points. Gravity is basically Kubernetes-on-Teleport, and our
distribution of k8s has additional security measures built-in, where Teleport
(in a library form) is acting more or less on a lowest "root" level which the
infrastructure owner can optionally turn on/off for pieces of their
infrastructure, we'll be gradually publishing more documentation on Gravity
soon, but you're right: RBAC lives one level higher.

------
qwertyuiop924
It's interesting, but I don't think I'd take it over openssh just yet. I'm not
at the scale where most of the features become relevant, and frankly, I don't
trust it as much as I trust openssh, a piece of software that's been in active
development for almost 17 years, has an excellent security track record, and a
development team well known for its care for security and its response to
security issues.

And in a piece of vital security infrastructure, trust is everything.

~~~
draugadrotten
> "Teleport has completed a security audit from a nationally recognized
> technology security company. So we are comfortable with the use of Teleport
> from a security perspective."

It would be interesting to read more details about this audit. This blurb is
pretty much "Trust us" with more letters.

~~~
twakefield
Unfortunately, our current agreement with the security company we hired
prevents us from sharing the details unless under NDA. We may revisit those
terms so that we can publish it now that Teleport is garnering more interest.

Edit: tried to add more clarification to address jtchang's question.

~~~
jtchang
Why is this? Doesn't it make sense to publish which company did the audit? I
mean for financial companies like KPMG they definitely do it.

~~~
sethhochberg
I'd guess it is something like "pay us $XX for an audit for your information;
pay us $XXXX to tell other people we audited you"

~~~
developer2
It's exactly this. A private audit is generally cheap. The truth with these is
that the audit really doesn't mean anything - you will often find such audits
performing such a superficial sweep of the software that even glaring problems
may not be found.

Publicly releasing an audit puts the auditor's reputation on the line. As
such, the audit will always be performed very seriously, digging into the code
and scrutinizing every possible angle - at a level usually not even remotely
done for a private audit.

All said: a private audit means squat all.

------
NickBusey
This project was posted here 6 months ago, but has since evolved quite a bit.
Version 1.1.0 was recently released, so I personally wanted to hear HN's
thoughts on this more stable version of the project. (I am not affiliated.)

~~~
sciurus
Link to previous discussion:
[https://news.ycombinator.com/item?id=11355976](https://news.ycombinator.com/item?id=11355976)

------
moondev
Why is ssh even needed on distributed clusters? Shouldn't provisioning the
cluster be automated and the nodes be immutable by design? I can only imagine
what a nightmare a huge fleet of special sniwflake machines woukd be to
manage. Cattle not pets

~~~
vasco
This is a bit naive. If you've ran a production system with any decent traffic
and never needed to SSH into machines, congrats. I haven't and I don't know
anyone who has. You might need to go in for anything from auditing to
troubleshooting, even if it's rare.

PS: How is your automated provisioning system reaching your cluster if not by
SSH?

~~~
colemickens
>PS: How is your automated provisioning system reaching your cluster if not by
SSH?

Not sure about moondev, but Terraform + Cloud-init + Container Orchestrator
means that I basically never need to SSH into my nodes, except in extreme/rare
circumstances.

~~~
vacri
> _except in extreme /rare circumstances._

So you do need ssh after all?

~~~
colemickens
I said "I basically never need to". Not that I never need to. But yeah, I
basically never, ever need to. Short of needing to take a coredump or docker
shits the bed, I don't really ever need to log into my nodes.

I guess that's an offensive thing to point out judging by my score...

~~~
johnbellone
So you need SSH.

~~~
colemickens
Are you _kidding me_?

> _I said "I basically never need to". Not that I never need to. But yeah, I
> basically never, ever need to_

It is interesting to imagine why this innocuous comment has ruffled so many
feathers.

~~~
colemickens
Boy, I sure hope I'm helping someone really sad feel better about themselves.
Downvote away, it's not going to change a damn thing.

------
colemickens
So Teleport always records the SSH session? Doesn't that get expensive at
times? Sometimes I stream logs over SSH or use `watch` on a fast interval.
It's enough that tmux and ssh take a non-trivial amount of CPU, even just on
the receiving end. I just wonder if that proxy recording becomes a bottleneck.

~~~
old-gregg
Teleport is actually a Golang library, and that's how it's used internally at
Gravitational, where session recording can be turned on or off [1] based on a
use case.

The pre-built teleport daemon as you see in `tool` directory does not have a
config switch for turning recording off yet, we should add it.

[1]
[https://github.com/gravitational/teleport/blob/master/lib/se...](https://github.com/gravitational/teleport/blob/master/lib/service/cfg.go#L267)

------
sandstrom
Something (vaguely) similar can be achieved using Vault and an ssh-helper[1].

It enables one time passwords and password issuing can itself be tied to
2-factor, etc.

[1] [https://github.com/hashicorp/vault-ssh-
helper](https://github.com/hashicorp/vault-ssh-helper)

~~~
INTPenis
Do you know anything about recording ssh sessions too perhaps? That was one of
the more interesting points of this software in the OP.

I would like to see a proxying authentication layer for both ssh and rdp to
manage accountability and access centrally.

------
nixgeek
No support for "plugins" as far as authentication, or to elaborate a bit, how
do you go about running the 'auth' component in multiple VPC and have some
degree of sync? Perhaps a use case for an underlying LDAP directory, or ..?

~~~
alexk
We support OIDC connectors, so you can plug in LDAP using
[https://github.com/coreos/dex](https://github.com/coreos/dex) as one of the
providers, or simply roll a new OIDC provider customized to your needs.

~~~
Sanddancer
Why OIDC? Why not use something much more standardized like PAM?

~~~
alexk
Mostly because we wanted to support Google auth out of the box and OIDC is a
good way to get this + give options for pluggable auth to everyone else.

------
vacri
Pet hate: projects that use existing common(-ish) words. 'ssh' is instantly
recognisable. 'Teleport'... meh. Make your own word, be unique.

------
ChoHag
Why do these fucking quasi-products never actually say what the fuck they DO?
"<this> replaces sshd, possibly the most critical piece of software your
server runs, with a magic black box".

There's nothing in the rather meagre list of suggestions at the top of the
readme that can't be done already and 0 detail on how they intend to achieve
it and why their dubious methods require wholesale replacement of your, did I
say it's critical?, ssh daemon.

SSH is definitely not a tool I'll be replacing any time soon with the latest
fly-by-night product from CADT BikeShedders Inc.

~~~
INTPenis
There was one very interesting feature, recording of sessions.

There is an increasing demand in large organisations to manage server sessions
better.

That is to have accountability and manage access centrally.

So far I've only reviewed one solution, Cyberark, they promised to manage all
our server sessions centrally with 2FA, recording ssh and rdp, and more. But
in the end we weren't motivated enough to pick them.

I haven't seen any open source offering to do this.

Of course this product would be outside of your normal SSH server, as an
additional proxying layer and not a replacement for ssh. Just saying that
there was one very interesting point in that repo, I wouldn't replace OpenSSH
ligthly either.

------
HeadlessChild
This just feels like a lazy solution.

~~~
NickBusey
I'd be interested in hearing about non-lazy alternatives other than manual key
shuffling.

~~~
jessaustin
Actually certificates can be used with openssh as well:

[https://news.ycombinator.com/item?id=12518902](https://news.ycombinator.com/item?id=12518902)

I'm not sure this isn't too "lazy" for some tastes, however.

