9 ms·

Teleport – Modern SSH server for clusters and teams

218 points by NickBusey 10y ago

NickBusey 10y ago
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.)
- jdc0589 10y ago
  ditto. I evaluated it back then and though it could be fantastic at some point, it was just missing to many small things. Admittedly these were things we could have solved ourselves, but it seemed like they would be added to the core product at some point, so I opted to hold off adoption for a while.
- sciurus 10y ago
  Link to previous discussion: https://news.ycombinator.com/item?id=11355976 https://news.ycombinator.com/item?id=11355976
- e12e 10y ago
  Agreed, this looks like a pretty good evolution on plain (open)sshd now. Still does seem to sit at a somewhat uncomfortable place between being an augmented ssh that's easier to manage, and a completely separate auth/authz solution (in some ways a little like installing saltstack or puppet etc, which essentially grants a daemon arbitrary/root privileges and ability to do configuration changes on the "outside" of the unix user/group-framework). Things like: "Also, people can join your session via terminal assuming they have Teleport installed and running. They just have to run: > tsh --proxy=teleport.example.com join 7645d523-60cb-436d-b732-99c5df14b7c4 !!! tip "NOTE": For this to work, both of you must have proper user mappings allowing you access db under the same OS user." (my emphasis) I don't really see this as a big problem -- but I'd prefer a tool that basically magically took care of generating short-lived user-certificates for ssh (and it does indeed look like teleport does this now, in a rather nice and well-documented[1] manner) -- but I'd like to keep the user-database in some sane place, like ldap, especially as long as teleport use is still subject to pam/unix user/group in addition to internal user/authorizations. I also don't particularly like having to use password login (even with two-factor) - but I suppose one could either a) wrap the web bit in ssl client auth (but now you need two CAs, one for ssh certs and one for x509) - or better (for my use-case) create a daemon that works as a ssh daemon and can be configured for normal ssh access (set of known keys, limit access to internal network/whitelisted IPs) -- that can be used for initial auth. Or maybe just replace the current web auth with a specialized ssh daemon that uses standard ssh+two-factor login (something like[2]). All that said, I really like the look of this project in its current state, and I'll strongly consider using it over setting up a "bare" (open)ssh CA system. [1] https://github.com/gravitational/teleport/blob/master/docs/architecture.md https://github.com/gravitational/teleport/blob/master/docs/a... [2] Note, I'm not a great fan of the google auth pam module, but have successfully tested using OAUTH -- and it works well both with pre-generated passwords or google auth or similar TOTP-apps. An added benefit is that it can also be enabled for sudo/su elevation, rather than just relying on password for that. See eg: https://jonarcher.info/2015/07/hardening-ssh-with-otp-for-2-factor-authentication/ https://jonarcher.info/2015/07/hardening-ssh-with-otp-for-2-... and/or: http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-authenticator.shtml http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google... Incidentally my fight with OATH/pam/various python tools to generate qr-codes allowed me to overcome the seemingly insurmountable challenge of pairing the standard Google Authenticator App with the Star Wars: Old Republic TOTP secret in order to enable 2-factor login. It appears that makes me a member of a rather select club of swtor-players....
qwertyuiop924 10y ago
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 10y ago
  > "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.
  - qwertyuiop924 10y ago
    Indeed. That's why I'm not entirely trusting of it yet.
  - twakefield 10y ago
    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 10y ago
      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 10y ago
        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"
HeadlessChild 10y ago
This just feels like a lazy solution.
- NickBusey 10y ago
  I'd be interested in hearing about non-lazy alternatives other than manual key shuffling.
  - alfalfasprout 10y ago
    Kerberos, RADIUS, you name it.
  - jessaustin 10y ago
    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.
nixgeek 10y ago
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 10y ago
  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 10y ago
    Why OIDC? Why not use something much more standardized like PAM?
    - alexk 10y ago
      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.
moondev 10y ago
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
- deleted 10y ago
  [deleted]
- vasco 10y ago
  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 10y ago
    >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 10y ago
      > except in extreme/rare circumstances. So you do need ssh after all?
      - colemickens 10y ago
        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...
        10y ago
colemickens 10y ago
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 10y ago
  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/service/cfg.go#L267 https://github.com/gravitational/teleport/blob/master/lib/se...
sandstrom 10y ago
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 10y ago
  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.
deleted 10y ago
[deleted]
tssva 10y ago
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 10y ago
  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.
vacri 10y ago
Pet hate: projects that use existing common(-ish) words. 'ssh' is instantly recognisable. 'Teleport'... meh. Make your own word, be unique.
ChoHag 10y ago
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 10y ago
  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.

218 points by NickBusey 10y ago

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

jdc0589 10y ago
ditto. I evaluated it back then and though it could be fantastic at some point, it was just missing to many small things. Admittedly these were things we could have solved ourselves, but it seemed like they would be added to the core product at some point, so I opted to hold off adoption for a while.
sciurus 10y ago
Link to previous discussion: https://news.ycombinator.com/item?id=11355976 https://news.ycombinator.com/item?id=11355976
e12e 10y ago
Agreed, this looks like a pretty good evolution on plain (open)sshd now. Still does seem to sit at a somewhat uncomfortable place between being an augmented ssh that's easier to manage, and a completely separate auth/authz solution (in some ways a little like installing saltstack or puppet etc, which essentially grants a daemon arbitrary/root privileges and ability to do configuration changes on the "outside" of the unix user/group-framework). Things like: "Also, people can join your session via terminal assuming they have Teleport installed and running. They just have to run: > tsh --proxy=teleport.example.com join 7645d523-60cb-436d-b732-99c5df14b7c4 !!! tip "NOTE": For this to work, both of you must have proper user mappings allowing you access db under the same OS user." (my emphasis) I don't really see this as a big problem -- but I'd prefer a tool that basically magically took care of generating short-lived user-certificates for ssh (and it does indeed look like teleport does this now, in a rather nice and well-documented[1] manner) -- but I'd like to keep the user-database in some sane place, like ldap, especially as long as teleport use is still subject to pam/unix user/group in addition to internal user/authorizations. I also don't particularly like having to use password login (even with two-factor) - but I suppose one could either a) wrap the web bit in ssl client auth (but now you need two CAs, one for ssh certs and one for x509) - or better (for my use-case) create a daemon that works as a ssh daemon and can be configured for normal ssh access (set of known keys, limit access to internal network/whitelisted IPs) -- that can be used for initial auth. Or maybe just replace the current web auth with a specialized ssh daemon that uses standard ssh+two-factor login (something like[2]). All that said, I really like the look of this project in its current state, and I'll strongly consider using it over setting up a "bare" (open)ssh CA system. [1] https://github.com/gravitational/teleport/blob/master/docs/architecture.md https://github.com/gravitational/teleport/blob/master/docs/a... [2] Note, I'm not a great fan of the google auth pam module, but have successfully tested using OAUTH -- and it works well both with pre-generated passwords or google auth or similar TOTP-apps. An added benefit is that it can also be enabled for sudo/su elevation, rather than just relying on password for that. See eg: https://jonarcher.info/2015/07/hardening-ssh-with-otp-for-2-factor-authentication/ https://jonarcher.info/2015/07/hardening-ssh-with-otp-for-2-... and/or: http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-authenticator.shtml http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google... Incidentally my fight with OATH/pam/various python tools to generate qr-codes allowed me to overcome the seemingly insurmountable challenge of pairing the standard Google Authenticator App with the Star Wars: Old Republic TOTP secret in order to enable 2-factor login. It appears that makes me a member of a rather select club of swtor-players....

qwertyuiop924 10y ago

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 10y ago
> "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.
- qwertyuiop924 10y ago
  Indeed. That's why I'm not entirely trusting of it yet.
- twakefield 10y ago
  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 10y ago
    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 10y ago
      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"

HeadlessChild 10y ago

This just feels like a lazy solution.

NickBusey 10y ago
I'd be interested in hearing about non-lazy alternatives other than manual key shuffling.
- alfalfasprout 10y ago
  Kerberos, RADIUS, you name it.
- jessaustin 10y ago
  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.

nixgeek 10y ago

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 10y ago
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 10y ago
  Why OIDC? Why not use something much more standardized like PAM?
  - alexk 10y ago
    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.

moondev 10y ago

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

deleted 10y ago
[deleted]
vasco 10y ago
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 10y ago
  >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 10y ago
    > except in extreme/rare circumstances. So you do need ssh after all?
    - colemickens 10y ago
      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...
      - 10y ago

colemickens 10y ago

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 10y ago
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/service/cfg.go#L267 https://github.com/gravitational/teleport/blob/master/lib/se...

sandstrom 10y ago

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 10y ago
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.

deleted 10y ago

[deleted]

tssva 10y ago

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 10y ago
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.

vacri 10y ago

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

ChoHag 10y ago

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 10y ago
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.