4 ms·

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

by dljsjr 6y ago

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:

kbenson 6y ago
> 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.
- danudey 6y ago
  > 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.'
  - kbenson 6y ago
    > 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.
    - deleted 6y ago
      [deleted]
thwarted 6y ago
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.
- webvictim 6y ago
  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.
  - thwarted 6y ago
    You went through all the effort of having a manually configured fleet of machines and the thing that's daunting is solved with this?
throw0101a 6y ago
> 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: * http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fwd http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fw... * https://www.cloudsavvyit.com/25/what-is-ssh-agent-forwarding-and-how-do-you-use-it/ https://www.cloudsavvyit.com/25/what-is-ssh-agent-forwarding...
- cronos 6y ago
  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)

by dljsjr 6y ago

kbenson 6y ago

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

danudey 6y ago
> 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.'
- kbenson 6y ago
  > 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.
  - deleted 6y ago
    [deleted]

thwarted 6y ago

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.

webvictim 6y ago
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.
- thwarted 6y ago
  You went through all the effort of having a manually configured fleet of machines and the thing that's daunting is solved with this?

throw0101a 6y ago

> 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: * http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fwd http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fw... * https://www.cloudsavvyit.com/25/what-is-ssh-agent-forwarding-and-how-do-you-use-it/ https://www.cloudsavvyit.com/25/what-is-ssh-agent-forwarding...

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