Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I feel pretty dumb asking this but I have been working on this for a couple days now (on and off) and I cannot figure it out. I have just installed lubuntu on my machine and I can ssh locally onto it using localhost and password authentication and I can ping it from two other machines fine. I try to ssh from either of those machines and it continues to fail to authenticate with my password.

I have re-installed openssh-server a couple times and I just cannot seem to figure it out.

Does anyone have a suggestion about what the problem might be?

New Info:

I have created a new user just to make sure it was not user related and the new user could not login either.

Here is the output of ssh -vv cusername@fable:

ssh -vv cusername@fable
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to fable [192.168.1.76] port 22.
debug1: Connection established.
debug1: identity file /home/susername/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/susername/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/susername/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version 1.00
debug1: no match: 1.00
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
debug2: fd 4 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc
debug2: kex_parse_kexinit: aes128-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 506/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'fable' is known and matches the RSA host key.
debug1: Found key in /home/susername/.ssh/known_hosts:3
debug2: bits set: 528/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/susername/.ssh/identity ((nil))
debug2: key: /home/susername/.ssh/id_rsa (0x219e2358)
debug2: key: /home/susername/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/susername/.ssh/identity
debug1: Offering public key: /home/susername/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/susername/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
cusername@fable's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
cusername@fable's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
cusername@fable's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Here is my iptables:

sudo iptables -L
[sudo] password for susername: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination    

Here is my nmap from remote machine to the server in question: nmap -P0 192.168.1.76

Starting Nmap 5.00 ( http://nmap.org ) at 2012-07-24 23:32 CDT
Interesting ports on fable (192.168.1.76):
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 1.58 seconds

cat /etc/ssh/sshd_config

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# 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

Then I copied back the sshd_config.factory-default to sshd_config and had the same issues of it not accepting my password.

UPDATE:

I gave up. It seemed like it was some issue with lubuntu but it was probably something screwy that I did. I ended up installing linux-mint on there instead and everything was working flawlessly. Who knows... I really like linux-mint though!

share|improve this question
    
Do you have an /etc/hosts.allow or /etc/hosts.deny? –  Paul Jul 25 '12 at 4:10
    
ssh -v ... says...? –  Ignacio Vazquez-Abrams Jul 25 '12 at 4:11
    
@Paul: I do have both but both seem to be only comments. Ign: I can put that up but I want to scrub it first. –  stephenmm Jul 25 '12 at 4:14
    
@stephenmm Do you have a firewall running? –  Paul Jul 25 '12 at 4:23
    
I do not believe so but even if I did would it not stop me before trying to authenticate my credentials? –  stephenmm Jul 25 '12 at 4:24
show 3 more comments

1 Answer

up vote 2 down vote accepted

As I can read from your logs, neither firewall nor some hosts.deny -- or you would not have reached the password prompt. But let's analyze your log output.

First, it looks like your identity file needs a replace:

debug1: identity file /home/susername/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'

That's an ASCII armored, exported key -- ssh requires the original binary key instead. But then it seems you have two other valid private key files:

debug1: identity file /home/susername/.ssh/id_rsa type 1
debug1: identity file /home/susername/.ssh/id_dsa type -1

also, the remote host is verified successfully:

debug1: Host 'fable' is known and matches the RSA host key.
debug1: ssh_rsa_verify: signature correct

Next, just one of your private key files is valid:

debug2: key: /home/susername/.ssh/identity ((nil))
debug2: key: /home/susername/.ssh/id_rsa (0x219e2358)
debug2: key: /home/susername/.ssh/id_dsa ((nil))

I already showed what's wrong with the first one. Moreover we see the server did not accept any of the keys -- and thus negotiation falls back to interactive password prompt:

debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/susername/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

And finally:

cusername@fable's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Looks like you provided the wrong password, too.

Summary:

Two invalid private keys are unusable, the third is not accepted by the server -- which throws you back to the interactive password prompt. Your password is not accepted. Are you sure you provided the correct password for the named user on the remote host? Possible mistakes here:

  • provided password is for a different user
  • user and password may match on the local host -- but on the remote host, this user has a different password
  • user does not exist on the remote host

EDIT:

If the login using username/password still fails though you are sure to have provided the correct password, a good idea is to check /var/log/auth.log on the machine you try to login to. This log file should give you more details about what went wrong (all login attempts as well as sudo attempts are logged there).

share|improve this answer
    
First off, thanks for taking the time to look at this really appreciate it. I did not know user/passwd could match on the local but be different on the remote host? I thought that it used the linux credentials to authenticate user/passwd? –  stephenmm Jul 25 '12 at 13:26
    
@stephenmm: How would that help though? That wouldn't prove you were entitled to access the remote machine, just the local one. –  David Schwartz Jul 25 '12 at 13:30
    
Maybe some more details to make it clearer: having multiple machines (say host1 and host2), you could have a user "johndoe" on both of them. On the command line, you create that user with the useradd command. On host1: useradd -p password1 johndoe, on host2 useradd -p password2 johndoe. Now you have the same (local) user on both machines -- but with different passwords. –  Izzy Jul 25 '12 at 14:19
    
Password1 and password2 are different so tonight I can try and change them to be the same just to eliminate a variable but let me clarify what I did; I installed openssh-server on host1 and then from host2 I 'ssh jondoe@host1' then entered password1. Oh and then I kicked host1 in the disk drive. –  stephenmm Jul 25 '12 at 15:28
    
Aside from the kick, that sounds correct and should have worked. You might also want to check with your /var/log/auth.log which might provide additional information on why the login was refused. –  Izzy Jul 25 '12 at 15:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.