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.
John P
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. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "Hello. My PID is Inigo Montoya. You `kill -9'-ed my parent - - process. Prepare to vi." - ----------------------------------------------------------------------
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 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>" 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: ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "Men occasionally stumble over the truth, but most of them pick" - - themselves up and hurry off as if nothing had happened." - - -- Winston Churchill - ----------------------------------------------------------------------
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@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
On 12/3/18 1:07 PM, John Pilkington wrote:
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@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.
Ok, the "connection refused" bit indicates that sshd isn't running. Run "sudo systemctl enable sshd.service" to enable it to start at boot, and "sudo systemctl start sshd.service" to start it immediately.
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
Yeah, if you see "ssh" and/or "22/tcp" then the firewall is open for incoming ssh connections. Do the "systemctl" stuff above and try again. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - The world is coming to an end ... SAVE YOUR FILES!!! - ----------------------------------------------------------------------
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.
On 12/3/18 11:46 AM, Tom Horsley wrote:
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 tend to agree, Tom, but the command you suggest is quite telling. It's also possible that the firewall on the F28 machine isn't allowing incoming ssh. I can't remember if it's blocked by default or not, which is why I suggested also checking the firewall config. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "Yeah, but you're taking the universe out of context." - ----------------------------------------------------------------------
On 12/3/18 2:47 PM, Tom Horsley wrote:
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.
This pretty much the same here, it just works. However once I did see this behavior and it was traceable to incorrect permissions on $HOME/.ssh I never did figure out how they got changed from 700 but setting it back fixed the situation. Don't know if that applies here, but.... HTH
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 12/3/18 8:15 AM, John Pilkington wrote:
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.
We would need the exact error message to give you a good answer. However, if you're using Workstation, ssh is disabled by default. Try running "sudo systemctl enable --now sshd" and see if that solves your problem.
On 03/12/2018 20:08, Samuel Sieb wrote:
On 12/3/18 8:15 AM, John Pilkington wrote:
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.
We would need the exact error message to give you a good answer. However, if you're using Workstation, ssh is disabled by default. Try running "sudo systemctl enable --now sshd" and see if that solves your problem.
'systemctl status sshd' showed it disabled, vendor preset: enabled.
'systemctl start sshd' and 'ssh john@192.168.1.66' gives me the expected prompt.
I suppose I must have done that some time ago, for reasons now forgotten. Apologies to all and thanks for the help.
John
On 12/3/18 1:25 PM, John Pilkington wrote:
'systemctl start sshd' and 'ssh john@192.168.1.66' gives me the expected prompt.
Make sure you do "systemctl enable sshd" as well if you want to be able to use it after your next reboot. "systemctl enable --now" is a shortcut to enable and start the service at the same time.
On 03/12/2018 23:12, Samuel Sieb wrote:
On 12/3/18 1:25 PM, John Pilkington wrote:
'systemctl start sshd' and 'ssh john@192.168.1.66' gives me the expected prompt.
Make sure you do "systemctl enable sshd" as well if you want to be able to use it after your next reboot. "systemctl enable --now" is a shortcut to enable and start the service at the same time.
Yes, thanks. I have reenabled it and will check (ie verify) after the next boot.
-
John Pilkington -
Rick Stevens -
Samuel Sieb -
Tom Horsley -
Wells, Roger K.