Hello, I encountered an unexpected behavior when the ProxyCommand adds keys to ssh-agent and provides files specified by paths in IdentifyFile and CertificateFile when IdentitiesOnly=yes is set. I am reaching out to confirm whether this behavior works as designed or if there is an opportunity to change the certificate file handling for this use case (details below). When ~/.ssh/config contains: Host nodename IdentityFile "~/.tsh/keys/teleport-proxy-url.com/username@xxxxxxxxx" CertificateFile "~/.tsh/keys/ teleport-proxy-url.com/username@xxxxxxxxx-ssh/teleport-proxy-url.com-cert.pub " ProxyCommand tsh proxy ssh --cluster=teleport-proxy-url.com --proxy= teleport-proxy-url.com%r@%h:%p IdentitiesOnly yes The desired behavior when invoking 'ssh nodename` is that the invocation of ProxyCommand runs 'tsh proxy ssh ...', which opens the browser for single sign-on, provides the identity and certificate files, and loads them into ssh-agent. Then there should be a transparent ssh connection to "nodename." However, what ends up happening is "Permission denied (publickey)." When digging into this, ssh.c:load_public_identity_files detects that IdentityFile and CertificateFile don't exist. Then in sshconnect2.c:pubkey_prepare, the keys are in the ssh-agent; however, since the IdentitiesOnly=yes, the keys don't get loaded into the preferred nor agent list. Next, when sshconnect2.c:userauth_pubkey is called, it will attempt to re-read the private key, which subsequently fails because the server was also expecting the certificate. This explains, "Permission denied (publickey)." I would like to use Teleport with IdentitiesOnly=yes, and I was considering modifying sshconnect2.c:pubkey_prepare to attempt loading the files there to support this use case. Before proposing a patch, I wanted to check with the maintainers if this would be a desirable behavior change. If so, I would appreciate guidance on where you would prefer such a change. If this works as designed, that works for me, and I'll adjust my ssh configuration accordingly. Eric N. Vander Weele _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
