I'm setting up some servers for a new system and decided to do things a little bit differently. I'm running into an issue that I just can't seem to get past though. My desired configuration is having one bastion server and N other servers that can be accessed via the bastion only—a pretty typical configuration. The difference from what I normally do is that I would like to use signed SSH keys for authentication. This is pretty straight-forward for a single server but is throwing a wrench when using a bastion. Right now, I have two identically configured servers. I can access them both directly using a signed SSH key. However, if I try to use one as a bastion/jump host, I can't connect to the other. My ~/.ssh/config looks like this: Host ssh.uswe2 HostName ssh.uswe2.example.com User ec2-user IdentityFile ~/.ssh/ssh-rsa-cert Host *.uswe2 !ssh.uswe2 HostName %h.example.com User ec2-user ProxyCommand ssh -W %h:%p ssh.uswe2.example.com IdentityFile ~/.ssh/ssh-rsa-cert With this configuration, I can sign in to the bastion with ssh ssh.uswe2, but when I try to connect to the other server with ssh server2.uswe2 I get the following error: channel 0: open failed: administratively prohibited: open failed stdio forwarding failed kex_exchange_identification: Connection closed by remote host I can still connect directly to the server with ssh server2.uswe2.example.com over the public network though so I know that the CA and cert are being loaded correctly. My next thought was that maybe it was something to do with how the bastion is configured, but if I add my public key to ~/.ssh/authorized_keys on both servers, I can connect without any issue. I've reduced this down to a single command that is now showing issues: ssh -i /Users/bec23/.ssh/id_rsa-cert.pub -i /Users/bec23/.ssh/id_rsa -W 127.0.0.1:8080 disco-core@ssh.uswe2
I was just thinking of doing that too. Can you try with your sshd using '-d -D -o LogLevel DEBUG3' or '-d -D -E /tmp/sshd-bastion-troubleshooting.log' options? Have you tried to add the two CLI options, '-t -T' before your affected command line arguments? It should reveal something additional regarding the 'Match' (with DEBUG3).
Could you please attach debug traces (i.e. the output of "sshd -ddd") from the server that is failing authentication and the contents of the certificate in question (via "ssh-keygen -Lf /path/cert") It's unfortunately not possible to debug this further with the information provided.
closing bug: six months with no followup
close bugs that were resolved in OpenSSH 8.5 release cycle