ask ssh lj

[rmd]

so, when I try to ssh to a certain host, it fails with the message "Permission denied (,password)." Here's the tail end of the ssh -v of the connection:

debug1: Found key in /home/regis/.ssh/known_hosts:156
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: ,password
debug1: No more authentication methods to try.

How do I force ssh to use password authentication and to not try to use my ssh keys?

Comments

[adb-jaeger.livejournal.com]

That trace looks odd to me, especially this line:

debug1: Authentications that can continue: ,password

I don't think the comma should be there.

Preliminary googling comes up with pointers to this bug (http://thr3ads.net/openssh-bugs/2007/09/1164454-Bug-1361-New-ssh-should-handle-leading-comma-in-authentication-method-list), which seems rather old, but maybe you're hitting something similar.

Or maybe you just need to tweak the sshd config files on the server you're trying to connect to.

Good luck!

[rmd.livejournal.com]

it's an appliance, unfortunately. it works fine from a host where i don't have an ssh authentication agent running, too. i'm just not sure how to tell ssh 'don't present any crypto auth credentials, just wait til it asks for my password'

[adb-jaeger.livejournal.com]

Maybe the difference on that other host (where you're not running the auth agent) isn't the auth agent, but that host has the bug fixed?

I'm thinking that's still your problem: the reply ",password" is not valid. And since that's coming *from* the appliance, you can't change that.

So you need to make sure the client you're using to connect can deal with that non-standard list in a sane way.

[rmd.livejournal.com]

hm. possibly. i don't see anyone bitching about this on the vendor forums, tho. although it is running an older version of code.

[charleshaynes.livejournal.com]

I think jaeger is right, what does ssh -v look like when you connect to a known good host using password auth (and if you can, compare three cases. Host that only accepts password auth and not publickey. Host that accepts publickey and password but for which you don't have a publickey set, host that accepts both publickey and password but for which you pass the wrong publickey)

I blame the host passing back ",password" until proven otherwise, which means you can "fix" it by hacking your client if you're so inclined.

[rmd.livejournal.com]

Yeah. It looks like putty and securecrt are just clever (or maybe oblivious) enough to not get offended by the ",password"

Bah. Frickin computers.

[achinhibitor.livejournal.com]

How does the ssh -v on the host which can connect look?

[achinhibitor.livejournal.com]

Looking at the above-referenced bug report, I see:

Note there's no prompt for a password. The problem is that the
appliance is sending a leading comma in the list of authentication
method names in the userauth response, and ssh isn't recognising the
"password" method.

That is, the sshd is (somewhat incorrectly) putting a comma at the beginning of the auth methods list, and the ssh is then not parsing it as allowing "password".

Since you can't update the appliance, you've got to get an ssh that you can log in from that handles this particular problem.