Hacker News Reader

Comment by lucb1e | Hacker News Reader

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.

View on HN

Seems like this mainly notes changes in this release.

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.

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

OpenSSH can already do all of these things that you listed.

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.

Its not a ton of work, most works out of the box and requires just a command line argument

A "ton" of work may have been an exaggeration.

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.

Reply on news.ycombinator.com