Skip to content
HackIndex logo

HackIndex

SSH Legacy Crypto Login Compatibility

2 min read Jan 3, 2026

When you have valid creds or a valid key but modern clients won’t negotiate, force the legacy algorithms explicitly and keep the session controlled.

When this matters

This shows up on old appliances, unmanaged Linux builds, and “frozen” environments where SSH policy never got updated. The finding is usually not “you exploited SSH”. The finding is “the server requires or still accepts deprecated crypto”.

Keep this tight: prove negotiation, grab what you need, document the accepted algorithms.

Force legacy KEX and ssh-rsa to establish a session

Use this when you see group1 and ssh-rsa in enumeration, or when your client refuses to connect without overrides.

┌──(kali㉿kali)-[~]
└─$ ssh -p $PORT -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa $USERNAME@$TARGET_IP

If you only need proof of access without an interactive session, run a benign command and exit:

┌──(kali㉿kali)-[~]
└─$ ssh -p $PORT -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa $USERNAME@$TARGET_IP 'id; hostname; uname -a' 
uid=1000(user) gid=1000(user) groups=1000(user)
target-host
Linux target-host 5.10.0-... x86_64 GNU/Linux

If you’re using key-based auth on a legacy-only server

Same problem, different credential type. Combine the identity controls with legacy algorithm flags.

┌──(kali㉿kali)-[~]
└─$ ssh -p $PORT -i id_rsa -o IdentitiesOnly=yes -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa $USERNAME@$TARGET_IP

If you see “Too many authentication failures”, IdentitiesOnly=yes is mandatory.

Phase boundary: once you’re executing payload delivery or persistence actions, stop and put it in a Post-Exploitation or Persistence page. This page is only about establishing access when negotiation blocks you.

References