1

First of all, I'm sorry if there is a duplicate post somewhere. I searched for a while but none of the posts I found fixed my problem.

It's fairly annoying. I created a new VM on our network and when using virt-manager I can log into the VM fine with the username and password. When I try to ssh to the VM from anywhere else it rejects the password, but I know the password is correct. I've even changed it multiple times to make sure its correct.

The address I'm ssh'ing to is definitely pointing at the right VM as well, I've tested all this.

It's still usable, but the virt-manager console is very limited so the sooner I can get to the bottom of this the better. VM is running ubuntu 12.04 btw.

EDIT 1 Checked the auth.log and all I'm getting is "sshd[29304]:Connection closed by 'server.ip.address' [preauth]". I also tried allowing logging in as root, and even turned off password auth altogether in sshd_config and still nothing! I then turned on "AllowEmptyPasswords", still a whole lot of nothing.

3 Answers3

0

virt-manager connects to the console - this is very different from an ssh connection. You didn't tell us anything about the VM - but have have flagged this as Ubuntu. Is that the hypervisor or the VM?

You say it "rejects the password" - but omitted to provide the details of what happened / any error message. This is the single most important thing to do when seeking a solution to a problem - describe what happenend - not your interpretation of events. Your description implies that a TCP connection was established and that authentication failed. Ignoring this for now...

First thing to do is to try pinging the address. If you don't get a reply you have a routing or firewall issue. If you do get a reply it doesn't mean that your packets are being sent to the right place - but we'll come back to that later.

Next try a TCP connection to port 22. From Linux, I would use nc -zv $HOSTNAME 22 for this. If it times out, there is no service listening at that port number, or there is a firewall between your client and the server.

If it does connect, then the next step would be to try ssh -vv $USER@$HOST. If authentication fails, then you may have been connected to the wrong host or the ssh server may be configured to NOT accept password authentication. If you connected to the right host, there will be an entry in the authentication log saying so.

I'll assume that the ssh server is openssh - but you should check using the package manager on the VM what software is installed.

If that log entry is there, then check that the sshd_config has "PasswordAUthentication yes" in the config file (this should be the default if it has been commented out).

If that is the case, then there's something wrong with PAM stack. Try asking again with the output of ssh -vv and the sshd_config.

symcbean
  • 21,009
  • 1
  • 31
  • 52
0

I would recommend, assuming there is no firewall between you and the server, using the virt-manager console to run an sshd (in debug mode) on a different port.

This will allow you to see a more complete log of the connection, including why it refused to let you in:

 `which sshd` -d -p 27 

(The use of backticks t find the sshd is just me being lazy - the whole path needs to be specified for modern OpenSSH)

The output will be something like:

# `which sshd` -d -p 27
debug1: sshd version OpenSSH_6.0p1 Debian-3ubuntu1
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: read PEM private key done: type ECDSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='27'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 27 on 0.0.0.0.
Server listening on 0.0.0.0 port 27.
debug1: Bind to port 27 on ::.
Server listening on :: port 27.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 172.17.172.42 port 52877
Bad protocol version identification '' from 172.17.172.42

This was the log when I used telnet to connect and just hit return to close the connection - you should get a more complete error. I

Graham
  • 1
  • 1
0

Try to make sure you are using the correct username. ssh rejects correct password even when the real issue is incorrectness of username.

Willa
  • 101
  • 2