fwiw, probably a better way to go would be to use scp to copy things instead of relying on agent forwarding (but maybe there are other reasons for the agent forwarding?)

Either way, this is a quick fix for this, switching to scp would take a bit more work

Agent forwarding is required to be able to copy from the release store host to the deploy hosts directly.
Because scp does not support agent forwarding, ssh is used directly for copying.

Agent forwarding is required to be able to copy from the release store host to the deploy hosts directly.
Because scp does not support agent forwarding, ssh is used directly for copying.

Why would we need agent forwarding for scp? Can't you just scp from the machine w/ the credentials?

Without agent forwarding it would be required that all private keys for all deploy hosts are available on the release store host. If they are protected by a passphrase it would be also required to enter the passwords for the keys while deploying or to add them to the authentication agent on the release store host before. It would also mean, that everybody with access to the release store has also access to the deploy hosts. Agent forwarding allows to authenticate the deploy hosts only once on your local machine and use that authentication when copying (over ssh) from the release store host to the deploy hosts directly.

Couldn't you do the scp locally from the machine running edeliver? It would mean that the deployer has access to the release store host, the build host and the deploy hosts, but I'm not sure why that would be a problem. If a user can deploy code to a machine it's not far-fetched to require them to have ssh access to it.

@aaronjensen What you are proposing would take two copies. One time from the release store to the local machine and one time from the local machine to the deploy host. I think that is the reason @bharendt did not like it.

Now to get back to your PR after all this time: Is it not the same thing to set the controlpath to none as if I don't set it at all? Or is it sharing the connections by default? This is the first time I'm hearing about sharing connections, so I'm just asking. I read the section about ControlMaster here: https://linux.die.net/man/5/ssh_config.

What you are proposing would take two copies. One time from the release store to the local machine and one time from the local machine to the deploy host.

I don't really remember this conversation and I'm not using edeliver currently so I'm not going to try and catch back up.

Is it not the same thing to set the controlpath to none as if I don't set it at all? Or is it sharing the connections by default?

Some people set it for all ssh connections, though probably not many. This makes it safe for those people. People that do not set it are not affected, which is probably why there haven't been many people who have run into this issue.

I did not properly read the corresponding issue #104. I reject this because the default should be fine for most people. In the future we'll find a way around the alleged security holes of agent forwarding (e.g. with scp). For now we leave it up to the user if he wants to speed up the build process with ControlPersist (and increase his risk), or not use it at all (default).

@johannesE thanks for investigation! Thumbs up for prioritizing safety over speed.

Uh. Ok. Reverting this does not prioritize safety over speed. It makes edeliver break in a confusing way for some people who have made adjustments to their ssh config that they did not intend to impact their deployments.

For example, I made the adjustment to use control persist years before I used edeliver. I started to use edeliver and found it would not work randomly sometimes. It took me some time to track it down and it led me to the fact that edeliver ASSUMES that ControlPersist is not being used. If you are going to change the connection parameters (add agent forwarding) the correct/safe thing to do is to disable control persist. If you really want the speed (assuming edeliver makes multiple ssh connections, I do not recall) then you could set the control path to a temp dir.

Any way clearly I am a minority and I’m not even using edeliver at the moment so feel free to do what you want, but I feel bad for the next person that has to waste a day tracking this down.

I just reread your rejection @johannesE and it seems you may have misunderstood the original issue still. There is no security vulnerability now, I was saying that in response to the assertion that I should enable agent forwarding in my config.

The issue is one of a bug in edeliver when it makes assumptions about a users ssh config.

The last part of #104 (comment) details an option that would be both safe and allow for speed increases. If you're not going to just disable it outright, I'd recommend you do that at least.

I completely fucked up on this issue. At first I thought, we need to merge this. Then I got cold feet when I read the issue comments and reverted it. This was the mistake. In the end (a few hours ago) I did the unspeakable and force pushed the master back to when I merged it. Sorry about the confusion. This PR has definitely been merged, the git tree is clean and I'm 99% sure that I did not disturb anyone's workflow.

No worries, thanks! It was a confusing one--that's why I was wanting to ensure it was understood so as to protect the future 😄

One more thing: Thank you @aaronjensen for your work.

The last part of #104 (comment) details an option that would be both safe and allow for speed increases. If you're not going to just disable it outright, I'd recommend you do that at least.

I'll think about adding -o ControlMaster=auto -o ControlPath=/tmp/edeliver-build-host -o ControlPersist=10m

In any case: if few of the users lose a lot of time because of this, it's not worth the small speed increase for the others, because they are just passively losing their time. Security risks aside.

You bet. Adding that should be safe as long as edeliver is consistent in requesting agent forwarding. If edeliver does not request agent forwarding in the initial connection but does later, that would break.

Cheers!

That makes sense and I would've missed that, thx!