4 ms·

> don't use agent forwarding ever. If you know better, be damn sure you are right I am curious. Why do you say this? My use case for agent forwarding is durin

by abhaga 15y ago

> don't use agent forwarding ever. If you know better, be damn sure you are right I am curious. Why do you say this? My use case for agent forwarding is during automated deployment. Without agent forwarding, when pulling from SVN, I either need to enter password every time or have my private keys uploaded to the server where I want to deploy.

alexchamberlain 15y ago
Public keys, surely?
- abhaga 15y ago
  Sorry if I am missing out the sarcasm here :) but I did mean private keys since I am trying to authenticate from the prod machine to the source control server.
  - alexchamberlain 15y ago
    Then you're a fool! Generate new private keys on the PROD server and upload them. I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server.
    - abhaga 15y ago
      > Generate new private keys on the PROD server and upload them. How is that any more secure then agent forwarding? The vulnerability with agent forwarding needs some work and right timing to be exploited after the prod server is rooted. Having a set of private keys lying around is offering access on a plate. >I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server. Yes, I am wiser (or less foolish if you prefer ;-) ) now. One can always fall back to rsync and friends if the SCM lacks.
      - cmsj 15y ago
        Having specific keys for specific purposes is more secure because when you add the public half of it to your SVN server, you put the extra options along with the key that limit the server it can come from, and the command it can execute. This means that your seemingly-scary private key can now do one thing and one thing only - pull from svn. Now you can do deployments without any constraints like "abhaga needs to be awake and have his computer on and be SSHed to the right places" :)
      - cmsj 15y ago
        Having specific keys for specific purposes is more secure because when you add the public half of it to your SVN server, you put the extra options along with the key that limit the server it can come from, and the command it can execute. This means that your seemingly-scary private key can now do one thing and one thing only - pull from svn. Now you can do deployments without any constraints like "abhaga needs to be awake and have his computer on and be SSHed to the right places" :)
ryan-c 15y ago
Anyone with access to your account (this would include root) on a machine which you have forwarded your agent to can use it to authenticate as you. For your use case, the least evil option would be to set up an SSH key that is restricted on the SVN server to only be able to do an svn export.
ajross 15y ago
You probably need to rethink the security characteristics of your deployment architecture. You shouldn't be authenticating from a production host (which is presumably internet-facing, and thus more likely to be compromised), you should be pushing to it from a more protected source like a build machine behind a firewall. Using agent forwarding in this case is precisely the problem being discussed. If someone roots your web server (or whatever it is), they can authenticate as your ssh account to any host that accepts it. So at a minimum your subversion server will be compromised if any of the production hosts are. Bad.
- abhaga 15y ago
  > You probably need to rethink the security characteristics of your deployment architecture. I'm wiser now :). Although till I don't move to a push model, I think I will explore the restricted keys as suggested by ryan-c and use them. Unfortunately, none of the one shot deployment systems point this out. Most of them do a git pull on production. When I built mine, I wanted to avoid putting my private keys up on the production, so I went with Agent Forwarding.

by abhaga 15y ago

alexchamberlain 15y ago

Public keys, surely?

abhaga 15y ago
Sorry if I am missing out the sarcasm here :) but I did mean private keys since I am trying to authenticate from the prod machine to the source control server.
- alexchamberlain 15y ago
  Then you're a fool! Generate new private keys on the PROD server and upload them. I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server.
  - abhaga 15y ago
    > Generate new private keys on the PROD server and upload them. How is that any more secure then agent forwarding? The vulnerability with agent forwarding needs some work and right timing to be exploited after the prod server is rooted. Having a set of private keys lying around is offering access on a plate. >I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server. Yes, I am wiser (or less foolish if you prefer ;-) ) now. One can always fall back to rsync and friends if the SCM lacks.
    - cmsj 15y ago
      Having specific keys for specific purposes is more secure because when you add the public half of it to your SVN server, you put the extra options along with the key that limit the server it can come from, and the command it can execute. This means that your seemingly-scary private key can now do one thing and one thing only - pull from svn. Now you can do deployments without any constraints like "abhaga needs to be awake and have his computer on and be SSHed to the right places" :)
    - cmsj 15y ago
      Having specific keys for specific purposes is more secure because when you add the public half of it to your SVN server, you put the extra options along with the key that limit the server it can come from, and the command it can execute. This means that your seemingly-scary private key can now do one thing and one thing only - pull from svn. Now you can do deployments without any constraints like "abhaga needs to be awake and have his computer on and be SSHed to the right places" :)

ryan-c 15y ago

Anyone with access to your account (this would include root) on a machine which you have forwarded your agent to can use it to authenticate as you. For your use case, the least evil option would be to set up an SSH key that is restricted on the SVN server to only be able to do an svn export.

ajross 15y ago

You probably need to rethink the security characteristics of your deployment architecture. You shouldn't be authenticating from a production host (which is presumably internet-facing, and thus more likely to be compromised), you should be pushing to it from a more protected source like a build machine behind a firewall. Using agent forwarding in this case is precisely the problem being discussed. If someone roots your web server (or whatever it is), they can authenticate as your ssh account to any host that accepts it. So at a minimum your subversion server will be compromised if any of the production hosts are. Bad.

abhaga 15y ago
> You probably need to rethink the security characteristics of your deployment architecture. I'm wiser now :). Although till I don't move to a push model, I think I will explore the restricted keys as suggested by ryan-c and use them. Unfortunately, none of the one shot deployment systems point this out. Most of them do a git pull on production. When I built mine, I wanted to avoid putting my private keys up on the production, so I went with Agent Forwarding.