Hi:  I have two boxes connected to the same router.  One runs SL7.5, from tomorrow probably SL7.6, which is an el7 clone, and the other runs Fedora 28. I can ssh and rsync from F28 to SL7, but permission is denied in the opposite direction.  Port 22 is open.  I now have copies of both versions of /etc/sshd and intend to examine diffs. Google provides many links but nothing that looks authoritative or, preferably, authoritative and simple.  Any help wpuld be appreciated.

On 03/12/2018 17:30, Rick Stevens wrote: > On 12/3/18 8:15 AM, John Pilkington wrote: >> Hi:  I have two boxes connected to the same router.  One runs SL7.5, >> from tomorrow probably SL7.6, which is an el7 clone, and the other runs >> Fedora 28. >> >> I can ssh and rsync from F28 to SL7, but permission is denied in the >> opposite direction.  Port 22 is open.  I now have copies of both >> versions of /etc/sshd and intend to examine diffs. >> >> Google provides many links but nothing that looks authoritative or, >> preferably, authoritative and simple.  Any help wpuld be appreciated. > > You need to look at the logs or messages when you try to connect from > SL7 to F28 (and F29 is current). > > Odds are that SL7 is using a cipher or an algorithm that is deemed > insecure in the latest sshd implementations at the F28 end and you'll > either need to have sshd on F28 accept it (via a "Ciphers" or > "KexAlgorithms" option in /etc/ssh/sshd_config) or use one of the > acceptable ciphers/algorithms at the client (SL7) end. > > Logs and error messages are your friends in these cases. Thanks Rick.  The SL7.5 to 7.6 upgrade has just completed but 'Connection refused' still.  The only effective diffs between the sshd_configs appeared to be in F28, 'PermitRootLogin yes' and 'PrintMotd no'.  So I'll try to get some more verbose logs.

On 03/12/2018 19:19, Rick Stevens wrote: > On 12/3/18 10:16 AM, John Pilkington wrote: >> On 03/12/2018 17:30, Rick Stevens wrote: >>> On 12/3/18 8:15 AM, John Pilkington wrote: >>>> Hi:  I have two boxes connected to the same router.  One runs SL7.5, >>>> from tomorrow probably SL7.6, which is an el7 clone, and the other >>>> runs >>>> Fedora 28. >>>> >>>> I can ssh and rsync from F28 to SL7, but permission is denied in the >>>> opposite direction.  Port 22 is open.  I now have copies of both >>>> versions of /etc/sshd and intend to examine diffs. >>>> >>>> Google provides many links but nothing that looks authoritative or, >>>> preferably, authoritative and simple.  Any help wpuld be appreciated. >>> >>> You need to look at the logs or messages when you try to connect from >>> SL7 to F28 (and F29 is current). >>> >>> Odds are that SL7 is using a cipher or an algorithm that is deemed >>> insecure in the latest sshd implementations at the F28 end and you'll >>> either need to have sshd on F28 accept it (via a "Ciphers" or >>> "KexAlgorithms" option in /etc/ssh/sshd_config) or use one of the >>> acceptable ciphers/algorithms at the client (SL7) end. >>> >>> Logs and error messages are your friends in these cases. >> >> Thanks Rick.  The SL7.5 to 7.6 upgrade has just completed but >> 'Connection refused' still.  The only effective diffs between the >> sshd_configs appeared to be in F28, 'PermitRootLogin yes' and 'PrintMotd >> no'.  So I'll try to get some more verbose logs. > > "PermitRootLogin yes" is dangerous (allows root to log in via ssh) so > I wouldn't suggest leaving that alone. I'd set it to "no" and restart > sshd ("systemctl restart sshd.service"). You'll need to log in as a non- > root user and "sudo" stuff, but it's safer. > > As to the other stuff, try "ssh -v <hostname-or-addr-of-f28-system>" [john@HP_Box ~]$ ssh -v -v -v john(a)192.168.1.66 OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 58: Applying options for * debug2: resolving "192.168.1.66" port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 192.168.1.66 [192.168.1.66] port 22. debug1: connect to address 192.168.1.66 port 22: Connection refused ssh: connect to host 192.168.1.66 port 22: Connection refused F28 /etc/ssh/ssh_config line 58 is a blank line among lines commented out.

> from the SL client, see what it says and post that. Oh, and make sure > the F28 firewall is permitting incoming TCP port 22 (can't recall if it > does that by default). You can find that by, as root: > >     # firewall-cmd --get-default-zone >     # firewall-cmd --info-zone <value-from-prev-cmd> > > Look for the service "ssh" or something like "22/tcp". On one of my > machines (ssh service marked with "^^^"): > >     [root@prophead ~]# firewall-cmd --get-default-zone >     public >     [root@prophead ~]# firewall-cmd --info-zone public >     public (active) >       target: default >       icmp-block-inversion: no >       interfaces: em1 eno1 >       sources: >       services: dhcpv6-client mdns sane ssh synergy tftp tftp-client >                         ^^^ >       ports: 54925/udp 1900/udp 49152/tcp 514/udp 8200/tcp 514/tcp > 1935/tcp > 161/udp >       protocols: >       masquerade: no >       forward-ports: >       source-ports: >       icmp-blocks: >       rich rules: The zone is 'home', services include ssh; I have other ports (for mythtv) enabled.  No obvious discrepancies. But I was using the firewall-config GUI and got repeated instances of (firewall-config: 28658): Gtk-WARNING**: <time> Failed to set text from markup due to error parsing markup:  Unknown tag 'interface' on line 1 char 20 The 'interface' field in the GUI has enp0s25 Comment: Used by network connection xxxxxxx

ssh -v -v -v user@remote Is often a good command to use. It tells you everything it is trying so you can see what all it failed on. I've never had any problems with CentOS 7 and new fedora systems though. They talk to each other just fine for me. Some very very old systems are trying to use deprecated ciphers, but nothing as old as el7 and f28.

I can ssh and rsync from F28 to SL7, but permission is denied in the opposite direction.  Port 22 is open.  I now have copies of both versions of /etc/sshd and intend to examine diffs.

'systemctl start sshd'  and 'ssh john(a)192.168.1.66&#39; gives me the expected prompt.