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

Johannes F. Knauf March 19, 2021

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.

 

1 answer

0 votes
Halyna Berezovska
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 22, 2021

@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

Johannes F. Knauf March 23, 2021

@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

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.

Halyna Berezovska
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 26, 2021

@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

Halyna Berezovska
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 29, 2021

@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

Johannes F. Knauf March 30, 2021

@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
Halyna Berezovska
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 5, 2021

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

Halyna Berezovska
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 26, 2021

@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

Johannes F. Knauf May 5, 2021

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".

Halyna Berezovska
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 7, 2021

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

Johannes F. Knauf May 7, 2021

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
Halyna Berezovska
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 7, 2021

@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
TAGS
AUG Leaders

Atlassian Community Events