Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

rsync-deploy insecure by default on non-standard SSH port


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


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.


1 answer

@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 , 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

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.

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.

Regards, Galyna

@Halyna BerezovskaThanks for the feedback! Just go for it. I will not find the time soon. If I return to the topic and find my problem solved, I will be happy. If I return and it's still open for me to solve it, I will be happy, too.

Like Halyna Berezovska likes this

@Johannes F_ Knaufok, thanks, we'll notify you about the update.

@Johannes F_ Knauf in version 0.5.0 you can use

SSH_ARGS variable while using alternative port and pass, e.g.,

SSH_ARGS: '-o HostKeyAlgorithms=...'

Looking forward to seeing your feedback, thanks!

Regards, Galyna

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 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 @Halyna Berezovska ,

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.

Like Halyna Berezovska likes this

@Johannes F_ Knauf ok, thanks for such recommendation, we'll discuss it within a team

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Bitbucket

📣 Calling Bitbucket Data Center customers to participate in research

Hi everyone, Are you Bitbucket DC customer? If so, we'd love to talk to you! Our team wants to dive deep to understand your long-term plans regarding Bitbucket DC and Atlassian Cloud. Do you plan...

174 views 2 4
Read article

Community Events

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

Events near you