Hi, I needed to do the CLI changes to SSH to address audit vulnerabilities. I was able to change settings, but not the KEX protocol. This key exchange protocol can't be changed until 9.0. Palo says they have a fix for the rebooting issue. Unfortunately, their fix was to use a new OS, which wasn't in the cards for us. Then, it occurred to me how we might fix this. We normally disable telnet, and use SSH, as I expect most people do. The problem, according to Palo, was the PA220 (and perhaps 200) only had one key for SSH because that made reboots faster (see below). I believe it was that I was using SSH when I restarted the service that was an issue. A reboot was need to recreate the SSH key. The reboot was forced because the existing SSH session couldn't find a good SSH key, so the service tried to restart 6 times or so, then forced the reboot when the service failed to start. So, what I decided to do was enable telnet, then telnet into our 220s, exit any SSH sessions, apply the SSH CLI changes, commit them, then restart the SSH service. I could then SSH into the units with the new SSH settings. I then disabled telnet again. This seems to restart the service OK and not reboot. This issue isn't a problem with the PA500 and above (like our 5220s), because they all have multiple SSH keys. So try this on one of your firewalls, and see how it goes! Regards, Larry See the info from my ticket: ------------------------- "Our Engineering team has an update on the Root cause of the issue. sshd_config file has a list of sshd keys that the daemon needs to start with. The list of keys are read from the config file and those file are then read from the filesystem In 8.0 and earlier 8.1 releases slower platforms like 200, 500 and 800 series used to start sshd service with 6 keys). But we later realized that this was slowing the login in time. So in some maintenance release of 8.1 we reduced the number of keys from 6 to 1. This increased the log in times for all the slower platforms noticeably. When we upgraded from earlier version having 6 keys to a newer version having just 1 key what happened was that the remaining 5 keys were never deleted from cryptod keystore. Having 5 keys in cryptod and never using them is not an issue in itself. But the problem happened when we changed the default host key. Now, the code that does all this changes checked if the new default host key (ecdsa 256 in this case) was present in cryptod and since it was present, it did not generate that key, and more importantly it did not create a key file which sshd daemon reads during startup. So what happened was that when sshd tried to start it could not find any keys to start with and did not start. That's why it kept on failing and after trying few times, the device rebooted. When the device rebooted, a script that checks ssh keys in cryptod and adds the correct key files to filesystem ran and it added all that was necessary for sshd daemon to start. That's why sshd started properly after reboot. We have a fix for this and it should resolve this issue from happening in future." --------------------
... View more