3 ms·

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

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

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