I'm not using hosts.allow
or hosts.deny
, furthermore SSH works from my windows-machine (same laptop, different hard drive) but not my Linux machine.
ssh -vvv root@host -p port
gives:
OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer
On the windows machine, everything works fine, so I checked the security logs and the lines in there are identical, the server treats the two different "machines" no different and they are both allowed via public-key authentication.
So that leads to the conclusion that this must be an issue with my local ArchLinux laptop.. but what?
[torxed@archie ~]$ cat .ssh/known_hosts
[torxed@archie ~]$
So that's not the problem…
[torxed@archie ~]$ sudo iptables -L
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
No conflicts with the firewall settings (for now)..
[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------ 2 torxed users 4096 Sep 3 2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw------- 1 torxed users 1679 Sep 3 2013 id_rsa
-rw-r--r-- 1 torxed users 403 Sep 3 2013 id_rsa.pub
-rw-r--r-- 1 torxed users 170 May 11 11:21 known_hosts
Permissions appear to be fine (same on the server)..
Also tried without configuring /etc/ssh/ssh_config
with the same result except for a lot of auto-configuration going on in the client which ends up with the same error.
Best Answer
Originally posted on Ask Ubuntu
If you have ruled out any "external" factors, the following set of steps usually helps to narrow it down. So while this doesn't directly answer your question, it may help tracking down the error cause.
Troubleshooting
sshd
What I find generally very useful in any such cases is to start
sshd
without letting it daemonize. The problem in my case was that neithersyslog
norauth.log
showed anything meaningful.When I started it from the terminal I got:
Much better! This error message allowed me to see what's wrong and fix it. Neither of the log files contained this output.
NB: at least on Ubuntu the
$(which sshd)
is the best method to satisfysshd
requirement of an absolute path. Otherwise you'll get the following error:sshd re-exec requires execution with an absolute path
. The-p 10222
makessshd
listen on that alternative port, overriding the configuration file - this is so that it doesn't clash with potentially runningsshd
instances. Make sure to choose a free port here.Finally: connect to the alternative port (
ssh -p 10222 user@server
).This method has helped me many many times in finding issues, be it authentication issues or other types. To get really verbose output to
stdout
, use$(which sshd) -Ddddp 10222
(note the addeddd
to increase verbosity). For more debugging goodness checkman sshd
.The main advantage of this method is that it allows you to check the
sshd
configuration without having to restart thesshd
on the default port. Normally this should not interfere with existing SSH-connections, but I've seen it. So this allows one to validate the configuration file prior to - potentially - cutting off ones access to a remote server (for example I have that for some VPS and even for physical servers where I need to pay extra to get out-of-band access to the machine).