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

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

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

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.

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