This looks like a really cool project. I'm excited to see it develop.
How would authentication work with configuration management? I see that new nodes are authenticated with a one-time token generated from the auth server, but that seems like it could be tricky to implement in a dynamic cluster (like an AWS auto scaling group).
Thanks! One time provisioning token helps node to connect and get a host certificate signed by the right CA key. All further authentication happens using OpenSSH host certificates. This also means that new nodes can simply join the cluster as long as they have the right certs, not using provisioning tokens at all. This allows you to have an external authority bootstrapping new nodes without talking to existing auth server.
Hello everyone, the Teleport team is here to answer any questions.
Internally we use Teleport as a library to connect multiple clusters into a structured system of doing ops with solid identity management, but we figured it deserves to be its own tool, especially because so many larger companies in the Valley have built something similar internally.
> 1) How does session archiving work with non-line-oriented applications? (e.g. top and its brethren)
We capture and replay the whole stream, so playback works well with top/mc/emacs/vim etc
> 2) Does it ever capture passwords (or any other non-echoed characters) by accident?
If you accidentally type in password in your active session that will be visible, session capture will record it, yes. We plan on encrypting everything just in case at rest though:
This solves a problem we were looking at my last job: recording and replaying sessions. Identity management and bastion setup are solved problems, but it is nice to have an all in one package.
Of course, this raises a few security questions:
1. Do I have to run this as a server on every host I intend to ssh into? Or can it use existing installations of openssh for that?
2. Is this re-inventing any authentication mechanism? If yes, how robust is it and how thoroughly has it been tested? (I'm guess not much right now, since this isn't production ready yet, but the question will remain for a while.)
3. Do I have to use a different client? Or are existing ssh clients fully sufficient? The article does mention compatibility with OpenSSH, but does not detail. It also mentions using HTTPS as a transport instead of SSH, which is concerning in the case of compatibility.
Dynamic tags are implemented as external processes that run on schedule and their stdout becomes a value of a tag.
So if you have, say, a CLI command which spits out AWS labels of a node, hook it up and they'll appear as Teleport tags.
One thing of note: though they do say it's "fully compatible with OpenSSH", it is not compatible with ed25519 keyed SSH, as Golang SSH does not support it.
Otherwise looks like a cleverly designed system. Being able to use a standard terminal emulator to connect would be nice though.
Can teleport run the same command on a group of servers, then collect the output and prefix it with the name of the server it came from? For example we could run a "df" on a batch of servers and see if they have enough free space, all in one line.
How is this any different from the very common LDAP + Kerberos + RADIUS solution that is usually deployed in large companies. This seems like it's re-inventing things that already exist and have been used successfully for years. It seems to me that a tool that makes deployment of LDAP/RADIUS/Kerberos easier would be more practical.
Congrats to the Gravitational team on teleport! LDAP/RADIUS/etc are often useful only for internal employee access. Teleport brings (among other things) a new level of flexibility for secure remote management (say, by a vendor perhaps), so I don't see it as a replacement for the traditional auth protocols.
In terms of making LDAP/RADIUS easier, well, we're a YC company that does just that! Foxpass (S15) https://www.foxpass.com/.
Hey, that's a good question and a valid concern. Teleport's auth server is designed to be extendable and we plan to add support for a variety of existing authentication and authorization protocols in the upcoming releases based on community feedback and requests.
We use existing 2FA HOTP based access control in the first release mostly to get a good quick start experience and we understand that big organizations will plug in Teleport into their existing auth infrastructure.
It would be nice if it made backups of small files uploaded/deleted/modified through SFTP. That, along with the session history, would allow recovery from accidental deletion or overwrite (time machine for small files edited by hand).
we don't support sftp (yet), but we emulate SCP, so we can do the backup and upload for sure. We had this use-case in mind when building SCP feature set. Where would you like to push files (e.g. S3?)
This name ("teleport") is really close to this other piece of software, which looks to be very much in the same space: https://github.com/petar/goteleport
Thanks! I don't think teleport will work with mosh as mosh uses custom UDP-based protocol that we'd have to support, however if we'll get lots of feature requests for it, we'll definitely consider implementing it!
So, they implemented Active Directory/RADIUS, a terminal proxy, screen, and a web gui? Does this not seem to anyone else like a weird mix of features for one tool?
Perhaps the mix into one tool is what makes it novel?
I'll be honest, my first knee-jerk, HN conditioned, reaction to this was similar to yours, but I've been trying to temper my first reactions, especially when they are negative.
Not the most central thing, but something that put me off a little was that they offer a command to filter the listings...had these people never heard of grep? The playback of terminal sessions is cool though, although I swear I've seen someone else do that somewhere...
noobermin: thanks for looking at Teleport with an open mind. Good point on grep: our people have heard of it. :)
The reason `tsh` takes label filters as an argument to all of its sub-commands (not just "ls") is to perform actions only on machines that fit the criteria, maybe you want to "tsh scp" a file to all "distro=debian" nodes, or you want to "tsh ssh role=postgres_master" not knowing which node is the master at this time.
The background story behind these little "niceties" is this: internally we've always wanted to have a bit of Ansible-like slice&dice magic in interactive mode for raw SSH, so we've built it and sharing it: perhaps someone else would find it useful.
How would authentication work with configuration management? I see that new nodes are authenticated with a one-time token generated from the auth server, but that seems like it could be tricky to implement in a dynamic cluster (like an AWS auto scaling group).