Compose not behaving nicely with --context flag with a ssh host

Open Source Projects Compose
1

Hi to everyone!
I’m having some problem using docker-compose with the --context flag, in particular when using a ssh context.
The problem derives from ssh multiplexing:
as described in the official docs is possible to enable ssh multiplexing for reusing ssh connections. When calling the command

docker-compose --context mysshcontext up -d

this log keeps repeting in the output:

mux_client_request_session: session request failed: Session open refused by peer
ControlSocket /home/users/myuser/.ssh/socket-myuser@myhost.com:22 already exists, disabling multiplexing

Does anyone know how to configure docker-compose or the ssh stuff to best utilize this feature?

NB: compose works if the ssh options are disabled.

Thanks!

marco

2

If anyone get these errors set ssh ControlPersist to no:
ControlMaster auto
ControlPersist no
ControlPath ~/.ssh/socket-%l-%r@%h:%p

1 Like
3

Anyone know why official docs give a slightly different answer with only “%C”? Maybe it’s more compatible across linux?

I still get pretty frequent mux_client_request_session errors following docs with latest docker 23.0.5 and ubuntu 20 to modern ubuntu and centos.

# Not good enough, still leads to errors?
ControlPath       ~/.ssh/control-%C
ControlPersist    yes

I switched to the suggestion above and it seems to be really working. Will try ControlPersist 5m but might try no.
ControlPath ~/.ssh/socket-%l-%r@%h:%p

4

Continuing the discussion from Compose not behaving nicely with --context flag with a ssh host:

Unfortunately still seeing the dreaded
kex_exchange_identification: Connection closed by remote host
with that ControlPath and ControlPersist 5m.
Trying ControlPersist no, nope more docker errors.

Ugh this sucks does anyone using DOCKER_HOST=ssh://… with a variety of linux boxes and not encounter this kex error?

5

You can find tokens here: https://man.openbsd.org/ssh_config#TOKENS

%C is just %l%h%p%r

I never heard of this setting, so I can’t tell you much more about it. My guess is that it just has to uniquely describe the connection but this gues could be completely wrong. Since the original post container the error message “already exists”, could it be that it wasn’t unique enough originally or it wasn’t properly deleted previously?

1 Like
6

Do you know that you posted in the same topic? :slight_smile:

7

Oops had some problems posting and accidentally kept that text.

Thanks ok that makes sense, %C is basically the same.

I just realized the ~/.ssh/ directory in this situation is NFS mounted, I wonder if that can make it unreliable. Maybe I should try moving ControlPath to /tmp or /var/run/users/ or ?

8

Yes, I wouldn’t store it on NFS, but I don’t know if that is your problem or not.

9

sadly, moving the ControlPath to /tmp does not eliminate this occasional failure:

command [ssh -o ConnectTimeout=30 -- mb1-15.X.Y.com docker system dial-stdio] has exited with exit status 255, please make sure the URL is valid, and Docker 18.09 or later is installed on the remote host: stderr=mux_client_request_session: session request failed: Session open refused by peer
kex_exchange_identification: Connection closed by remote host