NetBotz 250 : SSH Hostkey and Public/Private keys

[Anonymous user]

Hello,

I am working on security features on the NetBotz 250.

I would like to know if the ssh hostkey, generated by the Security Wizard, is the private key, the public key or both keys of the Rack Monitor NetBotz 250 ?

Thank you in advance for the attention you may pay to my question.

Raphaêl

[Anonymous user]

Hi rf2019,

It's both, Security Wizard will generate a .P15 file which as far as I know is unique to APC devices. .P15 file can contain just the private key or they can contain both similar to a .PFX file.

I assume you mean the GUI version of Security Wizard, if so it will also give you the thumbprint that can be used for host verification to prevent "man-in-the-middle" attacks.

-Gavan  

[Anonymous user]

Hi Gavan,

Thank you for your reply.

So if I understand correctly, the .p15 file has merged within the public and private ssh keys.

Is there any way to send to the Rack Monitor the public and the private ssh keys in different files ?

Raphaël

[Anonymous user]

Hi rf2019,

Can I just clarify, you are talking about the SSH host key and you talking about using public key private key authentication?

For an SSH host key there isn't really public and private keys, there is a host key and a thumbprint which can't be separated.

The 250 doesn't support public/private key authentication, you need o use password based authentication. 

-Gavan

[Anonymous user]

Hi Gavan

I think I start to better understand how it works.

But if the Rack Monitor is the SSH server, does the client connecting to it (let's say a PC) will require the hostkey to be stored in its memory, or is the fingerprint alone sufficient enough ?

Thank you in advance.

Raphael

[Anonymous user]

I'm not an expert on SSH but it's not like HTTPS.

Think of it like a checking the CRC for a file that's been downloaded from the internet. The SSH server assumes that you already know its thumbprint and on connection it expects you or your SSH client to confirm that the provided key matches what you think it should be.

The thumbprint is generated by hashing the host key in some way. (I don't know the exact details).

-Gavan 

[Shaun · Accepted solution]

Hi Raphaël,

The HostKey is the server's (in this case, your 250's) key pair.  When the connection is first established, the server sends its public key to the client.  The client creates a "shared secret", and uses the server's public key to encrypt it, and then returns this to the server.  Now both client & server know this shared secret - the client because it created it, the server because it could use its private key to decrypt it - but for a third-party attacker, neither is true, so it doesn't have the shared secret.

The shared secret is then used as the password for a much more efficient cipher (eg AES).

For this to work, the client needs to be able to trust that the key it received from the server, really came from the server.  For SSL/TLS, this is done by signing the key using another key the client already knows and trusts (a CA).  This is actually possible in some ssh implementations too, but more typically we just compare the key against a copy we already have.

The first time you connect, your client doesn't already have a copy - so you'll be presented with the key's "fingerprint".  This is just a cryptographic hash of the public key, to make this comparison easier for a human to make.  In the web interface of the 250 (Configurating->Network->Console->SSH Host Key), this is shown as an MD5 hash.  Many clients now prefer sha256 by default, but you can usually ask them to show MD5 also in order to make this comparison (eg, for openssh this would be ssh -o FingerprintHash=md5 user@host..).

Once you accept that you trust this key, the public key is saved to speed this up in future connections (eg, in openssh this is the known_hosts file; the long string on each line is a public key encoded with base64).  Most implementations store the whole key rather than the fingerprint - it prevents collision attacks, and saves having to hash it every time - at the low cost of using a few more bytes on disk.

To bring this back to the 250; if the client connects and receives a key it doesn't trust, and especially so when the key has changed, a well-behaved ssh client will stop and inform you something unusual has happened.  This is the correct behaviour, but can be a real nuisance if you've had to replace or reset the card for perfectly innocent reasons - especially if ssh is being used for automations where this stop isn't immediately visible.  So we provide a mechanism to replace this key - so you can install your own, and if you ever need to reset or replace the card, you can install the same key again to quickly and easily re-establish this trust relationship for all clients.

This is all a standard (and mandatory) part of any ssh implementation - but because it's so rarely interacted with, it's easily forgotten.  Most people are used to dealing with their own user ssh keys, and assume that's the keys they're looking at - as Gavan said, at this time we don't support the user-key mechanism.

[Anonymous user]

Thank you Shaun for your detailed and precise information.

Just another last question.

For what I understood, NetBotz uses the hostkey (mix of public and private key).

However, is it possible to define a public and a private key, generated and defined by a bespoke security key generator, and input them on the NetBotz, so the SSH server on the NetBotz uses such keys ?