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
@Galyna Zholtkevych 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
ssh -o StrictHostKeyChecking=no
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.
Making SSH_ARGS optionally configurable looks like a good design decision to me. It enables flexibility, while keeping the default simple and secure.
The only part I am missing is the
ssh -e none
This should always be used for rsync to disable ssh escapes. Otherwise there is a chance, that certain character sequences trigger the ssh escapes by accident.
See https://linux.die.net/man/1/ssh section "Escape Characters".
@Johannes F_ Knauf I suspect this also can be configured through this variable.
This variable is flexible, its type is a string, so you can pass
SSH_ARGS: '-e none -o HostKeyAlgorithms=...'.
If you have some problems with this, give us the feedback and we will implement better solution taking into account your need.
Hi @Galyna Zholtkevych ,
while your assertion is true and people could optionally enable it in SSH_ARGS, the option '-e none' should always be active. Nobody will ever want an ssh transport for rsync with escape sequences enabled. Escape sequences are only meaningful for interactive use. Please correct me, if I missed a use case there.
So it's more about using sensible defaults, that will prevent failures for all users of the rsync-deploy pipe.
On October 20, 2021, Atlassian published a security advisory for Jira Service Management. The full advisory is available at this link. We've seen a number of questions already asking for...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events