rsync-deploy insecure by default on non-standard SSH port
Asked by Johannes F. Knauf:

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.


Answers:
author: Halyna Berezovska
body: [@Johannes F_ Knauf](/t5/user/viewprofilepage/user-id/1680389)thank 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

comments: author: Johannes F. Knauf
body: [@Halyna Berezovska](/t5/user/viewprofilepage/user-id/3865505) 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](https://bitbucket.org/atlassian/rsync-deploy/src/fd4258f2631270841e998b22373323116e01c387/test/test.py#lines-59) 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.


author: Halyna Berezovska
body: [@Johannes F_ Knauf](/t5/user/viewprofilepage/user-id/1680389)we 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


author: Halyna Berezovska
body: [@Johannes F_ Knauf](/t5/user/viewprofilepage/user-id/1680389)we'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


author: Johannes F. Knauf
body: [@Halyna Berezovska](/t5/user/viewprofilepage/user-id/3865505)Thanks 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.


author: Halyna Berezovska
body: [@Johannes F_ Knauf](/t5/user/viewprofilepage/user-id/1680389)ok, thanks, we'll notify you about the update.


author: Halyna Berezovska
body: [@Johannes F_ Knauf](/t5/user/viewprofilepage/user-id/1680389) 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


author: Johannes F. Knauf
body: 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](https://linux.die.net/man/1/ssh "man ssh") section "Escape Characters".


author: Halyna Berezovska
body: [@Johannes F_ Knauf](/t5/user/viewprofilepage/user-id/1680389) 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.


author: Johannes F. Knauf
body: Hi [@Halyna Berezovska](/t5/user/viewprofilepage/user-id/3865505) ,

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.


author: Halyna Berezovska
body: [@Johannes F_ Knauf](/t5/user/viewprofilepage/user-id/1680389) ok, thanks for such recommendation, we'll discuss it within a team


Tags: bitbucket-pipelines

cloud

rsync