No supported authentication methods available – SSH‑1 support decision

Answer first

No public timeline exists for removing the SSH-1 option from PuTTY. The option is retained in the current code base for backward compatibility with legacy systems, but there is no published removal date or commitment. Enabling SSH-1 is not a supported fix for No supported authentication methods available, and it should not be used for production access.

Confirmed facts

• Modern OpenSSH distributions default to Protocol 2 only and SSH-1 protocol support has been removed from current client and server code.
• Enabling SSH-1 introduces known cryptographic weaknesses and lacks integrity protection. It should never be used in production.
• The PuTTY error No supported authentication methods available is an authentication negotiation failure, not a missing protocol feature.

Likely explanation

The error means the client and server could not agree on an authentication method under the negotiated protocol. Common causes are:

• The client is offering only methods the server rejects, e.g., password when PasswordAuthentication is disabled, or a key type the server does not accept.
• The client is attempting SSH-1 against an SSH-2-only server, resulting in no mutually acceptable method.

Assumption: the host is a standard OpenSSH server. If the server is a proprietary or legacy implementation, supported authentication names and Protocol settings may differ.

Steps needed for this case

1. Confirm protocol negotiation. Use verbose output to see what protocol is negotiated and which methods are offered and accepted.
2. Verify server authentication policy. Inspect sshd_config for PasswordAuthentication, PubkeyAuthentication, AllowedAuthentications and AuthorizedKeysFile, then check the effective configuration.
3. Ensure the client presents a valid credential the server permits. Test with an explicit key and preferred authentication.

Safe verification commands:

ssh -v user@host

sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|allowedauthentications'

ssh -i <private_key> -o PreferredAuthentications=publickey user@host

Security and cost implications of leaving SSH-1 enabled

SSH-1 is deprecated and considered insecure by most modern SSH servers. Even for low-traffic, infrequent connections, enabling SSH-1 exposes the client to known attacks and weak integrity protection. There is no measurable cost saving that offsets that risk, and enabling the option does not resolve authentication negotiation failures under SSH-2.

Client-side alternatives without SSH-1

Legacy authentication can be addressed within SSH-2. In PuTTY, review Connection > SSH > Auth settings and the key algorithms offered under SSH > Host Keys. On the server side, ensure the required authentication method is permitted and the client presents a matching, valid key or password. Do not enable Protocol 1 to gain access.

One missing diagnostic detail that changes the recommendation: is the target server a standard OpenSSH server or a proprietary/legacy implementation? If it is a legacy implementation, supported authentication names and protocol behavior may differ from the steps above.