5 ms·

This is probably the wrong forum, but I have a question or two that I see as related. I have setup a VPS, disabled passwords, and setup a key with a passphrase

This is probably the wrong forum, but I have a question or two that I see as related. I have setup a VPS, disabled passwords, and setup a key with a passphrase to gain access. At this point my greatest worry is losing this private key, as that means I can't access the server. What is a reasonable way to backup my private key? Encode it as something similar to a QR-code, print it, and store it in a hole in the wall? Copy it to an USB-stick and hide that somewhere safe? Alternatively, I have access to more than one computer, so I could also authorize a couple of other keys to access the server. So I would transfer the public key to the authorized machine, and add them to the authorizedkeys from there? How to deal with the possibility of death? Do I trust someone with my keys and passphrases?

cyberpunk 10y ago
As long as the key is password protected with a reasonable strength password (say, a sentence which you remember) then why not put them everywhere? I generally have a copy of my ~/.ssh copied to a few locations, and I'm not really concerned about people guessing the password more than someone hijacking a ssh auth sock on a remote system (which is why you should ssh -A only when you need to :}}) Edit: To elaborate on this a bit more -- perhaps I'm not an ideal role model for 'best practice' ssh key behavior -- but I end up dealing with a whole load of keys and boxes in $dayjob: punkz:~$ wc -l ~/.ssh/known_hosts 1473 /home/punkz/.ssh/known_hosts punkz:~$ ls -l ~/.ssh/id_* | wc -l 31 I deal with these by creating a new keypair for each client I'm working with (sometimes one for each of their environments) and I incorporate their name, or the location of the office I first attended for them, into the passphrase for the key somehow. While this is similar enough to the others that I won't forget the whole thing and so if I have to pick up some old client where I've forgotten the phrase there's usually only about 4 combos with the client's name or the address with various CaSeOpTiOnS or so on that I can usually get there.. I suspect if someone, or ... say .. some state, was targeting me personally to get access to a specific key that if they've gotten to the point where they have copies of them anyway; I wouldn't be able to stop them with a clever passphrase which is more unique than what I currently do.. Thinking along those lines then, I'm aiming to protect against lazy/stupid attackers wanting 'low hanging fruit' as it were, vs the big boys who probably have other ways of pulling these secrets from me.... I maintain a completely different passphrase schema for my personal keys -- either way, that's how I do it; seems good enough for me.. Any thoughts?
- jamiesonbecker 10y ago
  You don't need to use different keys for each customer.. it's not a problem to just provide the same public key for all of them. However, if you have several different access devices (i.e., laptop and desktop), you should definitely have different keys on those. (disclaimer: I work for Userify)
  - cyberpunk 10y ago
    I disagree -- you really do need to; I tend to need to use ssh -A on my clients (jump boxes, etc) -- and the agent I will only have their key in it -- if one of the other staff with root on the bounce box, or an attacker, grabs my auth sock, then the keys only let them further into that one client, instead of pwning all my others... Or say, someone pwning a dev jenkins box doesn't get an agent connection which lets them into prod...
    - cuu508 10y ago
      Any other reasons for separate keys, if I don't use ssh -A?
      - cyberpunk 10y ago
        Not really. Think of each key as, well, a key.. If you used the same key in every lock in your house, that might be ok... Sometimes, though, you need to be more careful -- the only motivation for using more than one is to limit the damage someone getting a copy of that key does, right?
    - deleted 10y ago
      [deleted]
    - philsnow 10y ago
      You (probably) don't need to use -A to use a jump box. SSH agent forwarding with -A is unsafe on shared jump boxes where either 1) anybody else has root on the jump box or 2) everybody uses a shared account on the shared jump box, because the connection to your agent can be hijacked and used to authenticate as "you" elsewhere. Look at ssh's -W or -J options (depending on how old your ssh client is), or see e.g. [0]. [0] https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts#Jump_Hosts_--_Passing_through_a_gateway_or_two https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...
lastofus 10y ago
For backing up your keys, they can be encrypted to a device with full disk encryption, or to a mountable disk image that's encrypted, and then push that file off site. As for access if you lose a key, unless you somehow run a VPS that also uses full-disk encryption (and requires a passphrase on boot), then your hosting provider has access to your VPS. For instance, with DO or Linode, you can log in to the admin console and reset the root password of a server. Once done, you can use the terminal built into the admin panel to access to the server even if SSH is disabled. Presumably, someone could work with the provider, prove you are dead, and that they should gain access to your servers. At that point it would come down to the policy of the hosting provider.
- cyberpunk 10y ago
  An account that can only login on the local ptys is a good enough backup plan. The disk encryption doesn't buy you much in such an environment, though... Even with whole disk encryption if you're running virtualized; then your provider can just read your VM's memory anyway... Unless your VPS is going to be forever shutdown, disk encryption under a hypervisor you don't control seems reasonably pointless -- I only use it for physical security to stop people being able to use disks they yank from physical boxes -- even then if they were motivated enough they could probably grab the memory from the server(s) and get the keys anyhow... AFAIK, there is no possible protection from this besides running your own gear. There were recently published attacks where someone managed to pull keys from other machines by abusing some either intel or vmware's memory dedupe tech bugs iirc (don't have the link handy) -- so; it's not even limited to what your provider may be doing...
jamiesonbecker 10y ago
It might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case one is compromised or assumed to be compromised. (disclosure: I work @ userify)
- jlgaddis 10y ago
  In addition, it might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case the third-party service you're using to manage the keys to the kingdom is compromised or assumed to be compromised.
  - cyberpunk 10y ago
    Sorry to hijack this, but this is absurd. I really must have missed the story here -- people pay for a third party service to manage their private keys? ... Err. That's so illogical it's making my brain hurt to even work out why I would need to explain how illogical it is... I can't even come up with a good analogy for how wrong that whole idea is, fortunately I don't have to though since no one that has mastered 'ssh-keygen' and 'cp' would actually do so..... 2FA, okay; the service provider only has half the story. ssh-keys-as-a-service? WAT. Edit: Okay, I looked a bit more at userify and it seems to be an agent that runs on your systems which generates authorized_keys files.... From their docs: "There are two parts of the Userify installation: creating the agent (readable only by root) in /opt/userify, and setting the agent to start at bootup. Setting the agent to start at bootup is a bit trickier, but the installation process attempts to detect the server type and set it up properly." Am I reading this wrong? You hook up an agent, which runs as root, which farms out authorized_keys entries across the estate? One possible mech for deploying the agent is conf management? What the actual fuck? Why would anyone do this? Do I even need to explain why this is blowing my mind so much?
    - viraptor 10y ago
      keyegn + cp don't do everything. Unless the distribution and session killing is automated, you can't easily revoke access. Of course you could implement this fairly easily with {chef/puppet/salt/ansible/...} and ldap, but it requires time / bandwidth. This is what userify seems to give you. I'm not saying it's a good solution though. I agree that it's giving someone full access to your whole environment and it's a bad idea.

cyberpunk 10y ago

As long as the key is password protected with a reasonable strength password (say, a sentence which you remember) then why not put them everywhere? I generally have a copy of my ~/.ssh copied to a few locations, and I'm not really concerned about people guessing the password more than someone hijacking a ssh auth sock on a remote system (which is why you should ssh -A only when you need to :}}) Edit: To elaborate on this a bit more -- perhaps I'm not an ideal role model for 'best practice' ssh key behavior -- but I end up dealing with a whole load of keys and boxes in $dayjob: punkz:~$ wc -l ~/.ssh/known_hosts 1473 /home/punkz/.ssh/known_hosts punkz:~$ ls -l ~/.ssh/id_* | wc -l 31 I deal with these by creating a new keypair for each client I'm working with (sometimes one for each of their environments) and I incorporate their name, or the location of the office I first attended for them, into the passphrase for the key somehow. While this is similar enough to the others that I won't forget the whole thing and so if I have to pick up some old client where I've forgotten the phrase there's usually only about 4 combos with the client's name or the address with various CaSeOpTiOnS or so on that I can usually get there.. I suspect if someone, or ... say .. some state, was targeting me personally to get access to a specific key that if they've gotten to the point where they have copies of them anyway; I wouldn't be able to stop them with a clever passphrase which is more unique than what I currently do.. Thinking along those lines then, I'm aiming to protect against lazy/stupid attackers wanting 'low hanging fruit' as it were, vs the big boys who probably have other ways of pulling these secrets from me.... I maintain a completely different passphrase schema for my personal keys -- either way, that's how I do it; seems good enough for me.. Any thoughts?

jamiesonbecker 10y ago
You don't need to use different keys for each customer.. it's not a problem to just provide the same public key for all of them. However, if you have several different access devices (i.e., laptop and desktop), you should definitely have different keys on those. (disclaimer: I work for Userify)
- cyberpunk 10y ago
  I disagree -- you really do need to; I tend to need to use ssh -A on my clients (jump boxes, etc) -- and the agent I will only have their key in it -- if one of the other staff with root on the bounce box, or an attacker, grabs my auth sock, then the keys only let them further into that one client, instead of pwning all my others... Or say, someone pwning a dev jenkins box doesn't get an agent connection which lets them into prod...
  - cuu508 10y ago
    Any other reasons for separate keys, if I don't use ssh -A?
    - cyberpunk 10y ago
      Not really. Think of each key as, well, a key.. If you used the same key in every lock in your house, that might be ok... Sometimes, though, you need to be more careful -- the only motivation for using more than one is to limit the damage someone getting a copy of that key does, right?
  - deleted 10y ago
    [deleted]
  - philsnow 10y ago
    You (probably) don't need to use -A to use a jump box. SSH agent forwarding with -A is unsafe on shared jump boxes where either 1) anybody else has root on the jump box or 2) everybody uses a shared account on the shared jump box, because the connection to your agent can be hijacked and used to authenticate as "you" elsewhere. Look at ssh's -W or -J options (depending on how old your ssh client is), or see e.g. [0]. [0] https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts#Jump_Hosts_--_Passing_through_a_gateway_or_two https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...

lastofus 10y ago

For backing up your keys, they can be encrypted to a device with full disk encryption, or to a mountable disk image that's encrypted, and then push that file off site. As for access if you lose a key, unless you somehow run a VPS that also uses full-disk encryption (and requires a passphrase on boot), then your hosting provider has access to your VPS. For instance, with DO or Linode, you can log in to the admin console and reset the root password of a server. Once done, you can use the terminal built into the admin panel to access to the server even if SSH is disabled. Presumably, someone could work with the provider, prove you are dead, and that they should gain access to your servers. At that point it would come down to the policy of the hosting provider.

cyberpunk 10y ago
An account that can only login on the local ptys is a good enough backup plan. The disk encryption doesn't buy you much in such an environment, though... Even with whole disk encryption if you're running virtualized; then your provider can just read your VM's memory anyway... Unless your VPS is going to be forever shutdown, disk encryption under a hypervisor you don't control seems reasonably pointless -- I only use it for physical security to stop people being able to use disks they yank from physical boxes -- even then if they were motivated enough they could probably grab the memory from the server(s) and get the keys anyhow... AFAIK, there is no possible protection from this besides running your own gear. There were recently published attacks where someone managed to pull keys from other machines by abusing some either intel or vmware's memory dedupe tech bugs iirc (don't have the link handy) -- so; it's not even limited to what your provider may be doing...

jamiesonbecker 10y ago

It might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case one is compromised or assumed to be compromised. (disclosure: I work @ userify)

jlgaddis 10y ago
In addition, it might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case the third-party service you're using to manage the keys to the kingdom is compromised or assumed to be compromised.
- cyberpunk 10y ago
  Sorry to hijack this, but this is absurd. I really must have missed the story here -- people pay for a third party service to manage their private keys? ... Err. That's so illogical it's making my brain hurt to even work out why I would need to explain how illogical it is... I can't even come up with a good analogy for how wrong that whole idea is, fortunately I don't have to though since no one that has mastered 'ssh-keygen' and 'cp' would actually do so..... 2FA, okay; the service provider only has half the story. ssh-keys-as-a-service? WAT. Edit: Okay, I looked a bit more at userify and it seems to be an agent that runs on your systems which generates authorized_keys files.... From their docs: "There are two parts of the Userify installation: creating the agent (readable only by root) in /opt/userify, and setting the agent to start at bootup. Setting the agent to start at bootup is a bit trickier, but the installation process attempts to detect the server type and set it up properly." Am I reading this wrong? You hook up an agent, which runs as root, which farms out authorized_keys entries across the estate? One possible mech for deploying the agent is conf management? What the actual fuck? Why would anyone do this? Do I even need to explain why this is blowing my mind so much?
  - viraptor 10y ago
    keyegn + cp don't do everything. Unless the distribution and session killing is automated, you can't easily revoke access. Of course you could implement this fairly easily with {chef/puppet/salt/ansible/...} and ldap, but it requires time / bandwidth. This is what userify seems to give you. I'm not saying it's a good solution though. I agree that it's giving someone full access to your whole environment and it's a bad idea.