Hi folks,
I recently used atlassian/rsync-deploy:0.4.4 with SSH_PORT. I noticed that rsync-deploy switches to
ssh -o StrictHostKeyChecking=no
in that case. I could track it down to https://bitbucket.org/atlassian/rsync-deploy/src/fd4258f2631270841e998b22373323116e01c387/pipe/pipe.sh#lines-90
This setting compromises SSH's security architecture. It should not be used here. Does someone happen to know the reasoning behind that configuration of StrictHostKeyChecking? I want to provide a fix.
@Johannes F_ Knaufthank you for raising this, we will consider this for the future updates and bugfixes.
Also, we are always happy to meet contributors to our pipes.
Contributing, don't forget about tests and semversioner change and other stuff , referring to documentation for contribution https://bitbucket.org/atlassian/rsync-deploy/src/fd4258f2631270841e998b22373323116e01c387/CONTRIBUTING.md , so we can merge it faster without long review process
Regards, Galyna
@Halyna Berezovska In order to contribute a proper fix, I am still missing information about the background of the developer's design decision. I have a conjecture, but I rather want some confirmation here. I surmise that this flag has been introduced, because the default SSH hostkey registration in Bitbucket (Repository Settings → SSH Keys → Known Hosts) seems to retrieve only RSA keys.
I made a similar experience in the meantime when switching back from rsync-deploy to wrapper-free rsync commands in my pipelines: Connection to hosts primarily offering different protocols, e.g. ECDSA, will fail by default.
The SSH hostkey preparation in rsync-deploy's test code backs my assumption.
In that case, changing from
to
ssh -o HostKeyAlgorithms=ssh-rsa
would be all that is needed.
When touching this piece of code, adding '-e none' might be a good idea, as well.
ssh -e none -o HostKeyAlgorithms=ssh-rsa
SSH features some escape characters for connection control by default, so a SSH connection without '-e none' will not be fully transparent, but might break when the communicating programs accidentally hit an escape character.
@Johannes F_ Knaufwe try to not hardcode such stuff in the pipe.
But in the tests it can be implemented.
About repository ssh keys: we are not using them in this pipe's tests.
We are authenticating using test environment variables.
Don't worry, if it does not work for you, we will contact in the pr or by email.
Just tell if you want to contribute and we will discuss your case next week.
REgards, Galyna
@Johannes F_ Knaufwe've discussed your case. So we think that it would be nice improvement. Tell us if you want to contribute yourself or we can do it in the future release.
It looks like you're new here. Sign in or register to get started.
