ssh-public-key1

[stukat]

We backup our config of our FortiGate 100D nightly to Hyperconf.  The POODLE vulnerability forced us to raise SSH encryption to "set strong-crypto enable".  This cause Hyperconf to fail. So....we tried to create a public/private key pair.  Easy enough.  Unfortunately we keep getting a 107 error from within Hyperconf:

There is no cipher supported by both: client and server. (107)

Operation failed: There is no cipher supported by both: client and server. (107)

Any suggestions would be appreciated.

[emnoc]

The POODLE has nothing to do with SSH but  you are taking the right approach with strong-crypto. Now onto your problem  if you can find a linux/mac run ssh with verbose and look at what the ssh-server ( fortigate ) is offering?

Most fortigates supports aes128-ctr  or aes192-ctr or aes256-ctr

E.g my  FGT60D at my home running 5.2.2

SOC1>ssh -p 2022 -c 3des-cbc  10.10.80.1 no matching cipher found: client 3des-cbc server aes128-ctr,aes192-ctr,aes256-ctr, SOC1>

As you can see 3des-cbc is not supported but a 4.3.18 fortigate somewhere on  the internet does;

SOC1>ssh -c 3des-cbc  x.x.x.x kfelix@x.x.x.x's password:

Also you can disable "SSHv1" via the  global settings which eliminates  version1 server. Which is a good thing and then retest forcing the client at  version 1 and you should get a immediate failure.

config sys global

   set admin-ssh-v1 dis

end

But you errors seems like your client is not presenting a cipher  that the  server offers. I would look for a  update to your ssh client and what support ciphers?

So I would find a unix host or some other client and do some diagnostics and debugs and see what's going on. And the last thing, you have a debug function in the fortigate for sshd

.

HOME60D (root) # diag debug application  sshd -1 HOME60D (root) # diag debug en HOME60D (root) # SSH: Making sure that 10.10.80.11, vd = root, is not blocked SSH: This ip 10.10.80.11 is not blocked SSH: Forked child 241. SSH: Client protocol version 2.0; client software version OpenSSH_6.2 SSH: match: OpenSSH_6.2 pat OpenSSH* SSH: Enabling compatibility mode for protocol 2.0 SSH: Local version string SSH-2.0-eAajI SSH: list_hostkey_types: ssh-rsa,ssh-dss SSH: SSH2_MSG_KEXINIT sent SSH: SSH2_MSG_KEXINIT received SSH: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 SSH: kex_parse_kexinit: ssh-rsa,ssh-dss SSH: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr, SSH: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr, SSH: kex_parse_kexinit: hmac-sha1,hmac-sha1-96 SSH: kex_parse_kexinit: hmac-sha1,hmac-sha1-96 SSH: kex_parse_kexinit: none,zlib SSH: kex_parse_kexinit: none,zlib SSH: kex_parse_kexinit: SSH: kex_parse_kexinit: SSH: kex_parse_kexinit: first_kex_follows 0 SSH: kex_parse_kexinit: reserved 0 SSH: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 SSH: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss SSH: kex_parse_kexinit: 3des-cbc SSH: kex_parse_kexinit: 3des-cbc SSH: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@ SSH: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@ SSH: kex_parse_kexinit: zlib@openssh.com,zlib,none SSH: kex_parse_kexinit: zlib@openssh.com,zlib,none SSH: kex_parse_kexinit: SSH: kex_parse_kexinit: SSH: kex_parse_kexinit: first_kex_follows 0 SSH: kex_parse_kexinit: reserved 0 SSH: Calling cleanup 0xbe9790(0x0)

So run your script while in debug, and see what happens

[stukat]

WinAgents updated their HyperConf program to accept CTR.  We can now log in to FortiGate with a key.  Now, can I disable password authentication on the "admin" account so that the only allowed method of accessing the device is by public/private key?

Currently I've changed admin user to prof_admin and removed all rights to it.  Accessing FG via LDAP until this is figured out.