I have a quick question around SSH pub/priv key usage.
Eager to get some advice/opinions on what might be the risks/advantages, any thoughts around security etc.
This is the basic scenario.
...I'm an admin of a Machine A for my business. I require to transfer (outbound only) files to all my individual customers endpoints. For this, I generate a pub/priv key pair and then I provide the public key to Client A/B/C etc, who provides a username for me to facilitate a connection to them (One directional).
e.g.
machineA $ ssh clienta_user@clientA_IP_Address
machineA $ ssh client_B_stuff@clientB_IP_Address
Etc. etc.
Machine A (Me)
|
________________________________________________
| | | |
Client A Client B Client C Etc
In this case, I only have and manage one SINGLE pub/priv key pair. And this pairing is used then to essentially connect to all my different clients/customers. So, the private key remains securely only on Machine A, in ~/.ssh/ under the same OS user.
...If I was to say, generate an individual pub/priv key pair per each client/customer - the multiple private keys still remain under the same OS user, in the same directory, on the same machine.
So, does having potentially many multiples of pub/priv key pairs (for each client/customer) really enhance security?
i.e. if Someone gains access to machine A, all private keys will be compromised whether its one or ten?
Does it really enhance my position to have multiple pairings or just create an administrative overhead?
Probably not much difference , more admin with more keys.
Presume you are well aware of the basics around security of keys etc.
If the account on your host is interactive then make it encrypted - at least that way there's an additional layer of security needing to be compromised.
perhaps look at a different model than SSH for this purpose -
one potential might be Syncthing - Wikipedia
(I've no experience of it myself so cave usor ! )
am sure the team will have additional feedback on this.
If I'm understanding things correctly, the question boils down to: is having one shared key for all my remote accounts less secure than having individual keys for each of my remote accounts ? And as you say yourself, if all these keys are still ultimately used by one single local user account, then the point is moot - if that account is ever compromised, all the keys it uses will be readable by the person accessing it, and so it makes no difference if you have one key or a hundred.
If you were to break up your remote access into multiple separate user accounts ,and assign each account a dedicated key pair, then that would increase security in a tangible way. So long as the compromise of one of these accounts would not lead to the compromise of any of the others, then the worst case scenario would be that the single key pair used by that account would be accessible to the hackers, and therefore you would only need to change that one compromised key.
Of course, again if the root account (or its equivalent) were to be compromised, then all bets are off, as once a hacker has access to that, they have access to everything on the system anyway.
If you want to increase key security, one suggestion is to create your keys with a passphrase. This does mean that if ever anyone got a copy of the private key, the would need to know the passphrase to be able to actually use it. Now, you might think that would get in the way of automation/scripting, but in reality it need only do so to a very slight degree. If you use an SSH key forwarding agent, it can load the key one time, asking for the passphrase one time, and then use that key passwordlessly (if that's a word ) every time that a connection requires it. That, I think, is probably the single biggest thing you could do to increase key security, rather than worrying about which accounts use which keys.
I would say yea at least you will need to have and user/group for each client accessing your system.
In general to expose SSH service to internet good practice would be to use chroot per user and change default SSH port to some high one to avoid malicious scanners.
Limit shell access as well, use SFTP subsystem with chroot.
Limit network to only allow access from your clients by employing local linux firewall or extermal firewalls in your network.
Minimum rights which are needed should be enforced and servers exposed to internet should be patched fairly often.
You might also want to audit such system(s), depending on the sensitivity of data in question.
Yes, all the basic security mechanism to protect the private key are in place.
We couldn't leverage something such as Syncthing as we would not be able to leverage a system of Community relays. Our actual SSH transfers are all made across IPSec VPN tunnels to customers.
"if all these keys are still ultimately used by one single local user account, then the point is moot - if that account is ever compromised, all the keys it uses will be readable by the person accessing it"
Yes, this is exactly it - that single local account will have to remain as is, unchanged, without some substantial application re-write changes; if we were to examine breaking the local accounts into individual separate users.
This query itself stems from a suggestion from an external party inferring that we must (Per 'well known' best practices), incorporate individual client pub/priv key pairs but in our bespoke scenario, it is a one-to-many type type relationship, which renders the argument without foundation in my opinion. It does occur to me that from an "optics" perspective, the idea of many individual unique pub/priv pairings might appear more secure, albeit without any real tangible security enhancement (If all present under the same local OS account user).
Thanks @Peasant, but in this scenario. No one is accessing our system.
We are the the initiator of all connections outbound to each recipient (i.e. we are the mailman).
So, does having potentially many multiples of pub/priv key pairs (for each client/customer) really enhance security?
I believe it does enhance security in some way. I suspect that you do too, or you wouldn't be looking for a reason to not do it.
The security enhancement comes from non-obvious places related to when things fail and the key pair is compromised.
If you are using a separate key pair to access each client, then there is no way for the compromise of one key pair to possibly be used to to attack other clients.
Consider a type of compromise wherein a client's system is compromised and manages to attack your system wherein the key pair on your system is exposed. Or if you're (conditionally) using SSH agent forwarding, because you nominally trust your client's system, someone with elevated privilege on a client's system could access your forwarded agent and get it log into one of your other client's systems.
You can use a from stanza in the ~/.ssh/authorized_keys (et al.) file, but that's a relatively easy thing to change.
Conversely if you use completely different key pair, then it's not possible to use the incorrect key pair to cross log into client's systems. (I'm assuming that you are being intelligent about what is forwarded and where.)
It's really about additional / backup layers of security for when something else fails.
In your scenario, it would be quite easy to use different key pairs for each client and configure your client to automatically use the proper key pair based on the remote target system in the ~/.ssh/config file (et al.).
) every time that a connection requires it. That, I think, is probably the single biggest thing you could do to increase key security, rather than worrying about which accounts use which keys.