Some ssh passwords are not handled correctly

[trichner]

I'm trying to login to my server but it gives me a 'ssh authorization failed' on my password. My server is using the yubi-PAM module for two-factor authentication, it might cause problems, although it only needs a password. Other ssh clients work fine, even the Chrome 'Secure Shell' which is using NaCL.

Since the only output is that it failed, it's pretty hard to pinpoint the problem.

Also, what should 'user' be? only 'user' ? or 'user'@'hostname' ?

Manual login works fine.

[rpwoodbu]

I'm not sure that there's any more information available for me to print. I'd expect it to work OK regardless of what backend authentication you're using. It is known to work with both password auth and interactive auth with multiple prompts (e.g., with the Google Authenticator PAM module). It prints out which auth types the server supports, and shows which one it is attempting to use at the moment; check to see that the auth type is what you expect, and compare with "ssh -v".

The user should just be $USER, and nothing else.

[rpwoodbu]

Actually, there may be some debug info from libssh that could be enabled, similar to "ssh -v". I'll make this a bug to add a way to get that to be output.

[trichner]

Ok, I tested it again with a normal ssh server with password. And I'm still unable to login. Login with 'Secure shell' chrome extension works fine. Can I turn any debug log on?

Console output:

Authentication types supported by server:
 - Password
 - Public Key
Trying authentication type Public Key
No ssh key found.
Trying authentication type Password
Password: 
Password authentication failed: Access denied. Authentication that can continue: publickey,password
ssh authentication failed: Access denied. Authentication that can continue: publickey,password

[rpwoodbu]

@trichner Are you possibly using public key auth with Secure Shell? Double-check that you are really using password auth, and that the password is what you expect.

There's no more logging available in the current version. I'll try to get more logging available soon (more complex to plumb through than you'd think). But don't wait for that; check which auth method you're using with Secure Shell.

[trichner]

I triple checked, I'm now using a vanilla OpenSSH server. Only password, no fancy stuff. Here an (anonymized) trace from a login with 'Secure Shell Extension' and option -vvvv http://pastebin.com/2ukmJzPJ

The only special thing: It runs on a port above 1024. Thanks for your efforts! Mosh looks like a successor of ssh and this extension brings it to chrome OS and windows.

[rpwoodbu]

Interesting. I don't think it is the port number, as the connection is succeeding (evidenced by receiving the list of supported auth types).

My best guess at this point is that there's something in your password that my code doesn't like. Can you try connecting to a test account with a simple password? If that works, see if you can narrow down what specifically makes the password problematic.

[trichner]

You are correct, it is the password, '1234' worked perfectly. Have you escaped @ in passwords?

[rpwoodbu]

Ah, now we're getting somewhere. I'm not doing anything special. Let me do some experimentation.

[rpwoodbu]

I am able to connect with a password containing an '@' and a '\'. I am doing no escaping or anything. Is there anything else that it might be? The code should be able to handle a password as long as 255 characters, unless libssh has a shorter limit.

[trichner]

The password looks like this: 'aphanumeric1234@!alphanumeric1234' It's under 30 chars.

[rpwoodbu]

Well, I set my password to exactly that, and I was still able to connect. Are you not able to if you use that same password?

[rpwoodbu]

I haven't heard from you in a while. Labeling as "wont fix" for now, as I can't reproduce. Please reopen if you have more information.

[daluz]

I have the same issue. Simple password (AaaaaaaBbbbbb1234), and like the first message, the serves uses yubikey pam module.

[rpwoodbu]

Interesting that both of you are using the Yubico PAM module. It is confusing that @trichner was able to connect with a simple "1234" password, whereas you cannot connect with a still rather simple alphanumeric password. I wonder if there was something else going on when @trichner tried "1234". @daluz, can you test with exactly that password and see what happens?

There's one other thing worth mentioning: There is support in Mosh for Chrome to talk to an external agent app, which is then used to talk to a Yubikey. Since Mosh for Chrome doesn't talk to the Yubikey directly, and since you're very unlikely to have that particular agent app installed, I don't see how this could interfere, but it is an interesting coincidence. The upshot is that I have easy access to Yubikeys, so I might be able to reproduce the issue myself.

[daluz]

I'll try to, but the server passwords are behind a security policy that I have no control of. Let me know how I can provide more logs if you need to.

[bshogeman]

Same issue. Is there a way to cleanup the added keys or remove just one? In the Mosh client there only is a add button no remove or edit. :-/

[rpwoodbu]

@bshogeman You can remove an existing key by hitting "save" while the field is blank. https://github.com/rpwoodbu/mosh-chrome/wiki/Key-based-ssh-Authentication

[rpwoodbu]

Did any of you figure out what was happening here? I'm going to unassign for now, but leaving open.