Allow choosing SSH authentication methods

[j-xella]

Is your feature request related to a problem? Please describe.

I have an old server that only support authentication algorithm [ssh-rsa]. I understand that this algorithm is not secure any more, and openssh disabled support of it by default. So if I try connecting to the server with wezterm, I get:

Using libssh-rs to connect to XXXXXX
Error: Connecting to XXXXXX: Fatal: kex error : no match for method server host key algo: server [ssh-rsa], client [ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256]

However, my server is very old and I can't change the method. Also, the server is on internal network, so I am OK with the [ssh-rsa] risks.

Describe the solution you'd like
One of:

• add [ssh-rsa] to the list of client algorithms. Probably not good for security.

• Allow users to enable additional algorithms by adding support of ssh options -oHostKeyAlgorithms=-ssh-rsa.

Describe alternatives you've considered

• I have tried adding options PubkeyAcceptedAlgorithms or PubkeyAcceptedKeyTypes to my ~/.ssh/config, but it did not make any difference.

• Connecting with Putty :)

[wez]

I'd suggest using verbose mode. eg: wezterm ssh -v HOST and looking carefully at the output.
A portion of it may be libssh telling you about options that it does not support, and a portion will be relevant to the ssh protocol negotiation.
Likely, if there is a feature gap, it will need to be raised with the libssh folks rather than in wezterm.
You can find them at:

• https://gitlab.com/libssh/libssh-mirror

[j-xella]

The output of suggested wezterm ssh -v HOST :

00:45:42.781  ←[32mINFO  ←[0m ←[1mmux::ssh←[0m > Using ssh config: {
    "compression": "yes",
    "forwardx11": "yes",
    "hostname": "192.168.0.XXX",
    "identityfile": "XXXXXXXXXXXXXXX",
    "port": "22",
    "pubkeyacceptedkeytypes": "ssh-rsa",
    "user": "root",
    "userknownhostsfile": "XXXXXXXXXXXXXXXXXXX",
    "wezterm_ssh_backend": "libssh",
    "wezterm_ssh_verbose": "true",
}
00:45:42.792  ←[32mINFO  ←[0m ←[1mlibssh::ssh_config_parse_file←[0m > Reading configuration data from XXXXXXXXX
00:45:42.793  ←[32mINFO  ←[0m ←[1mlibssh::ssh_config_parse_line←[0m > Unapplicable option: ForwardX11, line: 2
00:45:42.794  ←[32mINFO  ←[0m ←[1mwezterm_ssh::sessioninner    ←[0m > resolved 192.168.0.XXX:22 -> 192.168.0.XXX:22
00:45:42.796  ←[32mINFO  ←[0m ←[1mlibssh::ssh_connect          ←[0m > libssh 0.8.90 (c) 2003-2023 Aris Adamantiadis, Andreas Schneider and libssh contributors. Distributed under the LGPL, please refer to COPYING file for information about your rights, using threading threads_winlock
00:45:42.798  ←[32mINFO  ←[0m ←[1mlibssh::ssh_connect          ←[0m > Socket connecting, now waiting for the callbacks to work
00:45:42.801  ←[32mINFO  ←[0m ←[1mlibssh::ssh_connect          ←[0m > Actual timeout : 10000
00:45:42.803  ←[32mINFO  ←[0m ←[1mlibssh::ssh_socket_pollcallback←[0m > Received POLLOUT in connecting state
00:45:42.806  ←[32mINFO  ←[0m ←[1mlibssh::socket_callback_connected←[0m > Socket connection callback: 1 (0)
00:45:42.807  ←[32mINFO  ←[0m ←[1mlibssh::ssh_client_connection_callback←[0m > session_state=2
00:45:42.808  ←[32mINFO  ←[0m ←[1mlibssh::ssh_socket_unbuffered_write   ←[0m > Enabling POLLOUT for socket
00:45:42.809  ←[32mINFO  ←[0m ←[1mlibssh::callback_receive_banner       ←[0m > Received banner: SSH-2.0-dropbear
00:45:42.810  ←[32mINFO  ←[0m ←[1mlibssh::ssh_client_connection_callback←[0m > session_state=3
00:45:42.811  ←[32mINFO  ←[0m ←[1mlibssh::ssh_client_connection_callback←[0m > SSH server banner: SSH-2.0-dropbear
00:45:42.812  ←[32mINFO  ←[0m ←[1mlibssh::ssh_analyze_banner            ←[0m > Analyzing banner: SSH-2.0-dropbear
00:45:42.814  ←[32mINFO  ←[0m ←[1mlibssh::ssh_client_select_hostkeys    ←[0m > Order of wanted host keys: "ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256"
00:45:42.818  ←[32mINFO  ←[0m ←[1mlibssh::ssh_known_hosts_read_entries  ←[0m > Failed to open the known_hosts file '/etc/ssh/ssh_known_hosts': No such file or directory
00:45:42.822  ←[32mINFO  ←[0m ←[1mlibssh::ssh_client_select_hostkeys    ←[0m > Algorithms found in known_hosts files: "rsa-sha2-512,rsa-sha2-256,ssh-rsa"
00:45:42.825  ←[32mINFO  ←[0m ←[1mlibssh::ssh_client_select_hostkeys    ←[0m > Changing host key method to "rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com"
00:45:42.826  ←[32mINFO  ←[0m ←[1mlibssh::packet_send2                  ←[0m > packet: wrote [type=20, len=908, padding_size=11, comp=896, payload=896]
00:45:42.829  ←[32mINFO  ←[0m ←[1mlibssh::ssh_send_kex                  ←[0m > SSH_MSG_KEXINIT sent
00:45:42.832  ←[32mINFO  ←[0m ←[1mlibssh::ssh_packet_socket_callback    ←[0m > packet: read type 20 [len=300,padding=7,comp=292,payload=292]
00:45:42.835  ←[32mINFO  ←[0m ←[1mlibssh::ssh_packet_process            ←[0m > Dispatching handler for packet type 20
00:45:42.838  ←[32mINFO  ←[0m ←[1mlibssh::ssh_client_connection_callback←[0m > session_state=5
00:45:42.840  ←[32mINFO  ←[0m ←[1mlibssh::ssh_kex_select_methods        ←[0m > kex error : no match for method server host key algo: server [ssh-rsa], client [rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com]
00:45:42.842  ←[32mINFO  ←[0m ←[1mlibssh::ssh_socket_exception_callback ←[0m > Socket exception callback: 2 (0)
00:45:42.843  ←[32mINFO  ←[0m ←[1mlibssh::ssh_socket_exception_callback ←[0m > Socket error: No error
00:45:42.844  ←[32mINFO  ←[0m ←[1mlibssh::ssh_client_connection_callback←[0m > session_state=9
00:45:42.846  ←[32mINFO  ←[0m ←[1mlibssh::ssh_connect                   ←[0m > current state : 9

It looks like a negotiation issue to me. Besides, this is what OpenSsh 8.8 release notes say:

Potentially-incompatible changes

This release disables RSA signatures using the SHA-1 hash algorithm
by default....

...

Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:

Host old-host
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

It would be great if wezterm supported these options ....

[wez]

wezterm can only support what the underlying ssh library supports.
Take a look at: #1262 (comment) for a possible way to resolve this

[j-xella]

I will try it later when I have access to the box.

But am I understanding correctly that in #1262 a support was added for PubKeyAcceptedTypes option only? The way Wezterm works, only selected few SSH options are passed to SSH library, not all of them, correct?

Because the problem in my case happens during host key validation, which is controlled by HostkeyAlgorithms +ssh-rsa option (I believe). Maybe, once that hurdle is overcome, it will croak on public keys as well...

[wez]

#1262 allowed wezterm to pass PubKeyAcceptedTypes as a parameter when using https://wezfurlong.org/wezterm/config/lua/SshDomain.html
It does not affect libssh parsing your .ssh/config file; if that option is present, libssh will read it from your config file.

[j-xella]

OK ... because this section of wezterm documentation made me think otherwise:

wezterm is now able to parse ~/.ssh/config and /etc/ssh/ssh_config and respects the following options:

• IdentityAgent
• IdentityFile
• Hostname
• User
• Port
• ProxyCommand
• Host (including wildcard matching)
• UserKnownHostsFile
• IdentitiesOnly
• BindAddress

All other options are parsed but have no effect. Notably, neither Match or Include will do anything.

[j-xella]

OK, silly me, I think I mixed up openssh and libssh 🤦‍♂️. It doesn't look like libssh supports HostkeyAlgorithms +ssh-rsa option, so no point asking for this any further ...

I think the fact that wezterm processes ~/.ssh/config file in openssh format got me confused about the ssh implementation in wezterm.

P.S. Another workaround I found on Windows is using wezterm with 3rd party ssh clients. For example:

wezterm-gui start ssh user@host

It uses some older version of openssh client bundled with a recent versions of Windows. At least ATM, it has support for ssh-rsa enabled, so the connection works.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.