Linux discovery and SSH Public / Private Keys

[lmundere]

Hi,

I am currently setting up the Linux Discovery, and we have opted to use the SSH Private Key, and I have received the pair, (both private and public key), I understand that I will add the private key in the SSH private Key within the credentials in ServiceNow and my question is where to put the Public Key? I am going to use a MID Server hosted on a Windows Server.

[Maik Skoddow]

Hi @lmundere 

please have a look on https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/credentials/reference/r_SSH...

You don't need the public key.

Kind regards
Maik

[Jim Palmer]

There's a stack of great documentation on public key authentication available on the web, some more technical than others, but as a basic concept (and this is over-simplified) the public key allows the client to encrypt data, while the private key allows you to decrypt data.

So in the context of ServiceNow discovery, ServiceNow holds the private key (decryption key) and you send the public key (encryption method) to the Linux servers you want to discover. Maik's link below is setting up the private key in ServiceNow but you still need to configure the targets for discovery.

To setup SSH authentication on a target:
By default, on the target host, you append the contents of the key generated *pub file on a new line into a special file the home directory of the user you wish to authenticate as:

e.g. my username is 'sndisco'
The file I use is '/home/sndisco/.ssh/authorized_keys'

Then when ServiceNow tries to discover as 'sndisco', it'll ask the discovery target if it can use the private key file for authentication and if the key is setup, it'll authenticate with the keys rather than password, and if the key is not setup properly, it by default is setup to fall back to user/password.

This - on face value - is a good explainer on how to setup key auth. It does get into the weeds of SSH server and client settings that can stop authentication from working.

https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys

Note how i've used the phrase 'by default' a lot. You can configure ssh authentication on the server and the client in a lot of different ways and you can even add directives on the public keys themselves to further limit access, so there's a lot of 'ifs' depending on security policy. 

And i haven't even touched the sudoers setup for privilege escalation on the target...

[MA11]

Hi,

And... what you think about touch now the sudoers setup?

Thanks. 

[Jim Palmer]

Regarding sudoers;

The ServiceNow docs page has the list of commands required and additional file/command requirements for discovery of software/subsystem discovery here:

https://docs.servicenow.com/bundle/sandiego-platform-security/page/product/credentials/reference/r_S...

sudoers can get complex and can be very highly customised on each target with include files/directories and it's usually safer to leave it entirely up to your Linux admins to get the setup right. As if you break it, generally the only way to get privilege back is direct access to the root account (which in some organisations has a whole lot of additional security process). Sometimes there are other tools used to manage the sudoers files automatically.

Remember, sudoers is a privilege escalation tool so there will be additional steps to get access, follow your organisations processes.

But here's some documentation:

https://www.digitalocean.com/community/tutorials/how-to-edit-the-sudoers-file

https://www.sudo.ws/docs/man/1.8.17/sudoers.man/

And some tips/gotchas:

ALL=(root) NOPASSWD:...

NOPASSWD is a great option in the sudoers config if you're using SSH keys (see the ServiceNow docs) but starting it with the ALL directive is way too broad and the security team won't like it.

Defaults:disco !requiretty

(In this case 'disco' is the discovery user) Also useful for SSH key auth as you won't get a 'real' tty (terminal) for that user when doing discovery via ssh keys.