ssh wont accept passwords

investmentbnker75 · 10-18-2008, 11:43 AM

All,

I have two servers, server a and b. I have generated keys and put them on in the user directory on each server, opened the firewall rules to allow on port 22 made sure the permissions on both sides are correct, etc...

When i go from server a to server b, it looks normal and prompts me for a password the first time i try to log in to copy my public keys to server b for passwordless authentification, but when i put in the correct password for the user, it just asks for the password over and pver and wont accept the password. Can anyone tell me what needs to be done so i can log in?

Ive also added an entry in sudoers for ALL for the userid and made sure sshd allows for all in /etc/hosts.allow, with nothing in /etc/hosts.deny. Im stumped. Below is the ssh -v output:

ssh -v xxx.xxx.xxx.xxx (Server A's IP)

OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/userid/.ssh/identity type -1
debug1: identity file /home/userid/.ssh/id_rsa type 1
debug1: identity file /home/userid/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version SSHD
debug1: no match: SSHD
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/userid/.ssh/known_hosts:3
debug1: ssh_rsa_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: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/userid/.ssh/identity
debug1: Offering public key: /home/userid/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /home/userid/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password Authentication
Password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Password Authentication
Password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Password Authentication
Password:

anomie · 10-18-2008, 01:23 PM

Quote:

Originally Posted by investmentbnker75

When i go from server a to server b, it looks normal and prompts me for a password the first time i try to log in to copy my public keys to server b for passwordless authentification, but when i put in the correct password for the user, it just asks for the password over and pver and wont accept the password.

Open up a terminal on server b and run # tail -f /var/log/secure

Now try to log in from server a to server b again. Post the output from /var/log/secure here.

investmentbnker75 · 10-18-2008, 01:40 PM

Weird it says it accepted my password, but it doesnt let me login.

Oct 18 20:26:42 servername sshd[12]: Accepted password for userid from ::ffff:xxx.xxx.xxx.xxx port 2019 ssh2

anomie · 10-18-2008, 03:38 PM

Hmm, brainstorming...

Check the results of grep your_user /etc/passwd -- is it a valid home directory and valid shell? Do they both exist? Is the filesytem /home is mounted to full perchance?
Have you explicitly made any changes to your PAM settings?
Did you create the file /etc/nologin?
Finally, who is the user you're trying to login as? Is it root? (Because that opens another can of worms / things to check.)

If there is anything else that showed up while watching /var/log/secure that you didn't post, be sure to post it.

---

P.S. If none of this helps solve the problem, log in to a terminal on server b as root and run # passwd your_user

Then set the user's password again. Maybe you locked the account and forgot.

investmentbnker75 · 10-18-2008, 07:17 PM

In regards to /etc/passwd, the login is a valid directory and has a valid shell, /bin/bash.

No changes have been made to PAM, i did make sure setting in ssh_config and sshd_config do allow for RSA auth.

No, im not trying to log in as root. The user im logging in as has a setting in sudoers as ALL.

Ive reset the password a few times, still not working.

In regards to /etc/nologin, it doesnt exist, but it doesnt exist on any server where i dont have the problem. So...

What a head scratcher.

anomie · 10-18-2008, 07:45 PM

First a tangent: Are you really trying to use RSA authentication? That requires ssh protocol v1, which is a no-no unless you have no other option. You should be using ChallengeResponseAuthentication (w/ UsePAM yes); if there's a reason for your specific setup, please 'splain.

Another tangent: your sudoers setup has nothing to do with your sshd problem.

---

At this point what I'd suggest doing is cranking up the logging verbosity for sshd and observing /var/log/secure again.

Add to /etc/ssh/sshd_config:
LogLevel DEBUG

Then # service sshd reload

... then, attempt your login again and watch that log file.

investmentbnker75 · 10-18-2008, 08:04 PM

Ok followed your steps, heres what the tail shows:

Oct 18 01:58:15 serverA sshd[2525]: debug1: Bind to port 22 on ::.
Oct 18 01:58:15 serverA sshd[2525]: Server listening on :: port 22.
Oct 18 01:58:15 serverA sshd[2525]: debug1: Bind to port 22 on 0.0.0.0.
Oct 18 01:58:15 serverA sshd[2525]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.

Ive set ChallengeResponseAuthentication to yes.

sudoers was just mentioned to cover all bases, you never know.

Thanks!

anomie · 10-18-2008, 09:32 PM

Didn't you say you were trying to login from server a to server b? That output you posted looks like it's from server a (which we do not need right now).

On server b, change to DEBUG, reload sshd, tail the file, and try logging in from server a. (That's the output that will tell us something useful...)

investmentbnker75 · 10-18-2008, 10:04 PM

Just a typo, i meant server b. Sorry

investmentbnker75 · 10-30-2008, 10:18 PM

BUMP just checking if anyone is still there

jschiwal · 10-30-2008, 10:36 PM

Quote:

Originally Posted by anomie

First a tangent: Are you really trying to use RSA authentication? That requires ssh protocol v1, which is a no-no unless you have no other option. You should be using ChallengeResponseAuthentication (w/ UsePAM yes); if there's a reason for your specific setup, please 'splain.

Another tangent: your sudoers setup has nothing to do with your sshd problem.

---

At this point what I'd suggest doing is cranking up the logging verbosity for sshd and observing /var/log/secure again.

Add to /etc/ssh/sshd_config:
LogLevel DEBUG

Then # service sshd reload

... then, attempt your login again and watch that log file.

I don't believe that is correct. Read the comments in the /etc/sshd_config file:

Code:

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Protocol 2
...
# Authentication:

PermitRootLogin no
#RSAAuthentication yes
PubkeyAuthentication yes

For public key authentication, you disable ChallengeResponseAuthentication because you want to use the public key.

[code]

anomie · 10-30-2008, 11:50 PM

@jschiwal:

From sshd_config(5):

Quote:

RSAAuthentication
Specifies whether pure RSA authentication is allowed. The
default is “yes”. This option applies to protocol version 1
only.

I don't understand your reply at all.

---

@investmentbnker75:

Enable DEBUG output and try the login again... Still waiting to see your results.

jschiwal · 10-31-2008, 02:14 AM

My point is to use Public Key authentication. You can have an RSA key pair allowing protocol 2 only.

Quote:

You should be using ChallengeResponseAuthentication (w/ UsePAM yes)

I would say "You should be using "PubKeyAuthentication". I don't think the OP has added his public key to the ~/.ssh/authorized_keys file. Using PAM for authentication allows brute force attack attempts.

Using Public Key authentication, you will be prompted for a the key's passphrase, but this is to unlock the private key on the client side.

Another thing to check is the permissions of the $HOME/.ssh/ and $HOME directories.

anomie · 10-31-2008, 06:55 AM

I don't think OP has any authentication method working yet. I am waiting to see sshd DEBUG output that captures a login attempt.

If the end game here is pubkey authentication (which he has not said), then perhaps he should physically distribute keys via a usb drive or cd rom and skip getting any other form of authentication working.

jschiwal · 10-31-2008, 05:12 PM

I have no idea where the "angry" icon came from in post #11. I removed it. Sorry if it caused any offense.