About Ambidexter6

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

Hi,   Thanks for the reply!   I would I COULDN'T get it to happen!   I've changed about 50 of our 60 firewalls over the last few days. They all do it, except in two cases the restart seemed to happen but it just left the SSH process inaccessible - so I had to reboot it! 😄     In one case, it seemed the process didn't need to be restarted...after a day or so, it seemed to not have any issue and the changes were in place. But a 2% success rate isn't a good thing...especially since I (nor Palo) can explain why one worked and 2 killed the SSH process.   I also just don't get why there's no way to restart the process or push the SSH changes via Panorama. It just doesn't make sense. How is that "next generation"? It sounds more like "last century"! And there's no version of 8.x.x. that will allow me to change the Key Exchange protocol? I need 9.0 or 9.1? That's just idiotic. I just upgraded all of these to 8.1.13 like 2 months ago, so we're not going to 9.x!   I have a HA pair of 5520s and a single 5520 which I'll try this on. It may work, or totally crash. It's anyone's guess! Cheers, Ambi ... View more

I have, thanks. It does work, except i need 9.0 or 9.1 to enable the KEX algorithms to be selected manually, to remove sha1.   My question is now, that I have a number of changes to the management port to do, how do I push them to 60+ firewalls in Panorama? I'd want to add these to an existing template. But maybe a new template that's "related" to some existing template?   Thanks, Ambi ... View more

Hi,   I finally figured this out!   The issue is that the management interface on all the firewalls needs to have the "Permitted IP Addresses" which defines which IPs can permit SSH, SNMP, ping, etc.   This is located in Panorama -> Setup -> Interfaces -> Management -> Permitted IP Addresses.   The thing that made me finally figure this out was the "Device Management Services" section: That section isn't in every firewall, just Panorama, whereas the othere sections (Administrative Management Services, and Network Services) are in every firewall. But how could I not see that the firewalls were all in the permitted list? That's easy. We've got over 70 firewalls, and the page these go into on Panorama (or any firewall) only scrolls. It does not page, it does not allow import/export, and you can't resize the window. So, unless you show them in the CLI, there's no way to really know for sure that they're in there.   For example, I can't export them, and I can't template them, so I have the 70 firewalls, as well as IPs for any user, monitoring device, SNMP manager, syslog machine, etc. defined here, so I have at least 100 devices.   Now, the list is templated for the firewalls themselves...that is to say, each firewall's individual list of permitted IPs is identical as they all use the "Base" template for such settings. But for Panorama, it's all manual.   So what I needed to do was screen-shot the 5 pages of firewalls from the working, primary Panorama, and do the same thing with the Secondary. Then, highlight which was missing on each side (if there was something missing from the Primary, it would show up).   Now, this could be easier by using the CLI, but I dissuade casual users of Panorama from SSH-ing into it, so I wanted to document the procedure with the GUI. And it works, but it's smelly.   Thanks for your assistance!   Regards, Ambi ... View more

Hi,   Thanks for your suggestion!   Unfortunately, the two panorama servers are defined in the Panorama Settings dialog. We're enabling push, with 240 second timeouts and a 25 SSL retry count.   I might want to see if deleting the secondary's IP in a firewall then adding it again makes it work. The problem with this is the Panorama servers are defined by template. So I'd need to override it, the revert it. That may be more than I want to do.   Is there a CLI command to show the status of connections to the Panorama peers...both on Panorama to see the firewalls, and the firewalls to see both Panoramas?   Thanks, Ambi ... View more