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.

[cz_unit]

try ssh bozo.com -l (username) -p

?

C

[rmd.livejournal.com]

-p wants an argument for port number. going to ssh foo -l uname gives me the same response as ssh uname@foo.

[cz_unit]

Oh, maybe the host's sshd process is not including password type as a valid auth. I seem to recall you could screw in a number of authenticators for ssh (and anything) in Solaris, that might be it.

Can you use this client to any other ssh servers with password auth?

C

[rmd.livejournal.com]

yeah, i can ssh everywhere else with it. if it's somewhere that doesn't have my keys, it just reverts to password without a problem. it's just this appliance i have problems with. grar.

a long shot

[drwex]

Is the misbehaving host in your .ssh/known_hosts file? If so, try removing it.

Do you have the ability to originate your SSH connection from more than one source machine? That might let you see if the problem is at the source or the target.

[irilyth]

> debug1: Authentications that can continue: ,password
> A debug1: No more authentication methods to try.

This might imply that it's not going to take password authentication in any case -- the client is saying that it could still try 'password', but the server doesn't want to accept that.

That said, 'ssh -o PreferredAuthentications=password ' will force the client to try. But if the server is configured with 'PasswordAuthentication no' in sshd_config, then you're outta luck no matter what you tell the client to do.

[achinhibitor.livejournal.com]

I'm no expert but assuming you're running the ssh, it can only get the keys from your ~/.ssh/[whichever] file, or from the ssh-agent. You can cut it off from ssh-agent by undefining the SSH_* environment variables it sees. I suspect you can prevent it from seeing your key file by adding "-i /dev/null". The debug message when I try that suggest my ~/.ssh/* files aren't being looked at.

But I'm not sure you're interpreting the situation correctly. When I do "ssh -v", the messages suggest that "Authentications that can continue:" is a message from the sshd end saying what it is willing to accept, then the ssh end picks an auth mechanism from the list that it is willing to do and tries that. Which suggests that either your ssh is choking on ",password" itself, or it doesn't think it can present a password.