4

I'm trying to set up SSH multiplexing, but I'm running into an error, and there are insofar 0 hits on Google for the exact error message.

I created ~/.ssh/config with the contents:

Host *
 ControlPath ~/.ssh/master-%r@%h:%p

Then, I created the master connection by running:

ssh -vMM user@host.example.com

which seems to create the multiplexing socket successfully:

...
Authenticated to host.example.com ([1.2.3.4]:22).
debug1: setting up multiplex master socket
debug1: channel 0: new [/home/user/.ssh/master-user@host.example.com:22]
debug1: channel 1: new [client-session]
debug1: Entering interactive session.
...

Then, I try running a command via ssh in another window:

ssh -v user@host.example.com ls

However, this seems to fail to use the multiplexing socket:

OpenSSH_7.5p1, OpenSSL 1.1.0f  25 May 2017
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
Master refused session request: Permission denied
debug1: Connecting to host.example.com [1.2.3.4] port 22.
...

What could cause the Master refused session request: Permission denied error to occur?


Edit: The permissions of ~/.ssh and ~/.ssh/config are 700 and 644 respectively, so I don't see an issue there. ~/.ssh/master-* doesn't exist, I guess it's an abstract UNIX socket (and thus does not actually exist in the filesystem)? But then, that still doesn't explain the "access denied" error.

Also, I noticed that when attempting to establish the second connection, the master connection prints:

debug1: channel 2: new [mux-control]
debug1: permanently_drop_suid: 0
ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory
debug1: channel 2: free: mux-control, nchannels 3

Perhaps this is related. I'm connected using an unencrypted SSH key, so I don't see why SSH would need to ask for a password.

1 Answers1

5

I've figured out what is causing the "Access denied" error.

By default, SSH seems to want to interactively ask for permission when another SSH process wants to use an existing multiplex session. However, the ssh-askpass program, which it uses to ask for permission, was missing on my system, so SSH defaults to "no, don't grant access", thus resulting in an "access denied" error message on the client.

If ssh-askpass is installed (which is in the x11-ssh-askpass package on Arch Linux), then a dialog such as the following will be displayed:

Selecting "OK" will allow the connection attempt to continue.

The prompt itself was caused because I specified -M twice on the master's command line. To quote SSH(1):

Multiple -M options places ssh into “master” mode with confirmation required before slave connections are accepted.