compose icon indicating copy to clipboard operation
compose copied to clipboard

1.28.5 issues connecting over SSH

Open PhilJay opened this issue 4 years ago • 16 comments

Description of the issue

I've recently updated from docker-compose 1.27.4 to 1.28.5. Prior to the update, the following command worked as expected: docker-compose -f docker-compose.yml -H "ssh://[email protected]" up --build --force-recreate -d

After the update, I'm getting a connection refused error: ssh: connect to host domain.com port 22: Connection refused

Downgrading to 1.27.4 resolves the issue.

Context information

I am deploying to a linux server with ufw enabled, the configuration is as follows:

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT       Anywhere                  
2375/tcp                   ALLOW       Anywhere                  
2376/tcp                   ALLOW       Anywhere                  
Apache Full                ALLOW       Anywhere                  
22/tcp (v6)                LIMIT       Anywhere (v6)             
2375/tcp (v6)              ALLOW       Anywhere (v6)             
2376/tcp (v6)              ALLOW       Anywhere (v6)             
Apache Full (v6)           ALLOW       Anywhere (v6)  

Output of docker-compose version

docker-compose version 1.28.5, build c4eb3a1f
docker-py version: 4.4.4
CPython version: 3.9.0
OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020

Output of docker version

Client: Docker Engine - Community
 Cloud integration: 1.0.9
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:13:00 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:15:47 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker-compose config (Make sure to add the relevant -f and other flags)

networks:
  rmd:
    driver: bridge
services:
  rmd-cms:
    build:
      context: /project
      dockerfile: Dockerfile
    container_name: rmd-cms
    image: rmd-cms
    networks:
      rmd: null
    ports:
    - published: 1343
      target: 80
    restart: always
version: '3.7'

Steps to reproduce the issue

  1. Install docker-compose 1.28.5
  2. Setup linux server and enable ufw with the above rules
  3. Use docker-compose up with SSH

Observed result

ssh: connect to host domain.com port 22: Connection refused

Expected result

docker-compose works as expected without a connection refused error.

PhilJay avatar Mar 19 '21 12:03 PhilJay

Hi @PhilJay. Is it working when you manually ssh to the host with ssh user@hostdomain?

To switch back to using the implementation from 1.27.4, you ca try setting COMPOSE_PARAMIKO_SSH=1 with 1.28.5

aiordache avatar Mar 19 '21 14:03 aiordache

Yes, manual SSH is working as expected. Using COMPOSE_PARAMIKO_SSH=1 resolves the problem and gets rid of the connection refused error 👍 . Any idea what is different in 1.28.5 to cause this? Additionally, do you have any idea if this is related to #8222 ?

PhilJay avatar Mar 19 '21 14:03 PhilJay

@PhilJay In 1.28 we switched to shelling out to the SSH client to align it with the docker cli. We left the paramiko client as a fallback for cases when the shelling out does not work.

The new implementation spawns a python subprocess that executes a docker cli command through SSH to connect to the daemon. It runs ssh -l user -p port -- host docker system dial-stdio which allows to make HTTP queries via the stdin/stdout of the subprocess.

Would you mind trying to run this:

$ ssh -l user -p port -- hostdomain docker system dial-stdio
GET /v1.41/containers/json HTTP/1.1
Host: localhost
User-Agent: docker-compose/1.29.0dev
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Once you input 2 newlines you should get the container data from the daemon.

Do you always get the SSH error for all commands or is it only when you run with build?

aiordache avatar Mar 19 '21 16:03 aiordache

@aiordache It appears that it's unrelated to build and occurs on every command I tried. The above command (updated with my user info of course) gives me a 400 error.

PhilJay avatar Mar 22 '21 09:03 PhilJay

@PhilJay Are you sure you you wrote the HTTP request as:

GET /v1.41/containers/json HTTP/1.1
Host: localhost
User-Agent: docker-compose/1.29.0dev
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

You would get 400 if one of the fields is missing or is invalid:

$ ssh hostdomain docker system dial-stdio
GET /v1.41/containers/json HTTP/1.1

HTTP/1.1 400 Bad Request: missing required Host header
Content-Type: text/plain; charset=utf-8
Connection: close

400 Bad Request: missing required Host header

Do you get the 400 error codes for all queries? What is the error message ?

GET /version HTTP/1.1 or GET /v1.41/images/json HTTP/1.1

Are the docker cli commands working when you target the remote host:

$ docker -H ssh://user@hostdomain ps

aiordache avatar Mar 22 '21 10:03 aiordache

@aiordache Ok got it now, was missing something.

I'm getting a 200 now for the request you wanted me to test, so it is working.

Concerning the docker cli commands targeting the remote host: They are working as well.

PhilJay avatar Mar 22 '21 11:03 PhilJay

If the manual ssh queries work fine, it should work with docker-compose too. It executes the same commands.

One last question to see if we can narrow down the issue. Did you use so far the 1.28.5 binary? Do you mind trying the 1.28.5 installed via pip. You can run a python virtualenv to test.

In case the one installed via pip works fine, the issue may be in the binary runtime setup with Pyinstaller.

aiordache avatar Mar 22 '21 12:03 aiordache

I've now installed docker-compose via pip, tried the above mentioned command without using COMPOSE_PARAMIKO_SSH=1: Getting the same error: ssh: connect to host domain.com port 22: Connection refused

PhilJay avatar Mar 22 '21 13:03 PhilJay

In case it's relevant, I was having a problem with 1.28.5 on my Mac, where every command was taking at least 15 secs. I was using SSH to a remote engine on Ubuntu, and had the ssh info set up as a docker context. The docker client was fine; this was only an issue with docker-compose. e.g.

docker-compose -c mycontext ps takes 15s docker -c mycontext ps takes 0.9s

Reverting to 1.27 or setting COMPOSE_PARAMIKO_SSH=1 made everything fast again in docker-compose, but I started hitting the errors in #6463 and had to increase MaxSessions on my remote sshd.

With the combinations of those two workarounds, it's fine.

1.28 in the non-paramiko mode is still painfully slow. (But everything does eventually work).

quentinsf avatar Mar 26 '21 20:03 quentinsf

I'm also having the same problems using compose on a remote machine via SSH, have seen this with logs and down.

jswny avatar Apr 05 '21 23:04 jswny

Had the same problem. Try using

docker compose up

instead of

docker-compose up

then, everything works. Though it says that docker compose up is still experimental.

jayjootar avatar Apr 16 '21 10:04 jayjootar

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Oct 30 '21 16:10 stale[bot]

As I previously mentioned on the closed issue #6336 this is an issue in Travis-CI as well. Just wanted to pass along my experience on an open ticket.

I noticed this issue using docker-compose v 1.28.5 in Travis-CI.

I downgraded to 1.27.4 which is what we use in Travis-CI for another project and it worked as expected.

crshumate avatar Mar 03 '22 23:03 crshumate

This issue has been automatically marked as not stale anymore due to the recent activity.

stale[bot] avatar Mar 03 '22 23:03 stale[bot]

docker <space> compose (compose v2) has been released in September, you should consider updating

ndeloof avatar Mar 04 '22 11:03 ndeloof

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Sep 21 '22 10:09 stale[bot]

This issue has been automatically closed because it had not recent activity during the stale period.

stale[bot] avatar Nov 02 '22 03:11 stale[bot]