5 ms·

If you are in the terminal and don't have access to a browser?

by tjoff 4y ago

hnlmorg 4y ago
Not the OP but if anyone doesn’t have access to a browser in my org then I can safely say they’re not accessing from a company laptop and thus should be denied access.
- hamburglar 4y ago
  Not sure why you'd get downvoted for this comment. This is likely very applicable for many orgs that have operator workstation standards -- they're some kind of window/osx/linux box with a defined/enforced endpoint protection measures, and they all have a browser. Any device I can imagine ssh'ing from that doesn't have a browser is definitely out of policy.
  - 0xedd 4y ago
    because both of you narrow visioned the scenario to what you do daily. it is a common use case to ssh from a jump server, use ssh based CLI tools and debugging. the issue stems from windows users who are coupled to GUIs. the behavior pattern increases IT and DevOps costs unnecessarily. an alternative example: our org solves the issue with TOTP, required every 8 hours for any operation; from ssh/git CLI based actions (prompted at the terminal) to SSO integrations. decoupling security from unrelated programs. simple and elegant.
    - Macha 4y ago
      The -J parameter to say will transparently use a jump server and doesn't require the ssh key being on the third party server. I can't speak for tooling on step-ca but my employers in house tooling works similarly and loads the short lived signed cert into your ssh-agent so once you do the initial auth you can do whatever SSH things.
    - hamburglar 4y ago
      As pointed out, whether or not you go through a jump host isn’t relevant. We all go through jump hosts as well. Besides, neither me nor GP is saying this needs to be a universal pattern. We are saying that it’s a viable pattern for a lot of orgs.
    - hnlmorg 4y ago
      There are better ways to access remote servers than using a jump box. If you’ve gone to the lengths to tie SSH auth into a web based SSO then you should have at least set up you’re other infra to manage network access already (since that’s a far bigger security concern). Plus, as others have said, you can jump through SSH sessions with on the client ssh command (ie without having to manually invoke ssh on the jump box).
  - moondev 4y ago
    Checkmate! https://github.com/fathyb/carbonyl https://github.com/fathyb/carbonyl
- gpderetta 4y ago
  You really never ssh from one remote server to another?
  - rfoo 4y ago
    Not GP, but: I do, however when I do this I make sure the certificate is signed with permit-agent-forwarding and demand people just forward their ssh agent on their laptops. This also discourages people from leaving their SSH private key on a server just for ssh-ing into other servers in CRON instead of using a proper machine-key.
    - the8472 4y ago
      Agent forwarding has its own security issues, you're exposing all your credentials to the remote. It's better to configure jump hosts in your local ssh config.
      - rfoo 4y ago
        There's SSH agent restriction now. [1] https://www.openssh.com/agent-restrict.html https://www.openssh.com/agent-restrict.html
  - rhco 4y ago
    The CA CLI tool we use supports a few auth methods, including a passphrase-like one. It likely could be set up with TOTP or a hardware token also. We only use OAuth because it's convenient and secure-enough for our use case.
  - michaelt 4y ago
    In general for systems like this, you can open the browser link from a different host. For example, if I've SSHed from my laptop to Host A to Host B to Host C then need to authenticate a CLI program I'm running on Host C, the program can show a link in the terminal which I can open on my laptop.
    - gpderetta 4y ago
filleokus 4y ago
With e.g Azure's CLI az you can specify a flag something like "--use-device-code" which shows a copy-pastable URL that you then can just visit in the browser (on a different device even).

If you are in the terminal and don't have access to a browser?

by tjoff 4y ago

If you are in the terminal and don't have access to a browser?

Not the OP but if anyone doesn’t have access to a browser in my org then I can safely say they’re not accessing from a company laptop and thus should be denied access.

hamburglar 4y ago
Not sure why you'd get downvoted for this comment. This is likely very applicable for many orgs that have operator workstation standards -- they're some kind of window/osx/linux box with a defined/enforced endpoint protection measures, and they all have a browser. Any device I can imagine ssh'ing from that doesn't have a browser is definitely out of policy.
- 0xedd 4y ago
  because both of you narrow visioned the scenario to what you do daily. it is a common use case to ssh from a jump server, use ssh based CLI tools and debugging. the issue stems from windows users who are coupled to GUIs. the behavior pattern increases IT and DevOps costs unnecessarily. an alternative example: our org solves the issue with TOTP, required every 8 hours for any operation; from ssh/git CLI based actions (prompted at the terminal) to SSO integrations. decoupling security from unrelated programs. simple and elegant.
  - Macha 4y ago
    The -J parameter to say will transparently use a jump server and doesn't require the ssh key being on the third party server. I can't speak for tooling on step-ca but my employers in house tooling works similarly and loads the short lived signed cert into your ssh-agent so once you do the initial auth you can do whatever SSH things.
  - hamburglar 4y ago
    As pointed out, whether or not you go through a jump host isn’t relevant. We all go through jump hosts as well. Besides, neither me nor GP is saying this needs to be a universal pattern. We are saying that it’s a viable pattern for a lot of orgs.
  - hnlmorg 4y ago
    There are better ways to access remote servers than using a jump box. If you’ve gone to the lengths to tie SSH auth into a web based SSO then you should have at least set up you’re other infra to manage network access already (since that’s a far bigger security concern). Plus, as others have said, you can jump through SSH sessions with on the client ssh command (ie without having to manually invoke ssh on the jump box).
- moondev 4y ago
  Checkmate! https://github.com/fathyb/carbonyl https://github.com/fathyb/carbonyl
gpderetta 4y ago
You really never ssh from one remote server to another?
- rfoo 4y ago
  Not GP, but: I do, however when I do this I make sure the certificate is signed with permit-agent-forwarding and demand people just forward their ssh agent on their laptops. This also discourages people from leaving their SSH private key on a server just for ssh-ing into other servers in CRON instead of using a proper machine-key.
  - the8472 4y ago
    Agent forwarding has its own security issues, you're exposing all your credentials to the remote. It's better to configure jump hosts in your local ssh config.
    - rfoo 4y ago
      There's SSH agent restriction now. [1] https://www.openssh.com/agent-restrict.html https://www.openssh.com/agent-restrict.html
- rhco 4y ago
  The CA CLI tool we use supports a few auth methods, including a passphrase-like one. It likely could be set up with TOTP or a hardware token also. We only use OAuth because it's convenient and secure-enough for our use case.
- michaelt 4y ago
  In general for systems like this, you can open the browser link from a different host. For example, if I've SSHed from my laptop to Host A to Host B to Host C then need to authenticate a CLI program I'm running on Host C, the program can show a link in the terminal which I can open on my laptop.
  - gpderetta 4y ago

filleokus 4y ago

With e.g Azure's CLI az you can specify a flag something like "--use-device-code" which shows a copy-pastable URL that you then can just visit in the browser (on a different device even).