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