Windows SSH config not applied? Inspect it with ssh -G

You set a hostname, user, or port in an SSH config file, but the client still uses different values. Instead of repeatedly changing the connection command, inspect the configuration OpenSSH actually evaluates.

ssh -G prints the evaluated configuration and exits instead of starting an SSH login. The examples below use Windows OpenSSH from PowerShell. A WSL or Git Bash session can run a different SSH executable with a different configuration directory.

Identify the SSH executable

Get-Command ssh -All | Select-Object Source
ssh -V

Check the executable selected by your current shell. Windows’ built-in OpenSSH normally lives under C:\Windows\System32\OpenSSH\ssh.exe. Installing another client or changing a terminal profile can change which executable is run.

Check the config filename and location

The Windows OpenSSH user’s client file is %USERPROFILE%\.ssh\config. Check its name and location:

Get-ChildItem -Force "$env:USERPROFILE\.ssh" |
    Select-Object Name, FullName

The filename is config, without a .txt extension. sshd_config configures the server accepting connections; it is not this client file. Keep a copy before editing an existing configuration.

Use the alias in the Host block

Consider this example. The address is reserved for documentation; substitute your own destination when creating a real configuration.

Host blog-demo
    HostName 192.0.2.10
    User deploy
    Port 2222

Host *
    User commonuser
    Port 22

Inspect the alias that matches the block:

ssh -G blog-demo |
    Select-String '^(hostname|user|port|identityfile) '

The example’s user, hostname, and port should be:

user deploy
hostname 192.0.2.10
port 2222

Passing 192.0.2.10 directly does not match Host blog-demo. Use the alias when you want that block applied. Several identityfile lines can be normal because multiple identity candidates may be configured.

Compare an explicitly selected file

ssh -G -F "$env:USERPROFILE\.ssh\config" blog-demo |
    Select-String '^(hostname|user|port|identityfile) '

With -F .\config, the output shows deploy, 192.0.2.10, and port 2222. The identityfile lines are key candidates; their presence does not establish that authentication will succeed.

Compare this with the ordinary command. The -F option selects another client configuration file and also excludes the system-wide configuration file. A difference can therefore come from the chosen executable, the user file, or the system configuration.

Put specific settings before general defaults

For settings such as User and Port, OpenSSH normally uses the first value it obtains. Putting Host * first can establish a default before a later specific block is considered.

In this example, moving the wildcard block above Host blog-demo produces commonuser and port 22. Put the specific block first and inspect the result again.

Some directives behave differently: repeated IdentityFile entries add candidates. Check the directive’s manual rather than applying the first-value rule to every setting.

Check command-line overrides

ssh -G -p 2200 blog-demo |
    Select-String '^port '

This prints port 2200 because the command-line option takes precedence. Check saved shortcuts and terminal profiles for an old -p, -l, or user@host argument.

Separate configuration from connection failures

Once the evaluated hostname, user, and port match your intention, investigate the actual connection error: name resolution, TCP reachability, the SSH service, or authentication. Configuration inspection alone does not prove that a key will be accepted.

-G evaluates Host and Match conditions. A configuration using Match exec can still execute its configured command during evaluation; the example above does not use it.

References

• Microsoft Learn: OpenSSH configuration on Windows
• OpenSSH ssh(1)
• OpenSSH ssh_config(5)