From documentation: -F configfile Specifies an alternative per-user configuration file. If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will be ignored. The default for the per-user configuration file is ~/.ssh/config. From reality: If I put something like "IdentitiesOnly yes" in my ~/.ssh/config, then run "ssh -F not_my_ssh_config", which does not have IdentitiesOnly in it, the behavior I see is that SSH will have IdentitiesOnly set to yes. SSH appears to run both the ~/.ssh/config and whatever file you specify with "-F". When I use "-F" I would expect that it would only use the file I specified and not use my "~/.ssh/config" at all.
Please, provide the debug log from the example where you see this behavior. I do not see this behavior: $ ssh -vvv -F /dev/null localhost 2>&1 | grep config debug1: Reading configuration data /dev/null [jjelen@t470s ~]$ ssh -vvv localhost 2>&1 | grep config debug1: Reading configuration data /home/jjelen/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config [...]
It seems like the reality is a little more complicated. I'm seeing this behavior through a ProxyCommand. Here's what I'm seeing. Note that after creating a ~/.ssh/config with "IdentitiesOnly yes", I get a password prompt even though I'm specifying "-F ssh-bastion.conf" on the command line: $ cat ssh-bastion.conf Host 52.47.157.242 Hostname 52.47.157.242 StrictHostKeyChecking no ControlMaster auto ControlPath ~/.ssh/ansible-%r@%h:%p ControlPersist 5m Host 10.250.204.35 ProxyCommand ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -W %h:%p core@52.47.157.242 $ cat ~/.ssh/config cat: /home/evans/.ssh/config: No such file or directory $ ssh -F ssh-bastion.conf core@10.250.204.35 echo hi Warning: Permanently added '52.47.157.242' (ECDSA) to the list of known hosts. hi $ echo 'IdentitiesOnly yes' > ~/.ssh/config$ ssh -F ssh-bastion.conf core@10.250.204.35 echo hi Warning: Permanently added '52.47.157.242' (ECDSA) to the list of known hosts. Password: Here's debug output showing that it says it's only loading ssh-bastion.conf, but it's definitely behaving like it's reading ~/.ssh/config. You can see that the command goes through after I delete ~/.ssh/config even though I'm specifying "-F ssh-bastion.conf": $ ssh -vvv -F ssh-bastion.conf core@10.250.204.35 echo hi |& egrep '(config|hi)' debug1: Reading configuration data ssh-bastion.conf Password: $ rm ~/.ssh/config $ ssh -vvv -F ssh-bastion.conf core@10.250.204.35 echo hi |& egrep '(config|hi)' debug1: Reading configuration data ssh-bastion.conf debug1: Sending command: echo hi hi $ AHA! OK, I just figured it out... The ProxyCommand doesn't have "-F" specified. If I put "-F /dev/null" in the ProxyCommand, things work as expected! $ cat ssh-bastion.conf Host 52.47.157.242 Hostname 52.47.157.242 StrictHostKeyChecking no ControlMaster auto ControlPath ~/.ssh/ansible-%r@%h:%p ControlPersist 5m Host 10.250.204.35 ProxyCommand ssh -vvv -F /dev/null -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -W %h:%p core@52.47.157.242 $ echo 'IdentitiesOnly yes' > ~/.ssh/config $ ssh -vvv -F ssh-bastion.conf core@10.250.204.35 echo hi |& egrep '(config|hi)' debug1: Reading configuration data ssh-bastion.conf debug1: Reading configuration data /dev/null debug1: Sending command: echo hi hi Problem solved. Overly complex SSH config. I'll make push a bugfix to kubespray to have them add "-F /dev/null" to ProxyCommand in their ssh-bastion.conf file.
There already was very similar bug, which turned out was the same configuration issue. https://bugzilla.mindrot.org/show_bug.cgi?id=2827 Anyway, if you want to avoid these issues, I think using ProxyJump will pass the -F switch to the ProxyCommand automatically (which should work for you too). I am not closing the bug since this should be really done by you or a OpenSSH developers, but I am glad it worked for you.
What Jakub said is correct: your configuration is running a separate instance of ssh that does not include the -F option. He's also correct that JumpHost avoids this particular problem by always passing the -F option to subordinate ssh invocations.
Closing all resolved bug with release of openssh-8.2