gitea: key exhange negotiation failed though client and server share some protocols

I’m not sure if it’s related but after the upgrade I started getting:

Unable to negotiate with XYZ port 22: no matching host key type found. Their offer: ssh-rsa
fatal: Could not read from remote repository.

I’m also using built-in SSH server and I didn’t configure neither SSH_SERVER_KEY_EXCHANGES nor SSH_SERVER_CIPHERS previously, so I suppose it uses defaults.

Workaround is to specify SSH parameter in ~/.ssh/config:

Host mygiteahost.com
	Port 2222
	HostKeyAlgorithms +ssh-rsa
	PubkeyAcceptedAlgorithms +ssh-rsa
	User gitea

For anyone who ends up here, here is how you can easily switch over to ed25519.

Use ed25519 on the gitea side

Add SSH_SERVER_HOST_KEYS = ssh/gitea.ed25519 to your app.ini:

SSH_SERVER_HOST_KEYS     = ssh/gitea.ed25519

Don’t bother setting SSH_SERVER_CIPHERS, SSH_SERVER_KEY_EXCHANGES and SSH_SERVER_MACS, that is not necessary. However, in case you find it necessary to do so, please consult man sshd_config and ssh -Q cipher|key|key-sig.

In case the keys don’t get generated automatically, move to the ssh directory in your gitea data dir and generate the keys manually:

cd /var/gitea/ssh             # Change to your needs
ssh-keygen -t ed25519 -f gitea.ed25519

Then restart gitea, and look for the following entry in the log

2021/10/19 07:11:14 modules/ssh/ssh.go:312:Listen() [I] Adding SSH host key: /data/gitea/ssh/gitea.ed25519

Perhaps the gitea config cheat sheet is useful, if the above stated suggestions don’t work for you and you need to dive deeper into the configuration options.

Force ssh to use ed25519 for your gitea server

In my case the above stated steps were enough to fix the issue. If for some reason, you ssh needs to be forced to use ed25519, then see the following template for your ~/.ssh/config file

HOST gitea.local gitea
    HOSTNAME gitea.local
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Update

Addendum: Friend of mine reported, gitea will generate a rsa key by default, so it looks like it’s mandatory to generate the keys manually

Apparently ssh-rsa host key algorithm (and apparently also the signature algorithm) was declared deprecation a year ago and it finally has an effect.

Also to add insult to injury, it seems like gitea’s internal ssh server is hard-coded to only generate ssh-rsa keys so I can’t easily force it into rsa-sha2-* or other key types/algorithms, and the easiest workaround seems to be enabling ssh-rsa back as @nougad suggested.

For people looking for a workaround way to fix this on their server without people having to make changes to ~/.ssh/config on the client end: If you manually generate and ED25519 keypair ssh-keygen -t ed25519 and reference them with the SSH_SERVER_HOST_KEYS setting in app.ini it will force a better signature algorithm based on said key type.

IMO, it’s worth looking at moving to ED25519 or another elliptic curve algorithm as the default for Gitea, as RSA is getting closer to being totally broken all the time.

I’m having the same issue as @synaptiko above. Adding HostkeyAlgorithms ssh-rsa to my ~/.ssh/config for the host fixed the host key type problem, but my keys don’t work. Seems like the internal ssh server just isn’t working as it used to.

EDIT: Turns out I’m running gitea 1.14.5, so nevermind, I should probably be running the freshest code before complaining 😄 Worked around it personally by just switching to the system’s ssh server instead of gitea’s internal one.

My company’s entire ed25519 keys stopped working lmao Why is everything set to RSA? it’s not 2010…

<del>>SSH_SERVER_HOST_KEYS: ssh/gitea.rsa, ssh/gogs.rsa: For the built-in SSH server, choose the keypairs to offer as the host key. The private key should be at SSH_SERVER_HOST_KEY and the public SSH_SERVER_HOST_KEY.pub. Relative paths are made absolute relative to the APP_DATA_PATH. If no key exists a 4096 bit RSA key will be created for you.</del>

<del>uhh what, anyone able to tell me what to do to just get ed25519 keys going? idc about any other ones. </del>

nvm all you need to do is generate a new ed25519 key and set it with SSH_SERVER_HOST_KEYS as the guy above said… can’t believe you guys are using RSA key lmao…

also running the via the binary (not docker) @zeripath but seems you figured it out (using the gitea internal SSH server… I run openSSH server already and have no issues there, as I’ve used ed25519 for several years.)

@dogtopus

he easiest workaround seems to be enabling ssh-rsa back as

The easiest solution is just generating an ed25519 and pointing to it, takes <10 seconds

FWIW to gitea devs https://pkg.go.dev/crypto/ed25519

The easiest solution is just generating an ed25519 and pointing to it, takes <10 seconds

Yes but if you got a bunch of different clients connected to the server it would be a PITA to update them all to use the new public key. Although adding back RSA SHA1 on every machine is not ideal either.

@Poyoman39 the attached PR will solve the issue.

Oh damn - this is going to be annoying and difficult to fix.

Fundamentally there is a problem in the way that Go’s x/crypto/ssh library does the handshake.