> > 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@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@numeric-ip" to see what was different on mine: [guest1@laptop1 ~]$ ssh -vv guest1@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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
