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