can't connect anymore with known_hosts=None after fe757eae9fb1df5002 #263
Comments
sanga
changed the title
|
Can you get any logs from the Dropbear server to see if it is reporting an error? Also, can you increase the debug level to 2 and grab the logs from the client? The commands for that would be something like: import logging
logging.basicConfig(level='DEBUG')
asyncssh.set_debug_level(2) |
|
asyncssh logs: against v2.1.0 against v2.2.0 So it looks like it bails out during key-exchange. At a glance I didn't spot differences there... |
|
dropbear logs thusly: So |
|
Thank you for the additional info! The "No matching algo hostkey" is definitely interesting. Looking at the two host key lists, v2.2.0 is a strict superset of 2.1.0, adding the following algorithms: So, if the Dropbear server found a match in v2.1.0, it should also be able to find a match in the v2.2.0 case. However, I wonder if perhaps the problem could be related to the length of the host key algorithm list. With the added algorithms, the length of the list is 579 bytes in v.2.2.0 vs. 437 bytes in v2.1.0. Perhaps DropBear has a length limit on that. In the connect() call, could you try setting server_host_key_algs=['ssh-ed25519-cert-v01@openssh.com', 'ssh-ed448-cert-v01@openssh.com', 'ecdsa-sha2-nistp521-cert-v01@openssh.com', 'ecdsa-sha2-nistp384-cert-v01@openssh.com', 'ecdsa-sha2-nistp256-cert-v01@openssh.com', 'ecdsa-sha2-1.3.132.0.10-cert-v01@openssh.com', 'ssh-rsa-cert-v01@openssh.com', 'ssh-dss-cert-v01@openssh.com', 'ssh-ed25519', 'ssh-ed448', 'ecdsa-sha2-nistp521', 'ecdsa-sha2-nistp384', 'ecdsa-sha2-nistp256', 'ecdsa-sha2-1.3.132.0.10', 'rsa-sha2-256', 'rsa-sha2-512', 'ssh-rsa', 'ssh-dss']This is the list from v2.1.0. If that works, it might also be interesting to try: server_host_key_algs=['ssh-rsa',' sk-ssh-ed25519-cert-v01@openssh.com', 'sk-ecdsa-sha2-nistp256-cert-v01@openssh.com', 'ssh-ed25519-cert-v01@openssh.com', 'ssh-ed448-cert-v01@openssh.com', 'ecdsa-sha2-nistp521-cert-v01@openssh.com', 'ecdsa-sha2-nistp384-cert-v01@openssh.com', 'ecdsa-sha2-nistp256-cert-v01@openssh.com', 'ecdsa-sha2-1.3.132.0.10-cert-v01@openssh.com', 'ssh-rsa-cert-v01@openssh.com', 'ssh-dss-cert-v01@openssh.com', 'sk-ssh-ed25519@openssh.com', 'sk-ecdsa-sha2-nistp256@openssh.com', 'ssh-ed25519', 'ssh-ed448', 'ecdsa-sha2-nistp521', 'ecdsa-sha2-nistp384', 'ecdsa-sha2-nistp256', 'ecdsa-sha2-1.3.132.0.10', 'rsa-sha2-256', 'rsa-sha2-512', 'ssh-dss']This is the full list from v2.2.0, but with 'ssh-rsa' moved to the front. I don't know if this would help or not if it is a buffer length issue, but it'd be an interesting data point. |
|
I dug around a bit in the Dropbear source, and I think I may have found the issue. The buf_match_algo() function has some limits on both the number of proposed algorithms and the maximum name length of each algorithm. While the name length is ok (up to 64 bytes per algo name), the limit on the maximum proposed algorithms is 20 in sysoptions.h: #define MAX_PROPOSED_ALGO 20This is later used in but_match_algo() in common-also.c and it looks like anything beyond the first 20 algorithms might not be matched, as they don't fit in the fixed-size array it allocates: algo_type * buf_match_algo(buffer* buf, algo_type localalgos[],
enum kexguess2_used *kexguess2, int *goodguess)
{
char * algolist = NULL;
const char *remotenames[MAX_PROPOSED_ALGO], *localnames[MAX_PROPOSED_ALGO];
unsigned int len;
unsigned int remotecount, localcount, clicount, servcount, i, j;
algo_type * ret = NULL;
const char **clinames, **servnames;
if (goodguess) {
*goodguess = 0;
}
/* get the comma-separated list from the buffer ie "algo1,algo2,algo3" */
algolist = buf_getstring(buf, &len);
TRACE(("buf_match_algo: %s", algolist))
if (len > MAX_PROPOSED_ALGO*(MAX_NAME_LEN+1)) {
goto out;
}
/* remotenames will contain a list of the strings parsed out */
/* We will have at least one string (even if it's just "") */
remotenames[0] = algolist;
remotecount = 1;
for (i = 0; i < len; i++) {
if (algolist[i] == '\0') {
/* someone is trying something strange */
goto out;
}
if (algolist[i] == ',') {
algolist[i] = '\0';
remotenames[remotecount] = &algolist[i+1];
remotecount++;
}
if (remotecount >= MAX_PROPOSED_ALGO) {
break;
}
}
...
}The overall buffer length check is ok, because 20*(64+1) is 1300 bytes, which is bigger than what AsyncSSH is sending. However, the full list of algorithms in v2.2.0 is now 22, meaning the 'ssh-rsa' and 'ssh-dss' are beyond the 20 algorithms that Dropbear is willing to match against. I'm guessing that moving ssh-rsa earlier in the list will help, as would reducing the list of algorithms that AsyncSSH sends. On the Dropbear side, increasing MAX_PROPOSED_ALGO would also be a pretty simple fix for this. |
|
Thanks for the thorough investigation! Certainly looks like that's the issue. For the record against Dropbear all of the following work: So apparently just moving |
|
Great - thanks for the confirmation! Unfortunately, unless I introduced code which checks the peer's version string to see if it is a Dropbear server and re-orders the host key algs, it'll be difficult to automatically work around this AsyncSSH side. I think explicitly specifying server_host_key_algs might be your best bet in this case. Alternately, it looks like Dropbear understands ECDSA algorithms and those are earlier in the list. So, you might not see this issue when the Dropbear server is using an EC host key instead of an RSA one. |
|
Thanks, I wound up solving this by setting |
minimum failing example I could come up with is opening ipython and running the following:
I bisected this down to fe757ea So apparently something in that commit introduced this.
Not sure it's relevant but this is against
Dropbear server v2017.75The text was updated successfully, but these errors were encountered: