Aside from shivering at the mention of "Web UI", I don't quite get what this does that SSH doesn't. The landing page is super useless, and the blog post doesn't exactly explain why a VPN service (since it "removes the need for VPN", it's a VPN) is a replacement for ssh.
Like, "glorious portal radiating encrypted beams into all of your clouds and smart devices", umm yeah okay.
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.
> Reverse-tunnel mode, where devices without public IPs (or a vpn) can connect to your bastion server.
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.
Just extra pieces to manage. With a VPN, now you need to start worrying about firewall rules (do you isolate clients? What internal resources do they get access to?), IP assignment (now you need to run a DHCP server, or handle static IP allocations). What subnets do you use for your VPN, and what happens if they conflict with the network at some of your locations? Or maybe buy a VPN appliance to do that for you. Then you need to handle VPN authentication...
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.
These complications are particularly relevant if you're managing a fleet of devices on networks you don't control, such as on-prem versions of SaaS systems, or consumer IoT devices. In that situation you definitely don't want the device to be sitting around with a back door into your network, and subnet conflicts are often impossible to resolve.
VPNs are a huge security risk: you’re installing a lot of complex code and configuration into a secure context listening on an open network port, and you almost certainly open more traffic than just SSH so an attacker who compromises a VPN client can attack those services, too.
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.
> devices without public IPs (or a vpn) can connect to your bastion server
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)?
The NATted device dials out to the bastion (a.k.a. proxy) and maintains a persistent tunnel.
The proxy then sends all the connections to this device inside that tunnel.
Yes, but it's rarely how companies use OpenSSH because it takes a ton of work to set up.
Teleport gives you all this functionality by default out of the box. So it's not inventing anything new, just provides better UX.
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.
Yeah, you are right about this. Just thought about a personal setup, but getting it all up and running in enterprise scape will be more work than just a few flags
None of these features are supported by openssh without external code.
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.
Why is this "modern replacement for OpenSSH" when people use ssh specifically because it's so simple and doesn't have webui? There have been many ssh webuis in the last decade, none of them were "replacements" of ssh, just wrappers for people scared of terminals. What exactly does it do that 20 other ssh wrappers (or even portainer for containers) don't?
It's really slick, and provides a client/server architecture with a bunch of extra security on-top. It generates 1:1 certificates between the api layer and the clients, using a full auth service.
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.
There's little more than marketing bull on that site. Web user interface? No need for VPN? They precisely miss the whole reason for ssh. It's as if they have no clue what ssh is or does.
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?
auth.log is way primitive compared to what teleport has.
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.
This can only get you so far. We invested a lot time into getting more from system access event using eBPF to take n unstructured SSH session and outputs a stream of structured events. https://gravitational.com/blog/enhanced-session-recording/
I was (naturally) skeptical at first as well, but this looks great.
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.
Oh, It's just a joke (with some meta-ness maybe). I was referring to how HN often likes to cling to some "classics" (like SSH in this case) and how a lot of HNers seem to be against any "web" thing by default.
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
Teleport solves SSH'ing in to a ton of machines on private networks from outside the private network. 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 the short pitch.
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:
> Teleport solves SSH'ing in to a ton of machines on private networks from outside the private network.
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.
> SSH with a bastion (jump) system and ControlMaster/ControlPersist settings is generally how SSH handles this.
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.'
> rather than 'oh, that server... you need the SSH key, I think it's this one
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.
This is already a solved problem and ssh provides the solution. If you have a fleet of machines, you better be using config management to manage them. And you should be pushing out the public key that's on the device you use for remote access to all the machines using that config management. There isnt "a keypair for every node".
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.
Setting all of that infrastructure up and subsequently maintaining it involves a considerable amount of time and knowledge. Some people just want a solution that's easy to deploy and that handles all of the management for you.
> 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.
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.
Auth to the jump/bastion host and then have key(s) on that, or tunnel back the internal auth requests over to your desktop via ssh-agent(1) forwarding:
There are a few differences between an OpenSSH jump host and Teleport:
- you have to actively manage authorized_keys for every person using openssh; Teleport manages a PKI and can be backed by your existing SSO
- it hard to restrict any given user to a subset of hosts (e.g. only allow select few to access prod database); Teleport has RBAC
- hosts with Teleport also get SSH certificates, so you don't need to trust-on-first-use (which everyone has been conditioned to ignore)
I'm a bit more than half your age and I have the exact same questions. Most of Teleport's features seem to be things that e.g. sudo/doas, PAM, etc. have already solved, just with a prettier interface. And don't get me wrong, some of those features do look interesting (like the full replay logs of an SSH session), but most of them reek of "if it ain't broke we're gonna fix it anyway".
Just my opinion, our dev/admin tools need to be a little friendlier. There are too many people that are turned off from learning Linux, programming, or anything deeper than using an app, because there can be so many headaches. There will also people that dive deep into the kernel, but Ive wasted a lot of my time over the years doing something someone else could have done if there was just a web portal, GUI, or hell even decent documentation.
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.
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.
Can you get your certificate without using a browser? The description in the "how it works" sections here [1] describes it launching a browser for that step.
If it has to use a browser, can it be a non-GUI browser like Lynx or Links?
It seems more like a wrapper around ssh, providing additional authentication, auditing and control mechanisms, to help companies that have to comply with onerous security regulations.
CLI usage seem to be -
- log in to teleport, creates short lifetime certs & loads into ssh-agent
- use ssh as normal
Basic SSH does not provide much (any, really) guidance for SSH key management. For a large organization, it can be a very real problem.
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.
Every Teleport thread is stuffed with questions like this, because these articles always do a really bad job of explaining what Teleport is.
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.
Here's my situation: we need two-factor auth for some sensitive systems, through our own SAML solution (which provides 2FA). Currently, this involves a VPN (even if you're in the office) to an internal firewall, which then provides you access to servers. If you're out of the office, which everyone is right now, it involves a VPN to the office, then connect to your desktop and VPN from there to the internal firewall, and then access those systems. It's a pain.
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.
For all the people complaining about the web UI, it’s optional, Teleport also has a CLI and if you really want to you can use OpenSSH as the client. Teleport’s benefit isn’t really the web UI, it’s the fact it manages a certificate authority for authentication, hooked into the same authentication used for other things, and full audit logging of what people are doing via SSH.
Hey HN! I Director of Product for Teleport, and that does include CLI and YAML experience. This is a bumper release, with a bunch of fixes https://github.com/gravitational/teleport/releases/tag/v4.3.... . Even for OpenSSH users using Teleport in Recording Proxy mode.
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.
Hey, tell your marketing people that they did a really poor job. Taking a stab at everyone's beloved ssh? Calling your offering a replacement for it?! Daring! No wonder you're getting all that hate here on HN
"modern replacement for X" looks to me like about the worst title one could choose for advertising a product.
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.
For those who are looking for a simple ssh bastion but have no need for all of Teleport features, there is also https://github.com/moul/sshportal. Administration and registration is done through ssh, with no need for a special client or a web ui, and the whole thing is just a single binary which stores its configuration in sqlite (by default).
65 comments
[ 2.7 ms ] story [ 143 ms ] threadLike, "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.
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.
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)?
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.
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.
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.
It's marketing speak geared towards managers who have no idea what SSH is or does.
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?
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.
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
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):
Auth to the jump/bastion host and then have key(s) on that, or tunnel back the internal auth requests over to your desktop via ssh-agent(1) forwarding:* 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.
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.
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-...
CLI usage seem to be - - log in to teleport, creates short lifetime certs & loads into ssh-agent - use ssh as normal
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.)
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.
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.
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/
but beware of SCP https://gravitational.com/blog/scp-familiar-simple-insecure-...
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.