SSH connection hangs after ssh-key was accepted.

[ZaxonXP]

I tried the tergent on my android phone. I did follow all the steps and tried to connect using ssh -vv user@myServer. I saw the key was accepted, but I could not log in to the server. When I use my current password protected key I have no problem to log in and see the server welcome message and the command prompt.

How can I diagnose what the problem is and how to solve it?

[aeolwyr]

I would suggest trying the regular ssh-agent (i.e. software backed keys) to test if the server is configured correctly. Make sure you pass the same algorithm (RSA or ECDSA) and bit length to ssh-keygen to minimize the variables.

[ZaxonXP]

I regenerated the same type and length of the key as the one which is working with standard ssh-add and ssh-agent, but it is still hangs after the server accepts the key. Here are two sanitized logs:

This one is from normal ssh-agent authentication: normal.log

This one is from the tergent: tergent.log

Any clues what can try next?

[aeolwyr]

That is interesting, from what I understand at that point the client should be able to create a session. Did you try the suggestions posted here https://serverfault.com/questions/481966?

[luzhkovvv]

Hi! It seems I nailed that issue (at least for my environment).
I'm using dropbear as server (openwrt based router) and dropbear only supports ssh-rsa signature algorithm. The problem is that tergent creates invalid rsa response when using ssh-rsa - response length is calculated using hardcoded algorithm name length - 12 characters, and that's ok for newer 'rsa-sha2-512' (4 example), while "ssh-rsa" is only 7 characters. That causes ssh client to wait for additional 5 bytes from agent (as specified in packet length), but they never come.
Here is cut from ssh strace:

connect(4, {sa_family=AF_UNIX, sun_path="/data/data/com.termux/files/usr/tmp/ssh-P0OkBOjzyP6S/agent.5599"}, 110) = 0
... some interaction skipped
write(2, "debug1: Server accepts key: XXXX"..., 103) = 103
write(2, "debug3: sign_and_send_pubkey: XXXX"..., 86) = 86
write(2, "debug3: sign_and_send_pubkey: signing using ssh-rsa XXXX"..., 104) = 104
write(4, "\0\0\2\227", 4)               = 4
write(4, "\r\0\0\1\27\0\0\0\7ssh-rsa\0\0\0\3\1\0\1\0\0\1\1\0\256\234J\262\277zX\352\321\270%\313\r\365D\"\2i\274\f\362Pt\324\266h?N@\355O\247\270\306H\27"..., 663) = 663
read(4, "\0\0\1\31", 4)                 = 4
| 00000  00 00 01 19                                       ....             |
read(4, "\16\0\0\1\24\0\0\0\fssh-rsa\0\0\1\0\213\2J\354\214\246\344\370jD\360\321\32's\0Q]MY\230E\217\16V\377\20O\21-\350\24n\273\213sA\257\304\342\342a\217?"..., 281) = 276
... dump skipped
read(4, 0x7fcf85055c, 5)                = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++

We can see that ssh reads message length and gets 0x00000119=281, than tries to read 281 bytes, but only gets 276, starts new read to get last 5 bytes and waits indefinitely.

It seems to be pretty easy fix around

tergent/src/sign/response.rs

Line 17 in 34d7d54

stream.write_u32::<BE>(length + 25)?;

and

tergent/src/sign/response.rs

Line 21 in 34d7d54

stream.write_u32::<BE>(length + 20)?;

but I don't have and experience in RUST or Android development :)
Hoping for some fix :)

PS: I know that OpenSSH just issued warning about ssh-rsa being depreceted in future releases, but updates come slowly to embeded devices, and even upstream dropbear has not yet published version with newer algorithms support, so we can assume ssh-rsa is going to be in use at least for a while.

[ZaxonXP]

@luzhkovvv: Well, I am impressed... :)

[micsuka]

I'm facing a similar issue:
(tergent 0.1.1, ssh 8.3p1, server ssh version: 7.4p1 running on debian 9).
it hangs when I'm trying to ssh through tergent, but it works with normal ssh-agent. Attached the 2 logs.

other ssh server versions (I tried 7.9p1-10+deb10u2 and 8.0p1) work.

tergent.log
sshagent.log

[aeolwyr]

Hello, sorry for the late reply. @luzhkovvv thanks for the great investigation!

Since then I have implemented #4, so those hardcoded values are now gone. ssh-agent protocol was unmaintable because of issues like this and more, and now tergent has a more robust cryptoki interface.

See release 1.0 page here. Please note that if you wish to upgrade, you will need to follow the README as you'll need to generate new keys.

I don't have a way to replicate this issue on my end so hopefully this release should solve that problem too.