since we upgraded to FortiOS 5.2.5 or 5.4 Cattools gives us the error message "Failed to connect to XXX. Reason: No respone from remote host. Will try again."
If we connect to it with Putty we get a session.
Have debugged the SSH from FortiOS but no error messages is shown.
The debug in Cattools doesn´t give any errors either:
<NEWSESSION CatTools 3.10.0 2016-01-15 08:41:31>
<ACTIVITY TYPE=Device.Backup.Running Config>
<ACTIVITY SCRIPT=D:\Program Files (x86)\CatTools3\Scripts\Client.Device.Backup.Running Config.txt>
<USERS NAME FOR DEVICE=nbo-osd2fw01>
We have tried all different SSH ciphers but with the same result. When we save the ciphers we can see that it sends it to the FortiOS and that it accept it.
Can you please log in to your customer portal and download the latest RC of Kiwi CatTools. There should be a fix for the FortiGate problem you're experiencing. If you continue to have issues please contact me directly and we will continue to investigate.
RC3.11 does appear to have fixed the issue with the Fortigate 5.2.x Firmware.
I have reverted to SSH2 in CatTools after the install and the backup works without issue.
Fortinet released 5.2.7 for Fortigate. We've applied it to one of our test Fortigates and it does *not* address the shortcomming in CatTools SSH2 key exchange.
Would be really great if Solarwinds would patch the app...
My Service Provider has queried with Fortinet who say it is fixed in 5.2.7
we can't wait for that.
They suggested another work around to enable SSLV1 which whilst not ideal is better that enabling telnet.
config sys global
set admin-ssh-v1 enable
Did you lab this up? Did it work? I was hesitant to waste time with SSLv1 figuring the KEx was likely a similar process and was likely also broken. We've already implemented telnet with switchport-based ACLs to restrict access to tcp/23. Not ideal, but should be ok the until FortiOS patch is available.
I have this,
We had to update 2 of our 310B's due to the back door bug and after that they would not back up ( And they were the ones we bought the product for at the start of this year!)
Solar Support says that the tool used to connect written by "WeOnlyDo" does not support 2048 bit encryption. The suggestion was to use telnet (err no thanks) or upgrade the Fortigate to 5.2.6 but the bug# they reference is not referenced in 5.2.6 release notes.
Apparently there is a feature request for 2048bit support, I am a bit shocked it's not there already!
Looking at the releases of CAT
- (Released on 04/08/2014)
Does not seem there is much going on with it, if they are not developing it then it's going to be useless very soon.
There´s some more information regarding this issue att the Fortinet Forum.
"We had this same problem and raised it with or suppliers and were told:
This issue is related with the default dh-param that is changed from 1024 to 2048. But the FGT is still offering algorithm as "diffie-hellman-group-exchange-sha1" and "diffie-hellman-group1-sha1". When ssh client try to communicate with algorithm order "diffie-hellman-group-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1", FGT sends a TCP FIN. And the ssh connection can not be set up.
This issue is expected to be resolved in 5.2.6 or 5.4.1.
Fortinet have advised that there is no work around for this issue.
A fix will come in 5.2.6, the ETA for 5.2.6 is between Jan 25, 2016 - Jan 29, 2016 and for 5.4.1 its Feb 15, 2016 - Feb 19, 2016."
Same issue for us. Upgraded 2 of our 80C test devices (5.2.5 and 5.2.6 respectively) and same issue. Putty works fine, but CatTools fails in the area of the key exchange when watching the pcap on the Fortigate side.
Anyone know why is this considered a Fortinet issue? If we can use putty from the same box, it would appear that CatTools is not responding correctly to the Fortigate key exchange.
I opened a case with Solarwinds to see why CatTools can't negotiate the connection, but putty can...
Fortigate 5.2.6 does not resolve the issue. Solarwinds refuses to admit that it's a shortcoming in CatTools (despite my illustrating that PuTTY and openSSH appear to negotiate the ssh KEx just fine). Foritgate support has not responded to our case to either receive a patch or gain access to 5.2.7 as of yesterday.
So glad I'm paying for Solarwinds support...
Update for Case #948011 - "Fortigate v 5.2.(5,6) causes SSH timeout"
Thank you for contacting SolarWinds Technical Support.
This is a known issue introduced in Fortinet 5.2.5 (Fortinet bug ID 0300588) we expected it to be resolved in 5.2.6 but as you confirmed, its still present in 5.2.6. You may upgrade to Fortinet 5.4.1 (depending on which release has the fix) when available. Check with Fortinet support for more information.
Technical Support | SolarWinds - Unexpected Simplicity
Office Hours: Mon-Fri 9AM-6PM EST 866.530.8040
It looks like Fortigate made a change that requires a fixed order of the encryption algorithms -- see e.g. Cipher protocols supported by NCM SSH .
I suppose Putty can somehow handle that while our software can't.
Anyway, FortiOS 5.2.7 should fix that problem.
We are using Orion NCM 7.4 and cannot log in our 5.2.6 Fortigate box would it be possible to link this to the NCM product so NCM users can find the solution quicker.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.