12 ms·

Seems like this mainly notes changes in this release. https://gravitational.com/teleport https://gravitational.com/teleport is the landing page with more featu

Seems like this mainly notes changes in this release. https://gravitational.com/teleport 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.

stinkytaco 6y ago
> 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.
- mcpherrinm 6y ago
  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.
  - jon-wood 6y ago
    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.
- acdha 6y ago
  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.
lucb1e 6y ago
> 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)?
- cronos 6y ago
  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.
birdyrooster 6y ago
OpenSSH can already do all of these things that you listed.
- cronos 6y ago
  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.
  - number6 6y ago
    Its not a ton of work, most works out of the box and requires just a command line argument
    - cronos 6y ago
      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.
      - number6 6y ago
        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
- mcpherrinm 6y ago
  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.

stinkytaco 6y ago

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

mcpherrinm 6y ago
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.
- jon-wood 6y ago
  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.
acdha 6y ago
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.

lucb1e 6y ago

> 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)?

cronos 6y ago
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.

birdyrooster 6y ago

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

cronos 6y ago
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.
- number6 6y ago
  Its not a ton of work, most works out of the box and requires just a command line argument
  - cronos 6y ago
    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.
    - number6 6y ago
      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
mcpherrinm 6y ago
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.