7 ms·

Why!?!? Why do people do this!? If I want to ssh, I'll use ssh. I do not want or need a "web UI" in or for my ssh client. Is it because I'm getting old? Do I

Why!?!? Why do people do this!? If I want to ssh, I'll use ssh. I do not want or need a "web UI" in or for my ssh client. Is it because I'm getting old? Do I not understand why these darn kids do what they do? Or has my 51 years on this planet taught me that the KISS principle reigns supreme and that "those who don't learn from history, are doomed to repeat it"? Is it, in fact, just me who is mildly abhorred by this? Grimacing like Clint Eastwood from Gran Torino?

atonse 6y ago
You’re not the customer. Any organization that has sufficiently large has a need to know who is accessing what, and when. Tools like this help manage all that when you could have hundreds of logins a day.
- scarygliders 6y ago
  Pardon my 51yo brain, but I seem to remember that every ssh login is logged? Yes, auth.log if my memory serves.
  - mcpherrinm 6y ago
    auth.log is way primitive compared to what teleport has. It logs the actual session data, and if "enhanced" recording is enabled, it uses BPF tracing to record all processes executions and files that were opened. fwiw, the web ui is optional. Nobody's taking away your ssh client.
  - kohtatsu 6y ago
    https://gravitational.com/teleport/how-it-works/audit-logging-for-ssh-and-kubernetes/ https://gravitational.com/teleport/how-it-works/audit-loggin... Their audit log can include a lot more in a more structured format, including wire activity and even std{in,out,err}.
  - benarent 6y ago
    This can only get you so far. We invested a lot time into getting more from system access event using eBPF to take n unstructured SSH session and outputs a stream of structured events. https://gravitational.com/blog/enhanced-session-recording/ https://gravitational.com/blog/enhanced-session-recording/
    - kohtatsu 6y ago
      I was (naturally) skeptical at first as well, but this looks great. I saw on another page that audit logs are sent off server, presumably append-only, but can Teleport pause execution until after log replication is verified? For plain logs this would be straightforward, but for enhanced logging I suppose it'd be a matter of deciding when to pause execution, e.g. after downloading a file.
t0astbread 6y ago
If anyone ever asks me what HN is I'll send them this comment
- scarygliders 6y ago
  Is that good or bad? Asking for a friend. Friend also would like less ambiguity on that comment ;)
  - t0astbread 6y ago
    Oh, It's just a joke (with some meta-ness maybe). I was referring to how HN often likes to cling to some "classics" (like SSH in this case) and how a lot of HNers seem to be against any "web" thing by default. I don't mean to criticize (or make any statement about it at all), it's just opinions after all. I just wanted to tease a little bit with how this comment includes a lot of HN-isms :P
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.'
yellowapple 6y ago
I'm a bit more than half your age and I have the exact same questions. Most of Teleport's features seem to be things that e.g. sudo/doas, PAM, etc. have already solved, just with a prettier interface. And don't get me wrong, some of those features do look interesting (like the full replay logs of an SSH session), but most of them reek of "if it ain't broke we're gonna fix it anyway".
- deleted 6y ago
  [deleted]
prox 6y ago
Why do you want Windows when you have DOS? ;)
AtHeartEngineer 6y ago
Just my opinion, our dev/admin tools need to be a little friendlier. There are too many people that are turned off from learning Linux, programming, or anything deeper than using an app, because there can be so many headaches. There will also people that dive deep into the kernel, but Ive wasted a lot of my time over the years doing something someone else could have done if there was just a web portal, GUI, or hell even decent documentation. We need more people that are computer literate, and making the learning curve a little friendlier helps with that. It's not like there's a petition to get rid of SSH.
twakefield 6y ago
Dislaimer: I work at the company that makes Teleport. Just to clarify, this blog post was about the updates in this release which include a lot of UI changes (particularly in the Web UI). However, Teleport works with whatever UI you would typically use SSH with[0]. The WebUI is an additional "feature"; it's not the only user interface. [0] The use of SSO is another feature that does generally require a browser based auth.
russjones 6y ago
Hi scarygliders, That's a good question and valid skepticism. The UI serves two purposes. The first is to manage your cluster. For example, you may want to change a users role (to change what servers they can access) or play back a session recording to see what a user did within a session. You can do all of these things from the CLI, but sometimes you don't want to remember the exact command and flags, that's where the UI comes in. The second is to have access to servers from an environment that either does not have robust SSH support, doesn't allow you to install software, or maybe an environment (temporary) into which you don't want to install software. For example, when the UI was first written Windows did not have great support for SSH certificates, but the UI would allow Windows users to access Teleport clusters. Lastly, the UI is completely optional, in addition even the CLI tool is (almost) optional. Once you've fetched your certificate, you can use your OpenSSH client as normal. In-fact a lot of people use Teleport this way. Disclaimer: I work at Gravitational.
- tzs 6y ago
  Can you get your certificate without using a browser? The description in the "how it works" sections here [1] describes it launching a browser for that step. If it has to use a browser, can it be a non-GUI browser like Lynx or Links? [1] https://gravitational.com/teleport/how-it-works/certificate-based-authentication-ssh-kubernetes/ https://gravitational.com/teleport/how-it-works/certificate-...
  - russjones 6y ago
    You only need a browser if you are using SSO. If you are using local accounts it's all done in the CLI.
gertrunde 6y ago
It seems more like a wrapper around ssh, providing additional authentication, auditing and control mechanisms, to help companies that have to comply with onerous security regulations. CLI usage seem to be - - log in to teleport, creates short lifetime certs & loads into ssh-agent - use ssh as normal
icedchai 6y ago
Basic SSH does not provide much (any, really) guidance for SSH key management. For a large organization, it can be a very real problem. At one company I worked for, they handed out an SSH key for the prod admin login to every developer on their first day. Every user actually got the same key. When someone left, they had to rotate the keys. There was no bastion host, but the SSH port was open to static IP addresses for various offices and homes of employees. (Yes, this was a bad way to do it, of course.)
meredydd 6y ago
Every Teleport thread is stuffed with questions like this, because these articles always do a really bad job of explaining what Teleport is. Now, perhaps this doesn't matter to Gravitational. Perhaps any potential Teleport customer instantly understands what it is, and the confused onlookers are collateral damage. But to me, it looks like the non-employee commenters are doing a better job summarising your product than you are. I strongly suspect this means you're leaving something on the table.
trav4225 6y ago
Hahah, you're not alone. I have these thoughts nearly every single day...
danudey 6y ago
Here's my situation: we need two-factor auth for some sensitive systems, through our own SAML solution (which provides 2FA). Currently, this involves a VPN (even if you're in the office) to an internal firewall, which then provides you access to servers. If you're out of the office, which everyone is right now, it involves a VPN to the office, then connect to your desktop and VPN from there to the internal firewall, and then access those systems. It's a pain. The idea of Teleport means that I can: 1. Have one system that gets me a shell on any of our servers, regardless of what cluster they're in or what firewall they're behind, without having to use jump hosts 2. Provide SAML/2FA authentication to our AD for all servers, not just the ones which are joined to AD 3. Eliminate shared SSH keys, password sharing, "you have to connect to host X before you can connect to host Y", and so on. 4. Enable role-based authentication across all clusters, which I can update dynamically to grant uses access to new sets of systems when and if they need them, enabling the principle of least privilege. 5. Log every session, so that we can provide an audit trail if we ever need one. The web UI is nice because it allows quick access to all of this functionality, but it doesn't replace the command-line, and you can (and should, IMHO) keep using the command-line for most tasks. It does, however, make a much better option than tunnel after tunnel to get through firewalls to access a host to run one command. Personally, I think teleport fantastically solves an issue that we've been banging our heads together trying to work out a good solution to, and it's pretty elegant at that. If it doesn't make sense to you, then either you didn't read about the whole product and just saw "SSH" and "Web UI" and gave up on it immediately, or you're not in an environment where multiple layers of security, at both the application and network level, coupled with a desire for per-user or role-based access controls, create a multifaced SSH access nightmare.

atonse 6y ago

You’re not the customer. Any organization that has sufficiently large has a need to know who is accessing what, and when. Tools like this help manage all that when you could have hundreds of logins a day.

scarygliders 6y ago
Pardon my 51yo brain, but I seem to remember that every ssh login is logged? Yes, auth.log if my memory serves.
- mcpherrinm 6y ago
  auth.log is way primitive compared to what teleport has. It logs the actual session data, and if "enhanced" recording is enabled, it uses BPF tracing to record all processes executions and files that were opened. fwiw, the web ui is optional. Nobody's taking away your ssh client.
- kohtatsu 6y ago
  https://gravitational.com/teleport/how-it-works/audit-logging-for-ssh-and-kubernetes/ https://gravitational.com/teleport/how-it-works/audit-loggin... Their audit log can include a lot more in a more structured format, including wire activity and even std{in,out,err}.
- benarent 6y ago
  This can only get you so far. We invested a lot time into getting more from system access event using eBPF to take n unstructured SSH session and outputs a stream of structured events. https://gravitational.com/blog/enhanced-session-recording/ https://gravitational.com/blog/enhanced-session-recording/
  - kohtatsu 6y ago
    I was (naturally) skeptical at first as well, but this looks great. I saw on another page that audit logs are sent off server, presumably append-only, but can Teleport pause execution until after log replication is verified? For plain logs this would be straightforward, but for enhanced logging I suppose it'd be a matter of deciding when to pause execution, e.g. after downloading a file.

t0astbread 6y ago

If anyone ever asks me what HN is I'll send them this comment

scarygliders 6y ago
Is that good or bad? Asking for a friend. Friend also would like less ambiguity on that comment ;)
- t0astbread 6y ago
  Oh, It's just a joke (with some meta-ness maybe). I was referring to how HN often likes to cling to some "classics" (like SSH in this case) and how a lot of HNers seem to be against any "web" thing by default. I don't mean to criticize (or make any statement about it at all), it's just opinions after all. I just wanted to tease a little bit with how this comment includes a lot of HN-isms :P

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

yellowapple 6y ago

I'm a bit more than half your age and I have the exact same questions. Most of Teleport's features seem to be things that e.g. sudo/doas, PAM, etc. have already solved, just with a prettier interface. And don't get me wrong, some of those features do look interesting (like the full replay logs of an SSH session), but most of them reek of "if it ain't broke we're gonna fix it anyway".

deleted 6y ago
[deleted]

prox 6y ago

Why do you want Windows when you have DOS? ;)

AtHeartEngineer 6y ago

Just my opinion, our dev/admin tools need to be a little friendlier. There are too many people that are turned off from learning Linux, programming, or anything deeper than using an app, because there can be so many headaches. There will also people that dive deep into the kernel, but Ive wasted a lot of my time over the years doing something someone else could have done if there was just a web portal, GUI, or hell even decent documentation. We need more people that are computer literate, and making the learning curve a little friendlier helps with that. It's not like there's a petition to get rid of SSH.

twakefield 6y ago

Dislaimer: I work at the company that makes Teleport. Just to clarify, this blog post was about the updates in this release which include a lot of UI changes (particularly in the Web UI). However, Teleport works with whatever UI you would typically use SSH with[0]. The WebUI is an additional "feature"; it's not the only user interface. [0] The use of SSO is another feature that does generally require a browser based auth.

russjones 6y ago

Hi scarygliders, That's a good question and valid skepticism. The UI serves two purposes. The first is to manage your cluster. For example, you may want to change a users role (to change what servers they can access) or play back a session recording to see what a user did within a session. You can do all of these things from the CLI, but sometimes you don't want to remember the exact command and flags, that's where the UI comes in. The second is to have access to servers from an environment that either does not have robust SSH support, doesn't allow you to install software, or maybe an environment (temporary) into which you don't want to install software. For example, when the UI was first written Windows did not have great support for SSH certificates, but the UI would allow Windows users to access Teleport clusters. Lastly, the UI is completely optional, in addition even the CLI tool is (almost) optional. Once you've fetched your certificate, you can use your OpenSSH client as normal. In-fact a lot of people use Teleport this way. Disclaimer: I work at Gravitational.

tzs 6y ago
Can you get your certificate without using a browser? The description in the "how it works" sections here [1] describes it launching a browser for that step. If it has to use a browser, can it be a non-GUI browser like Lynx or Links? [1] https://gravitational.com/teleport/how-it-works/certificate-based-authentication-ssh-kubernetes/ https://gravitational.com/teleport/how-it-works/certificate-...
- russjones 6y ago
  You only need a browser if you are using SSO. If you are using local accounts it's all done in the CLI.

gertrunde 6y ago

It seems more like a wrapper around ssh, providing additional authentication, auditing and control mechanisms, to help companies that have to comply with onerous security regulations. CLI usage seem to be - - log in to teleport, creates short lifetime certs & loads into ssh-agent - use ssh as normal

icedchai 6y ago

Basic SSH does not provide much (any, really) guidance for SSH key management. For a large organization, it can be a very real problem. At one company I worked for, they handed out an SSH key for the prod admin login to every developer on their first day. Every user actually got the same key. When someone left, they had to rotate the keys. There was no bastion host, but the SSH port was open to static IP addresses for various offices and homes of employees. (Yes, this was a bad way to do it, of course.)

meredydd 6y ago

Every Teleport thread is stuffed with questions like this, because these articles always do a really bad job of explaining what Teleport is. Now, perhaps this doesn't matter to Gravitational. Perhaps any potential Teleport customer instantly understands what it is, and the confused onlookers are collateral damage. But to me, it looks like the non-employee commenters are doing a better job summarising your product than you are. I strongly suspect this means you're leaving something on the table.

trav4225 6y ago

Hahah, you're not alone. I have these thoughts nearly every single day...

danudey 6y ago

Here's my situation: we need two-factor auth for some sensitive systems, through our own SAML solution (which provides 2FA). Currently, this involves a VPN (even if you're in the office) to an internal firewall, which then provides you access to servers. If you're out of the office, which everyone is right now, it involves a VPN to the office, then connect to your desktop and VPN from there to the internal firewall, and then access those systems. It's a pain. The idea of Teleport means that I can: 1. Have one system that gets me a shell on any of our servers, regardless of what cluster they're in or what firewall they're behind, without having to use jump hosts 2. Provide SAML/2FA authentication to our AD for all servers, not just the ones which are joined to AD 3. Eliminate shared SSH keys, password sharing, "you have to connect to host X before you can connect to host Y", and so on. 4. Enable role-based authentication across all clusters, which I can update dynamically to grant uses access to new sets of systems when and if they need them, enabling the principle of least privilege. 5. Log every session, so that we can provide an audit trail if we ever need one. The web UI is nice because it allows quick access to all of this functionality, but it doesn't replace the command-line, and you can (and should, IMHO) keep using the command-line for most tasks. It does, however, make a much better option than tunnel after tunnel to get through firewalls to access a host to run one command. Personally, I think teleport fantastically solves an issue that we've been banging our heads together trying to work out a good solution to, and it's pretty elegant at that. If it doesn't make sense to you, then either you didn't read about the whole product and just saw "SSH" and "Web UI" and gave up on it immediately, or you're not in an environment where multiple layers of security, at both the application and network level, coupled with a desire for per-user or role-based access controls, create a multifaced SSH access nightmare.