Posted on by richay

Accessing Kali Linux through Guacamole SSH

Status: CURRENT — SECURITY WARNING / LEGACY WORKAROUND
Last reviewed: 31 August 2026
Applies to: Apache Guacamole SSH connections to modern OpenSSH/Kali Linux

Do not start by adding HostKeyAlgorithms +ssh-rsa to Kali. That re-enables the old RSA/SHA-1 signature algorithm which OpenSSH deliberately disabled by default. Update Guacamole/guacd and its SSH libraries first. Only use the old setting as a temporary compatibility workaround if you understand why the negotiation is failing.

Back in 2022 I had Guacamole refusing to SSH into a Kali Linux machine.

I found a Reddit comment suggesting this:

HostKeyAlgorithms +ssh-rsa


I added it to /etc/ssh/sshd_config on Kali and Guacamole started working.

At the time that solved the problem. In 2026, though, this absolutely needs some context before someone copies it into a current SSH server and accidentally makes security worse just to satisfy an ancient client.

Important correction: RSA itself wasn’t deprecated

The old explanation floating around in 2022 often said that “RSA was deprecated”. That’s not quite right.

OpenSSH 8.8 disabled the ssh-rsa signature algorithm by default because it uses the broken SHA-1 hash algorithm.

Existing RSA keys did not suddenly become useless. OpenSSH has supported stronger RSA signatures for years:

rsa-sha2-256
rsa-sha2-512


So this is an important distinction:

RSA key              = not automatically bad
ssh-rsa signature     = RSA + SHA-1, legacy
rsa-sha2-256 / 512    = RSA + SHA-2, modern


OpenSSH itself describes re-enabling RSA/SHA-1 as a stopgap for legacy implementations until they can be upgraded.

Why Guacamole used to have trouble

Guacamole’s SSH support is provided by libguac-client-ssh and the underlying libssh2 library.

Older Guacamole/guacd builds could therefore inherit the algorithm limitations of an older libssh2 build. A perfectly current OpenSSH server could reject the only host-key algorithm the old Guacamole side knew how to negotiate.

This is why weakening Kali was able to “fix” the connection: Kali began offering an old algorithm that the old client understood.

It worked, but we fixed the compatibility problem at the wrong end.

Recommended 2026 fix: update Guacamole first

Apache Guacamole 1.6.0 is the current release at the time of this review. Current Guacamole SSH support still uses libssh2, while newer Guacamole/libssh2 versions support modern SSH algorithms and newer key formats.

If you’re still running some prehistoric Guacamole container from the era when this article was written, update it before touching Kali’s SSH security.

For Docker, first check what you are actually running:

docker ps --format 'table {{.Names}}\t{{.Image}}' | grep -Ei 'guacamole|guacd'
docker logs --tail 50 guacd


Keep the Guacamole web application and guacd on matching current versions where practical.

For example:

services:
  guacd:
    image: guacamole/guacd:1.6.0

  guacamole:
    image: guacamole/guacamole:1.6.0


Don’t blindly replace two lines in a production Compose file from this snippet — database extensions, environment variables and your existing Guacamole setup still matter. The point is to get off the ancient SSH client stack first.

Check the Kali SSH server

On Kali, check the OpenSSH version:

ssh -V


Check which SSH host keys exist:

ls -l /etc/ssh/ssh_host_*_key.pub


A normal modern OpenSSH installation should generally have modern host keys available, commonly Ed25519 and/or ECDSA along with RSA.

If standard host keys are genuinely missing, OpenSSH can generate any missing defaults with:

sudo ssh-keygen -A


ssh-keygen -A generates host keys that don’t already exist; it isn’t a command for randomly replacing your existing server identity.

See what sshd is actually offering

Rather than guessing at the config, ask OpenSSH for the effective setting:

sudo sshd -T | grep -i '^hostkeyalgorithms'


Current OpenSSH defaults include modern algorithms such as:

ssh-ed25519
ecdsa-sha2-nistp256
rsa-sha2-512
rsa-sha2-256


Notice what’s missing from the normal modern default:

ssh-rsa


That’s deliberate.

Check Guacamole’s error before changing anything

If you’re using Docker:

docker logs --tail 200 guacd


Look for messages about SSH negotiation, key exchange, host-key algorithms or authentication.

Don’t assume every Guacamole SSH failure is an ssh-rsa problem. Bad credentials, a changed host key, an old key-exchange algorithm, networking, or a completely different SSH setting can all produce a failed connection.

Host key problem vs login-key problem

These are two different things and mixing them up causes a lot of shitty SSH advice on the internet.

  • HostKeyAlgorithms controls the algorithm the SSH server uses to prove its identity to the client.
  • PubkeyAcceptedAlgorithms controls signature algorithms accepted when a user authenticates with a public key.

If Guacamole cannot even negotiate the server’s host key, blindly adding PubkeyAcceptedAlgorithms +ssh-rsa isn’t fixing the same problem — it’s just weakening another setting for bonus points.

Last resort: temporarily re-enable ssh-rsa

CAUTION — LEGACY COMPATIBILITY ONLY

Only do this if you’ve confirmed that an old Guacamole/libssh2 client genuinely requires ssh-rsa and you cannot update it immediately. OpenSSH disabled this algorithm because it uses SHA-1. Remove the workaround once the client has been fixed.

Back up the SSH config first:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.before-ssh-rsa


Edit the server config:

sudo nano /etc/ssh/sshd_config


The historical workaround was:

HostKeyAlgorithms +ssh-rsa


The leading + matters: it appends ssh-rsa to the existing defaults rather than replacing the whole list.

Before touching the running SSH daemon, test the configuration:

sudo sshd -t


Do not continue if that returns an error. Keeping your current SSH session open while testing this is also a bloody good idea.

On Kali/Debian, reload SSH:

sudo systemctl reload ssh


Then immediately test Guacamole again.

Remove the workaround afterwards

Once Guacamole/guacd is upgraded and can negotiate a modern host-key signature, remove the compatibility line again.

You can find any old SHA-1 allowances with:

sudo grep -Rni 'ssh-rsa' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null


After removing the setting:

sudo sshd -t
sudo systemctl reload ssh


One more Guacamole security improvement

Current Guacamole supports SSH host verification using either an ssh_known_hosts file or a per-connection host-key value.

Surprisingly, Guacamole leaves host identity verification disabled if you don’t provide either of those.

For a private homelab that’s easy to ignore, but verifying the SSH server’s host key protects against connecting to the wrong machine or a man-in-the-middle. If you’re already cleaning up an old Guacamole SSH setup, it’s worth doing properly rather than merely making the red error box disappear.

Old article verdict

The old fix genuinely worked, so I’m not deleting it or pretending it never existed.

But the order of operations in 2026 should be:

1. Update Guacamole + guacd
2. Check guacd SSH logs
3. Confirm Kali has modern SSH host keys
4. Confirm modern algorithms are being offered
5. Fix the old client/library if possible
6. ONLY THEN temporarily enable ssh-rsa if absolutely required


Not:

Guacamole won't connect
        ↓
WEAKEN SSH UNTIL IT DOES
        ↓
sweet, fixed :D


Past me got the connection working. Current me would just like to stop past me from leaving a SHA-1-shaped rake on the lawn for someone else to step on 😅.

References

Leave a Reply

Your email address will not be published. Required fields are marked *