5 ms·

if its ssh why do i need to install/run cloudflared?

LakeAustin 8y ago
(Cloudflare team here) cloudflared proxies the traffic through the Cloudflare network to the service behind Access so that Cloudflare can ensure the request is authenticated first and then issue a token to the client through cloudflared.
- otterley 8y ago
  sshd already has a reasonable authentication protocol (several in fact, including public keys of various kinds) that is already tunneled through an encrypted channel. What additional value does cloudflared provide? It's a bit like saying HTTPS isn't good enough, so let's tunnel HTTPS inside HTTPS -- unless I misunderstand its purpose.
  - zackbloom 8y ago
    It's because the IdPs most organizations use don't have the type of SSH flow you're talking about. For Cloudflare to authenticate you, you first have to go through your Okta, Google Apps, etc login flow which is browser-centric.
    - otterley 8y ago
      I wrote about a sensible way to provision login authentication in some detail here: https://segment.com/blog/ditching-the-shared-user/ https://segment.com/blog/ditching-the-shared-user/
      - ejcx 8y ago
        There are actually quite a few aspects of your blog that I think we will emulate in the near future, with a twist, to solve more similar problems. This problem set was super different though. Adding a public facing SSH interface to our production hosts was a bit of a non-starter and we would have had to hack together auth on top of that (not just for us, but for our customers too). That's a lot of additional surface area and operational burden we didn't want. BTW we should catch up over a beer sometime =]
- throwaway2048 8y ago
  Why not authenticate via ssh keys using the ssh client (such as the openssh -J flag)
- cagenut 8y ago
  thanks for responding, but I confess it didn't clear anything up for me. I don't know what "Access" is or why ssh would require a token.
antoncohen 8y ago
Imagine you have an application like GitHub Enterprise or Phabricator, something that has a web interface and SSH for git access. You might trust SSH, but do you trust the web stack to not have vulnerabilities? I don't know about you, but I don't trust running third party apps, I won't publicly expose them. Instead I put them behind authenticating proxies, like Cloudflare Access[1], Google Identity-Aware Proxy[2], Bitly oauth2_proxy[3], and Buzzfeed SSO[4]. With an authenticating proxy an attacker can't even hit the web application until authenticating, so they can't exploit a vulnerability in the web application. They will have to pop the auth proxy first, which have less surface area, and then pop the web application. Applications that combine HTTP and SSH complicate things because the typical HTTP proxy won't proxy your SSH (git) connections, and the web authentication flow doesn't work with SSH. Cloudflare Access provides the auth proxy, cloudflared does the web authentication flow for a command line app and passes SSH traffic through Cloudflare Access. [1] https://www.cloudflare.com/products/cloudflare-access/ https://www.cloudflare.com/products/cloudflare-access/ [2] https://cloud.google.com/iap/ https://cloud.google.com/iap/ [3] https://github.com/bitly/oauth2_proxy https://github.com/bitly/oauth2_proxy [4] https://github.com/buzzfeed/sso https://github.com/buzzfeed/sso
- otterley 8y ago
  Can you explain why this setup is better than LDAP/Ansible/Chef (to provision user accounts) + ssh keys/CA-generated certificates for ssh authentication? This setup is well known in the art and isn't rife with reported vulnerabilities. The value of using a web flow to authenticate isn't clear to me because you have to provision user accounts on Unix systems anyway to have reasonable accountability.

(Cloudflare team here) cloudflared proxies the traffic through the Cloudflare network to the service behind Access so that Cloudflare can ensure the request is authenticated first and then issue a token to the client through cloudflared.

otterley 8y ago
sshd already has a reasonable authentication protocol (several in fact, including public keys of various kinds) that is already tunneled through an encrypted channel. What additional value does cloudflared provide? It's a bit like saying HTTPS isn't good enough, so let's tunnel HTTPS inside HTTPS -- unless I misunderstand its purpose.
- zackbloom 8y ago
  It's because the IdPs most organizations use don't have the type of SSH flow you're talking about. For Cloudflare to authenticate you, you first have to go through your Okta, Google Apps, etc login flow which is browser-centric.
  - otterley 8y ago
    I wrote about a sensible way to provision login authentication in some detail here: https://segment.com/blog/ditching-the-shared-user/ https://segment.com/blog/ditching-the-shared-user/
    - ejcx 8y ago
      There are actually quite a few aspects of your blog that I think we will emulate in the near future, with a twist, to solve more similar problems. This problem set was super different though. Adding a public facing SSH interface to our production hosts was a bit of a non-starter and we would have had to hack together auth on top of that (not just for us, but for our customers too). That's a lot of additional surface area and operational burden we didn't want. BTW we should catch up over a beer sometime =]
throwaway2048 8y ago
Why not authenticate via ssh keys using the ssh client (such as the openssh -J flag)
cagenut 8y ago
thanks for responding, but I confess it didn't clear anything up for me. I don't know what "Access" is or why ssh would require a token.

antoncohen 8y ago

Imagine you have an application like GitHub Enterprise or Phabricator, something that has a web interface and SSH for git access. You might trust SSH, but do you trust the web stack to not have vulnerabilities? I don't know about you, but I don't trust running third party apps, I won't publicly expose them. Instead I put them behind authenticating proxies, like Cloudflare Access[1], Google Identity-Aware Proxy[2], Bitly oauth2_proxy[3], and Buzzfeed SSO[4]. With an authenticating proxy an attacker can't even hit the web application until authenticating, so they can't exploit a vulnerability in the web application. They will have to pop the auth proxy first, which have less surface area, and then pop the web application. Applications that combine HTTP and SSH complicate things because the typical HTTP proxy won't proxy your SSH (git) connections, and the web authentication flow doesn't work with SSH. Cloudflare Access provides the auth proxy, cloudflared does the web authentication flow for a command line app and passes SSH traffic through Cloudflare Access. [1] https://www.cloudflare.com/products/cloudflare-access/ https://www.cloudflare.com/products/cloudflare-access/ [2] https://cloud.google.com/iap/ https://cloud.google.com/iap/ [3] https://github.com/bitly/oauth2_proxy https://github.com/bitly/oauth2_proxy [4] https://github.com/buzzfeed/sso https://github.com/buzzfeed/sso

otterley 8y ago
Can you explain why this setup is better than LDAP/Ansible/Chef (to provision user accounts) + ssh keys/CA-generated certificates for ssh authentication? This setup is well known in the art and isn't rife with reported vulnerabilities. The value of using a web flow to authenticate isn't clear to me because you have to provision user accounts on Unix systems anyway to have reasonable accountability.