3

https://nexla.zendesk.com/hc/en-us/articles/360053720333-Database-Connection-Options

Specifically:

In a text editor, add the below public SSH key to the authorized_keys file. The key must be all on one line. Make sure that you don’t introduce any line breaks when cutting and pasting.

This is the last portion of "Step 1." - this implies each user does not generate their own key, and there is no method to, as there is no where to import a private key within the platform. As far as I can tell this is reusing the same private key for multiple users.

It seems like there is potential for users of the platform to access other user's of the platforms data. Obviously the attacker would not only have to be a user of the platform but also know the database details post-ssh connection. It would also require the use of the same username (but given a default is suggested, seems likely). There is a lot an attacker would have to know to successfully access data they aren't supposed to, but I thought the rule in security is assume the attacker knows every detail of the set up, and make sure it's still secure (0 trust).

Edit: Hopefully add clarity and retract my statement in my first comment. I'm fairly confident after more research and double checking the phrasing that this is re-using one key per user and not good practice. Would love to see a more reputable (or at least a more security focused engineer than myself) confirm or deny this in an answer.

18
  • To whoever downvoted, can you help me understand why this isn't a good question for the site? I'm not implying it is insecure, just trying to understand....
    – TCooper
    Jul 26, 2022 at 19:10
  • I didn't downvote, but I'm not sure where you are seeing a concern. The article seems to describe typical SSH public key based authentication. First, a secure connection is built based on the server's private/public key pair (is this what you mean by same private key for multiple clients?). Then, clients authenticate using public key authentication, where clients prove possession of the private key associated with the public key stored on the server (each client uses a unique keypair to authenticate, only public keys are stored on the server). Where are you seeing a security concern?
    – mti2935
    Jul 26, 2022 at 20:23
  • @mti2935 because each user uses the same public key if following that guide. That implies they're setting up their server to connect to the same private key used by the platform for each account attempting to connect, no?
    – TCooper
    Jul 27, 2022 at 14:38
  • @mti2935 each client doesn't generate a new key, instead they're instructed "In a text editor, add the below public SSH key to the authorized_keys file. The key must be all on one line. Make sure that you don’t introduce any line breaks when cutting and pasting."
    – TCooper
    Jul 27, 2022 at 14:43
  • 1
    Smells like they're giving a single Private Key access to each user. Potentially the key belongs to their Support team? I'd definitely ask the Vendor.
    – tjd
    Jul 27, 2022 at 15:58

2 Answers 2

1

The title and the body of your question ask two different things:

  1. The title asks whether it is secure to have public key authentication enabled in your ssh server and allow every user on the system to authenticate using the same key pair. That's obviously an insecure setup. An example as to why, is that a user can list all other users of the system (e.g. cat /etc/passwd) and then just connect to the system as another user.

  2. The body of your question describes a different scenario; you ask whether it's secure to:

    • have host A (bastion) run an ssh server
    • have host B run a db server
    • allow access to host B only from host A
    • create a user, with default name nexla, on host A
    • allow public key authentication ssh access on host A
    • set the public key of the user on host A to be a predetermined one
    • announce the public key of the user to the public (no pun intented)
    • have the private key reside on Nexla's servers (not known to the public)

    This is obviously more secure than the scenario described in point 1, because your bastion host is only used by Nexla's data connectors from inside the company's network, the public key cannot be used to figure out the private key (as far as we know) and you have the choice not to use the default user name, making an attack even more difficult for potential attackers. However, it has the problem that the private key to connect to your internal network resides on Nexla's systems (which can be anything from hardened servers to employees' unpatched laptops). This makes it a trust issue on Nexla's security practices.

So, I don't see how other customers could abuse your bastion (or the db) without having access to both the private key and the username (if not the default). Even if they do try to use Nexla's web interface in order to break into your db (they can't access the bastion host by using the web interface) they still don't have the credentials to connect to your db - and a manual brute force is practically impossible (remember, they have to use the web interface in order to connect to your db, because they don't have the private key).

But, for the sake of the argument, let's say that they do have access to both the private key and the username you've used for the user at host A (bastion). Having this access means that they will have already broken into Nexla's network or are Nexla's employees with suitable access. So, if they do have access into Nexla's network, won't they also have access to all the data that Nexla is processing on your behalf (i.e. your db)? (is there a point into breaking into your network afterall, if they have all your data?)

0

That's a strong 4096-bit RSA key. I wouldn't worry about the key's cryptographic soundness, but I would worry about its storage and handling.

It does not at all fill me with confidence that the comment to this widely-used private key says [email protected], implying that it was generated by a user at this company named Avinash on a laptop rather than on a server.

It is best to never copy private keys but rather generate new keys on new hosts and then add them to relevant authorized_keys files, then to retire the old key and remove it from those files. However, with a manual model like this, that's not at all practical. There's no revocation mechanism. No way to remove the key's access if it ever gets compromised.

If Avinash's laptop is stolen, the key is out in the wild. If a few years pass and he gets a replacement and the laptop is then sold and the contents are recovered, the key is out in the wild. If Avinash's laptop is backed up and the backup is compromised, the key is out in the wild. If one of the servers the key was copied to was compromised, the key is out in the wild.

If the cryptography behind RSA (or at least RSA at 4096 bytes) is found to be insecure (OpenSSH has already migrated to preferring ed25519 in place of RSA as its preferred key type, but 4096-bit RSA is considered secure at the moment), an attacker may be able to authenticate as if holding the key.

And there's no revocation mechanism (unless you count email 🤢).

I'm not fond of this security model.

However, you're not entirely at risk. This doesn't open up root access to your system, just a dedicated nexla user (which, if you're unpatched, could run an privilege escalation exploit to become root). They even recommend you restrict access to the two IPs listed at the top of that page, which further helps control this. (Do this!)

To better tighten things down, I'd recommend setting up a restricted shell for them that only permits the exact action they perform on your system. That way, the only thing at risk is the database they're maintaining for you.

4
  • Private key? What private key? The linked article repeatedly states this is a public keys and the steps described are those which should be applied to a public key. Public keys are so named because there disclosure does not compromise the security of communications.
    – symcbean
    Jul 31, 2023 at 15:47
  • @symcbean – They offer one SSH public key for two IP addresses, implying at least two hosts, each of which uses the same private key. The key's comment states it was generated on a third system, an employee's laptop. Copying public keys is necessary. Copying private keys between systems is not a good practice. If it turns out that "Avinashs-MacBook-Pro-2.local" is the server and simply has two IPs, there are much more serious issues.
    – Adam Katz
    Jul 31, 2023 at 16:20
  • You'd better tell Google that they need a unique certificate on each of their servers then.
    – symcbean
    Jul 31, 2023 at 16:37
  • I trust Google to have good security around the deployment of their TLS keys to their load balancers, which encrypt server-side data that is otherwise visible to Google's backend. I can't say the same about a company that clearly generates keys on employee laptops, especially when these are SSH keys that grant remote access to a myriad systems.
    – Adam Katz
    Jul 31, 2023 at 17:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .