search

rpwoodbu / mosh-chrome

Mosh for Chrome
GNU General Public License v3.0
372 stars 59 forks source link

Failure to examine libssh2_userauth_authenticated leads to failure to use "none" authentication. #156

Closed MakeItGreatAgain closed 7 years ago

MakeItGreatAgain commented 7 years ago

per the libssh2 docs: https://www.libssh2.org/libssh2_userauth_list.html:

"Send a SSH_USERAUTH_NONE request to the remote host. Unless the remote host is configured to accept none as a viable authentication scheme (unlikely), it will return SSH_USERAUTH_FAILURE along with a listing of what authentication schemes it does support. In the unlikely event that none authentication succeeds, this method with return NULL. This case may be distinguished from a failing case by examining libssh2_userauth_authenticated."

The chrome-mosh code never does this check, thus "none" authentication is broken. This can be confirmed by attempting to connect to my public Multics host (mosh dps8@m.trnsz.com):

Authentication types supported by server: Failed to get authentication types:

This will succeed as expected in Prompt, Reflection, PuTTY, and OpenSSH, but fails in mosh-chrome and blinksh mosh/ssh due to the same bug of never checking libssh2_userauth_authenticated.

MakeItGreatAgain commented 7 years ago

Note: Edited original issue to include test case of mosh dps8@m.trnsz.com

rpwoodbu commented 7 years ago

Well, Mosh for Chrome uses libssh, not libssh2. However, it too exhibits similar behavior, with slightly different semantics. I even acknowledge that this doesn't work right in a comment here.

This shouldn't be terribly hard to fix. I think ssh::Session::GetAuthenticationTypes() could just return SSH_AUTH_METHOD_NONE (which would need to be added as kNone to ssh::AuthenticationTypes (and this would be a good opportunity to switch to a scoped enum), and handled in a few places like ssh::GetAuthenticationTypeName()) when it gets back SSH_AUTH_SUCCESS from ssh_userauth_none(), then handle that in SSHLogin::Start().