Fortigate SSH Server Generate New RSA Key Pair

[AtiT]

Hello,

Does anybody know how to generate a FortiGate SSH Server new RSA Key Pair - if it is possible at all.

Where is the default RSA key pair located on a FortiGate?

$ ssh -l admin x.x.x.x The authenticity of host 'x.x.x.x (x.x.x.x)' can't be established. RSA key fingerprint is 69:b7:62:fe:57:0b:bb:db:c3:87:bf:12:95:d0:c5:5d.

Are you sure you want to continue connecting (yes/no)? 

Thanks.

[SJFriedl]

Hmm. I have been ssh'ing into Fortigates - including HA pairs - for a long time and don't remember running into the host key changing other than after major software upgrades.

And though I can kind of understand why you'd want to install a fixed host key in each machine just to make automation easier, I'm trying to figure out if this actually makes you any more secure. If that fixed host key is floating around outside the Fortigate it's subject to compromise, and that seems sub-awesome plus a maintenance challenge.

Some packages that do automatic collection of networking gear configs - such as the miserable but versatile RANCID - script "accept new host key" as part of their connection chitchat, so many have decided this is just not that much of a risk even though it sounds sub-awesome.

I have a simple grab-the-config script that runs to my 60F every night, and I use "-o StrictHostKeyChecking=no" on the "scp" command line to automatically add the host keys.

My feeling is that if you suffer a man-in-the-middle attack between you and your default gateway, there are far deeper security problems on the network than dealing with SSH host keys.

Food for thought. I could be wrong.

[AlexFeren]

SJFriedl wrote:
I'm trying to figure out if this actually makes you any more secure.

My issue's not security - changed SSH public key usually indicates "system changed" - usually, a failover or upgrade. In this situation, nothing changed, other than a reboot.

The fact that ED25519 doesn't change but RSA does indicates - configuration setting or a bug.

[emnoc]

No the RSA key should not change unless MiTM is going on.

So do this,  login into the fgt  and use the local-ssh client integrated into fortios

e.g

    execute ssh kfelix@192.168.1.99 Let the fortios store the host fringerprint, and redo the same command after logging out and back in , did it show you a new permanently adding key to known_host  The below should come up only once until you manually delete the keys or upgrade the fortios       "Warning: Permanently added '[192.168.1.99]:2022' (ED25519) to the list of known hosts." Also are you running any special task jobs that will regen-key ? or running in FIPS mode ? which should not do any key-regeneration by it's self. And fwiw, I'm running maybe 2 fgts on 6.4.3 and 5 on 6.4.4 none on 6.4.5. The only way that I'm aware of a new key being loaded to known_hosts , if the ip_address changes or you add a new address or you ssh into a new address examples /* not I'm running ssh on port 2022 in my setup */ homefgt (vdom) # edit rootcurrent vf=root:0 homefgt (root) # execute ssh kfelix@192.168.1.99 2022kfelix@192.168.1.99's password:  homefgt (root) # execute ssh kfelix@127.0.1.1 2022Warning: Permanently added '[127.0.1.1]:2022' (ED25519) to the list of known hosts.kfelix@127.0.1.1's password:  homefgt (root) # execute ssh kfelix@127.0.1.1 2022kfelix@127.0.1.1's password:  homefgt (root) # execute ssh kfelix@127.0.1.2 2022Warning: Permanently added '[127.0.1.2]:2022' (ED25519) to the list of known hosts.kfelix@127.0.1.2's password:  homefgt (root) # execute ssh kfelix@127.0.1.3 2022Warning: Permanently added '[127.0.1.3]:2022' (ED25519) to the list of known hosts.kfelix@127.0.1.3's password:  homefgt (root) # execute ssh kfelix@127.0.1.3 2022kfelix@127.0.1.3's password:  You can always debug from the fortigate side of things also to see if sshd is doing anything weird.      diag debug application sshd -1 I would also check a few other ssh-clients. Report back on what you find. Ken Felix  

[AlexFeren]

We've already established that ED25519 doesn't change, so, using FortiOS 'execute ssh' which only uses this Host Key type won't show anything pertaining to RSA.

I've previously done "diagnose debug application sshd -1" - this is what I saw:

:

SSH: notify_hostkeys: key 0: ssh-rsa SHA256:21R3QR7eg9ffOjWUTrgKHDnHdIXTO5F9gS5lb0Op4BY SSH: notify_hostkeys: key 1: ssh-ed25519 SHA256:q7S3RT/EhTxfxfXyDdx95KNCBOMdork/PdYovXpcv9g

:

Those two matched exactly what "ssh-keyscan 10.0.0.1 | ssh-keygen -lf -" shows, so, there's nothing "weird" except that the RSA one changes after reload or power cycle.

Well, something that is weird is - I keep receiving Alertemails like this - I never received them in 6.0.12:

date=2021-04-24 time=14:22:55 devname=obfuscated devid=obfuscated eventtime=1619238175542759375 tz="+1000" logid="0100032247" type="event" subtype="system" level="error" vd="root" logdesc="SSH protocol cannot be negotiated" addr="192.168.X.Y" port=0 msg="Negotiation failed: no matching host key type found. Their offer: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521." 

Those Host key algorithms can be see in "ssh -vvvv" attempts, so, it's obvious that (cygwin) ssh is offering them at handshake, but Fortigate takes offense.

[user185953]

By the way, what does "get system info admin ssh" on fortigate give you?

Is it same ssh-rsa key as ssh-keyscan give you?

The command is outdated and shows only RSA fingeprint and only in md5. Ignore "DSA fingerprint" garbage.

PS: For me it is ssh-ed25519 keys that (at least back in the 5.6.x days used to) change when rebooting.

I abandoned using ssh-ed25519 keys because they are inconsistent across the cluster, making failovers annoying.

[emnoc]

Your not going to get the private-key from a ssh session.

OP, when you say new keys are you verifying the ssh fingerprint? and is the fingerprint the same ? And noting is doing any ssh-proxy between the client and the fortigate ?

e.g ( openssh )

 ssh -vvvv x.x.x.x

And look for a string similar to "debug1: Host '[192.168.1.99]:2022' is known and matches the ED25519 host key"  that would be your fingerprint housed in known_hosts files.

Ken Felix

 

[AlexFeren]

emnoc wrote:
is the fingerprint the same?

[strike]no.[/strike] Actually...

Before reload: host $ ssh-keyscan 10.0.01 | ssh-keygen -lf - # 10.0.01:22 SSH-2.0-Lw5qF # 10.0.01:22 SSH-2.0-Lw5qF # 10.0.01:22 SSH-2.0-Lw5qF # 10.0.01:22 SSH-2.0-Lw5qF # 10.0.01:22 SSH-2.0-Lw5qF [style="background-color: #ffff99;"]256 SHA256:q7S3RT/EhTxfxfXyDdx95KNCBOMdork/PdYovXpcv9g 10.0.01 (ED25519)[/style] 1024 SHA256:21R3QR7eg9ffOjWUTrgKHDnHdIXTO5F9gS5lb0Op4BY 10.0.01 (RSA) After Reload: host $ ssh-keyscan 10.0.01 | ssh-keygen -lf - # 10.0.0.1:22 SSH-2.0-uBS8L # 10.0.0.1:22 SSH-2.0-uBS8L # 10.0.0.1:22 SSH-2.0-uBS8L # 10.0.0.1:22 SSH-2.0-uBS8L # 10.0.0.1:22 SSH-2.0-uBS8L [style="background-color: #ffff99;"]256 SHA256:q7S3RT/EhTxfxfXyDdx95KNCBOMdork/PdYovXpcv9g 10.0.0.1 (ED25519)[/style]

1024 SHA256:3D0pNjuaODGYrjRJLSsWDWgscA7hZAV8Q/7BNpbgEuA 10.0.0.1 (RSA) So, ED25519 fingerprint stays same, but RSA changes...

However, it seems SecureCRT, by default, uses RSA and complains about "SHA-2 hash base64: 3D0pNjuaODGYrjRJLSsWDWgscA7hZAV8Q/7BNpbgEuA".

I've reprioritised Host Key algorithms in SecureCRT (attachment) and now, not getting changed changed host key warning.

So.. Back to original question, now more nuanced, is the RSA key supposed to change at reboot - a configuration setting or a bug?

[wsladek]

Did you find an answer to this?  My SSH key changes after every reboot as well, and this is impacting automation (software will not connect if key has changed - and rightfully so.)  Running 6.4.8 on 80F.

[it-sldo-is-security]

same problem here. 6.2.x -> all fine. 7.0.6 -> Keys differ on active and passive machine, and change after reboot. That kills the automation. Any ideas? thx