Teleport 4.3: Modern Replacement for OpenSSH
gravitational.com
gravitational.com
I deployed it at a previous position and stopped SSH across all hosts entirely, and just used this.
It rotated all it's own certificates every 4 hours, and each SSH connection used a unique certificate.
I never had any issues with it, and I had the web UI straight up exposed to the internet. It enforces TOTP and user management with the OSS stuff is pretty trivial.
It also did something really cool, which is that I had multiple bastions federated together through a single API, instead of having singular multiple bastions. This meant no configuration to access hosts between prod/stage/test, all a single entry point, it was awesome.
I don't use it today in my current position for a number of reasons, but if I were to go back to a smaller company and had the choice, I would deploy it with no hesitation.
Like, "glorious portal radiating encrypted beams into all of your clouds and smart devices", umm yeah okay.
https://gravitational.com/teleport is the landing page with more feature details.
I think a short list of features interesting to me is:
* SSH CA integrated with whatever SSO you have, removing need to distribute SSH authorized_keys files.
* SSH Bastion & Server with audit logging. Record sessions, who did what. Needed for many security-sensitive environments.
* Reverse-tunnel mode, where devices without public IPs (or a vpn) can connect to your bastion server. Useful if you're deploying computers "in the field" that you want remote access to, without needing additional VPN or port forwarding, etc.
How does it punch through NAT? Or does the NATted device connect similarly to using ssh -R 1234:localhost:22 (just like CAs and session recording work with SSH as well, but I guess this project might make it more integrated and user-friendly with a nice GUI)?
This may be a ridiculous question, but what's wrong with a VPN in this scenario? Or even a SOCKS proxy, which is already widely deployed and supported? You say "without needing additional VPN or port forwarding", but I'm curious what advantages it offers over using a VPN.
Lots of that is largely un-needed effort. If you just want to be able to SSH into computers, it's simpler to just have your ssh server connect back.
At small scale, where an ops team can keep track of all the computers individually? yeah, VPN is probably fine, especially if you've already got one. But I think these days, a lot of people are looking at avoiding VPNs outright.
They have advantages, too, but it’s not a simple decision. A reverse tunnel where the server has an agent which opens an outbound connection to receive requests over cuts a bunch of risks out of your environment and it’s less work to operate, too.
You can manually sign certs for users and hosts with ssh-keygen but there's no distribution or automation included with openssh. There's a half dozen SSH CA solutions around for this, but none as polished as what teleport has.
Teleport's session logging is unrivaled by anything you can do with openssh and is one of the key reasons I'm looking to adopt it.
The reverse tunnel mode could be accomplished with autossh to manage a reverse tunnel, but that's also not out of the box.
Maintaining a CA (and dealing with cert rotation) is some work.
Other things are indeed just a flag or config option (like jumphosts). But it takes work for a sysadmin/devops to educate all engineers in the company and make sure everyone uses the correct setup and doesn't end up dropping authorized_keys around random servers.
It's not that difficult technically as it is socially.
In networking (and a bit everywhere in engineering) people seem to associate "modern" with negatives, at least as a first impression; so if the tagline you try to sell your product is only "Modern replacement of X", it likely starts at -1 in the minds of most of your targets.
Why do people do this!?
If I want to ssh, I'll use ssh. I do not want or need a "web UI" in or for my ssh client.
Is it because I'm getting old? Do I not understand why these darn kids do what they do? Or has my 51 years on this planet taught me that the KISS principle reigns supreme and that "those who don't learn from history, are doomed to repeat it"?
Is it, in fact, just me who is mildly abhorred by this? Grimacing like Clint Eastwood from Gran Torino?
That's a good question and valid skepticism. The UI serves two purposes.
The first is to manage your cluster. For example, you may want to change a users role (to change what servers they can access) or play back a session recording to see what a user did within a session. You can do all of these things from the CLI, but sometimes you don't want to remember the exact command and flags, that's where the UI comes in.
The second is to have access to servers from an environment that either does not have robust SSH support, doesn't allow you to install software, or maybe an environment (temporary) into which you don't want to install software. For example, when the UI was first written Windows did not have great support for SSH certificates, but the UI would allow Windows users to access Teleport clusters.
Lastly, the UI is completely optional, in addition even the CLI tool is (almost) optional. Once you've fetched your certificate, you can use your OpenSSH client as normal. In-fact a lot of people use Teleport this way.
Disclaimer: I work at Gravitational.
If it has to use a browser, can it be a non-GUI browser like Lynx or Links?
[1] https://gravitational.com/teleport/how-it-works/certificate-...
You can do the same thing w/ a VPN and a good secret store. But Teleport is just another way of doing it and it has some nice tools around it for folks that want it :shrug:
From ssh(1):
-J destination
Connect to the target host by first making a ssh connection to
the jump host described by destination and then establishing a
TCP forwarding to the ultimate destination from there. Multiple
jump hops may be specified separated by comma characters. This
is a shortcut to specify a ProxyJump configuration directive.
* http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fw...
* https://www.cloudsavvyit.com/25/what-is-ssh-agent-forwarding...
SSH with a bastion (jump) system and ControlMaster/ControlPersist settings is generally how SSH handles this.
> Teleport handles the auth at its entry point, so you don't need a keypair for every node in your cloud. Just one for Teleport.
That's interesting. I'm initially skeptical of how that shifts the security responsibilities based on that description, but don't know enough about it to level any specific criticisms, if any are warranted.
This works if you have a simple network toplogy. If you have multiple layers, like:
1. VPN to office network 2. SSH to office desktop Linux machine 3. VPN to internal secure network segment 3. SSH from office desktop to internal secure host 3. SSH from secure host to another, even more secure, no-network-access host
Then jump hosts are a colossal pain to set up and maintain, since you have to configure a jump to A through B, then to C through A, then to D through C, and you end up with multiple layers of configuration, which you have to configure manually for each host or group of hosts.
> That's interesting. I'm initially skeptical of how that shifts the security responsibilities based on that description, but don't know enough about it to level any specific criticisms, if any are warranted.
In the design that I envision (for our installation), we have one authentication one time, via our SAML provider (which uses 2FA); now the user is authenticated to the system even more securely than regular SSH can provide, and can SSH to any hosts, as any users, which they have been granted access to. All authentication and host access is configured and managed in one place, so we can just focus on 'this person can do these things' rather than 'oh, that server... you need the SSH key, I think it's this one, and you need to connect as I think user X... or maybe user Y... it's a mess but we haven't had time to change everything.'
I really hope that's just a mistake in how you were typing it up and not reality, because if so then whatever organization or people are doing that are using SSH key pairs entirely incorrectly. The whole point of public and private keys is that you never have to share the private key.
You add the public key of the person who needs access's private, individual, not to be shared key to the account in question. There are systems to manage pushing public keys to remote systems and accounts, or someone can write their own in a couple hours in most languages. It's not a complicated process to automate.
> Then jump hosts are a colossal pain to set up and maintain, since you have to configure a jump to A through B, then to C through A, then to D through C, and you end up with multiple layers of configuration, which you have to configure manually for each host or group of hosts.
I'll just say that if you expect some centralized management system to save you from the extra bureaucracy of ill thought out security layering and systems (vpn to a network so you can access a host so you can vpn to another network? Seriously?), I imagine you'll find the outcome leaves a lot to be desired, no matter the promises.
And if you're talking about managing host keys, this is solved with host certificates signed by a local CA, the public key of which you put in your known-hosts file.
This "short pitch" says there's a problem where none exists.
We need more people that are computer literate, and making the learning curve a little friendlier helps with that. It's not like there's a petition to get rid of SSH.
Now, perhaps this doesn't matter to Gravitational. Perhaps any potential Teleport customer instantly understands what it is, and the confused onlookers are collateral damage.
But to me, it looks like the non-employee commenters are doing a better job summarising your product than you are. I strongly suspect this means you're leaving something on the table.
Friend also would like less ambiguity on that comment ;)
I don't mean to criticize (or make any statement about it at all), it's just opinions after all. I just wanted to tease a little bit with how this comment includes a lot of HN-isms :P
The idea of Teleport means that I can:
1. Have one system that gets me a shell on any of our servers, regardless of what cluster they're in or what firewall they're behind, without having to use jump hosts 2. Provide SAML/2FA authentication to our AD for all servers, not just the ones which are joined to AD 3. Eliminate shared SSH keys, password sharing, "you have to connect to host X before you can connect to host Y", and so on. 4. Enable role-based authentication across all clusters, which I can update dynamically to grant uses access to new sets of systems when and if they need them, enabling the principle of least privilege. 5. Log every session, so that we can provide an audit trail if we ever need one.
The web UI is nice because it allows quick access to all of this functionality, but it doesn't replace the command-line, and you can (and should, IMHO) keep using the command-line for most tasks. It does, however, make a much better option than tunnel after tunnel to get through firewalls to access a host to run one command.
Personally, I think teleport fantastically solves an issue that we've been banging our heads together trying to work out a good solution to, and it's pretty elegant at that.
If it doesn't make sense to you, then either you didn't read about the whole product and just saw "SSH" and "Web UI" and gave up on it immediately, or you're not in an environment where multiple layers of security, at both the application and network level, coupled with a desire for per-user or role-based access controls, create a multifaced SSH access nightmare.
CLI usage seem to be - - log in to teleport, creates short lifetime certs & loads into ssh-agent - use ssh as normal
Tools like this help manage all that when you could have hundreds of logins a day.
Yes, auth.log if my memory serves.
I saw on another page that audit logs are sent off server, presumably append-only, but can Teleport pause execution until after log replication is verified?
For plain logs this would be straightforward, but for enhanced logging I suppose it'd be a matter of deciding when to pause execution, e.g. after downloading a file.
It logs the actual session data, and if "enhanced" recording is enabled, it uses BPF tracing to record all processes executions and files that were opened.
fwiw, the web ui is optional. Nobody's taking away your ssh client.
Their audit log can include a lot more in a more structured format, including wire activity and even std{in,out,err}.
Just to clarify, this blog post was about the updates in this release which include a lot of UI changes (particularly in the Web UI).
However, Teleport works with whatever UI you would typically use SSH with[0]. The WebUI is an additional "feature"; it's not the only user interface.
[0] The use of SSO is another feature that does generally require a browser based auth.
At one company I worked for, they handed out an SSH key for the prod admin login to every developer on their first day. Every user actually got the same key. When someone left, they had to rotate the keys. There was no bastion host, but the SSH port was open to static IP addresses for various offices and homes of employees.
(Yes, this was a bad way to do it, of course.)
It's marketing speak geared towards managers who have no idea what SSH is or does.
As always I love some HN comments. While you do need a running proxy. You can use Teleport without ever having to use the UI.
Here to answer any questions.
but there are many good reasons to use the Teleport Library. https://gravitational.com/blog/openssh-vs-teleport/