router anomoly

[Jim Lewis]

>
> On 02/06/2015 08:25 PM, Ed Greshko wrote:
>> On 02/07/15 11:14, Geoffrey Leach wrote:
>>> Turns out that I can't ssh to the other F21 system, so we can confine
>>> the analysis to F21.  So here's the ssh output from ssh to that that
>>> system.
>>>
>>> geoff at puget[38]->ssh -vv webster
>>> OpenSSH_6.6.1, OpenSSL 1.0.1k-fips 8 Jan 2015
>>> debug1: Reading configuration data /etc/ssh/ssh_config
>>> debug1: /etc/ssh/ssh_config line 56: Applying options for *
>>> debug2: ssh_connect: needpriv 0
>>> debug1: Connecting to webster [192.168.10.5] port 22.
>>> debug1: Connection established.
>>> debug1: identity file /home/geoff/.ssh/id_rsa type 1
>>> debug1: identity file /home/geoff/.ssh/id_rsa-cert type -1
>>> debug1: identity file /home/geoff/.ssh/id_dsa type -1
>>> debug1: identity file /home/geoff/.ssh/id_dsa-cert type -1
>>> debug1: identity file /home/geoff/.ssh/id_ecdsa type -1
>>> debug1: identity file /home/geoff/.ssh/id_ecdsa-cert type -1
>>> debug1: identity file /home/geoff/.ssh/id_ed25519 type -1
>>> debug1: identity file /home/geoff/.ssh/id_ed25519-cert type -1
>>> debug1: Enabling compatibility mode for protocol 2.0
>>> debug1: Local version string SSH-2.0-OpenSSH_6.6.1
>>> ssh_exchange_identification: read: Connection reset by peer
>>>
>>> WRT the other questions.
>>>
>>> Yes, I did mean /etc/hosts.allow and /etc/hosts.deny
>> OK, those files are empty on "webster"
>>
>> Have you tried using "webster's" IP address?
>>
>>> sshd logs? I can't find any.
>> On the server side, "webster" ....
>>
>> journalctl -b -0 -u sshd
>>
> Hi Ed,
> Does the ssh Server need to resolve client hostname and ip
> address so that name resolves to the incoming request's ip address?
> And if it is not able to resolve, then it drops the connection?
>

  I am going to jump in here as I should probably know how to fix stuff
like this. Try this (some have been already mentioned):

-  Use the numeric IP instead of webster.

- I am assuming the user name is the same on both ends, but put it anyway
just to humor me.

- If you have an authorized_keys file on the server (in $HOME/.ssh)
temporarily move it to somewhere else.

- Can each machine ping the other?


  I just did an experiment on my network. Using my two Fedora 21 systems I
ran "ssh -vv user at numeric-ip" to see what was different on mine:

[guest1 at laptop1 ~]$ ssh -vv guest1 at 192.168.1.24
OpenSSH_6.6.1, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 51: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.24 [192.168.1.24] port 22.
debug1: Connection established.
debug1: identity file /home/guest1/.ssh/id_rsa type -1
debug1: identity file /home/guest1/.ssh/id_rsa-cert type -1
debug1: identity file /home/guest1/.ssh/id_dsa type -1
debug1: identity file /home/guest1/.ssh/id_dsa-cert type -1
debug1: identity file /home/guest1/.ssh/id_ecdsa type -1
debug1: identity file /home/guest1/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/guest1/.ssh/id_ed25519 type -1
debug1: identity file /home/guest1/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000


   The second to last line is different on mine. I believe this means that
either the server couldn't send a response or the client couldn't
receive it. I think "Connection reset by peer" means the client didn't
like where this was going and shut it down. Maybe tcpdump could be used
to check this.


Jim Lewis