Earlier quoted context omitted.
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)
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 t…
Ask HN: What are the best practises for using SSH keys?
91–100 of 114 posts
Re: Ask HN: What are the best practises for using SSH keys?
#92Earlier quoted context omitted.
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 'ss…
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 ba…
Okay, there are a few things here.. I'm not trying to rant at the people behind this directly, there are a number of similar agent-based tools which have similar issues, so please don't take it personally...
1) If you have the ability to roll out an agent such as this, with your conf management, then you could just manage your users that way instead....
2) Even assuming that this SAAS is un-hackable (lolz), you're now in the situation where all access to every machine in your environment can be changed with a single password on some web ui you don't control, which can be accessed from anywhere.
3) This should go without saying -- I can't put too much faith in how well it's implemented -- pwn the saas, then I immediately own every system connected to it..
4) The enterprise docs talk about sitting it next to your LDAP system... If I had an ops discipline and environment which has gotten to the point where I'm dealin with LDAP, why wouldn't I just configure PAM to read my ssh keys from that, instead of this?
I understand this is one of many such products which are coming out of the lack of desire/time/staff to handle opsy-style tasks when features could be getting written (I'm planning a talk on this...)
But.. does anyone really think that the cost of spending a day wrangling ansible to manage access to your servers is worth more than giving some random third party the ability to add users to your production databases?
I've dealt with many, many different auth mechanisms up to this point. LDAP+Pam_MkHomedir, NFS, Config Management, Shared Keys, Shared Passwords, etc etc. Each have problems, but I don't think the issues with any of those are solved by this, are they?
This must be aimed solely at small startups with no ops experience, right? No one would actually put this near real data, would they?
Re: Ask HN: What are the best practises for using SSH keys?
#93Earlier quoted context omitted.
Nobody seemed to answer this question, and neither did the original blog post (besides "trust me and do it"), so maybe you can shed more light on the main point: Why are ED25519 keys better than RSA, how compatible are they with different systems, and are they worth the hassle and risk of generating and using a new one?
Note that ED25519 is more vulnerable to quantum computation than is RSA.
ECC and RSA are both ultimately going to fall to practical quantum computing, and probably over a time frame short enough that it won't matter which cipher you picked.
Re: Ask HN: What are the best practises for using SSH keys?
#94Earlier quoted context omitted.
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 ba…
But... But... Okay, there are a few things here.. I'm not trying to rant at the people behind this directly, there are a number of similar agent-based tools which have similar issues, so please don't take it personally... 1) If you have the ability to roll out an agent such as this, with your conf management, then you could just manage your users that way instead.... 2) Even assuming that this SAAS is un-hackable (lo…
I hope so. But if I'm wrong, I'd like to hear from the actual users what do they get out of it.
Re: Ask HN: What are the best practises for using SSH keys?
#95Earlier quoted context omitted.
FDE leaves very few if any opportunities for accidentally spilling cleartext secrets onto the disk. If by home encryption, I assume you mean some encrypted container (or encrypted document). Consider what you "DO" with the decrypted contents.. often you are copying them out to perform some action (authentication, etc).. Are you certain the apps you use and your clipboard won't be paged to disk temporarily? If secrets…
The default encryption on Ubuntu, if you select 'Encrypt my home folder' during setup, uses ecryptfs on your home folder, and cryptswap for swap. For some reason, /tmp/ isn't encrypted by default as far as I can tell. AFAIK the main benefit is: if you want to run a multi-user or headless system, you need the network stack brought up before a password is entered - which home directory encryption provides and FDE can't…
It does not give any extra benefit because tmpfs only resides in RAM, and disk encryption typically only concerns data at rest.
If you come to a point where you want to have /tmp/ encrypted, you would rather encrypt the whole RAM. (Does anyone actually do that?)
Re: Ask HN: What are the best practises for using SSH keys?
#96Earlier quoted context omitted.
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)
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 t…
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_J...
Re: Ask HN: What are the best practises for using SSH keys?
#97 Is it better to use a different passphrase on each key, or does using the same one not matter much?
If the keys are for the same thing (i.e. your personal `id_rsa` and `id_ed25519`), then I'd personally be comfortable with the same passphrase. Different passphrases should be used for different purposes (e.g. you shouldn't use your personal passphrase on work-specific keys). How much less secure is it to not use a passphrase on a key?
Depends on the situation. I personally err on the side of caution and use a passphrase on all keys unless it's not physically possible.If you expect to be moving your SSH keys across machines (e.g. to use your same personal key on both your laptop and your desktop), then they should absolutely be passphrase-protected, even if they're only transferred via encrypted media.
Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?
There's not really a right or wrong answer to this besides "don't reuse the same key everywhere". I personally maintain one key (really two: one RSA, one ED25519) for all of my personal devices, and maintain a strict policy of full-disk encryption on such devices. I've occasionally maintained separate work keys so that I'm not ever in a position where I need to make my personal keys available to an employer.Meanwhile, for situations where a server needs to connect to another machine via SSH, each such server gets its own key. That way, if a server is compromised or decommissioned, I can revoke access by key.
Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?
It makes a significant difference. More bits → exponentially more attempts required to brute-force it. How/Where should private keys be stored on a device using them?
Depends on the device.A reasonable balance between security and practicality is for any portable media (including portable devices, like laptops/tablets/phones) to be encrypted (in addition to the key itself being passphrase-protected). Better security would be to extend this to non-portable media and machines as well (but this is painful to enforce on servers unless you have physical access).
The directory in which keys are stored should only be accessible to the OS user actually using those keys (so, for example, `~/.ssh` should have permissions `drwx------` when viewing with `ls -la`).
Basically, server SSH keys should be treated like you'd treat your SSL/TLS keys.
What are some of the pros and cons from a security standpoint
...of? and how may doing different things affect the usability of a key?
Pretty much everything involves security v. convenience tradeoffs. Generally, the more secure, the less convenient, and vice versa. While absolute security is ideal, a lack of convenience makes it more difficult to effectively enforce (e.g. as part of a company-wide security policy) unless you're willing to put in the work to build up an effective workflow around it.Re: Ask HN: What are the best practises for using SSH keys?
#98Earlier quoted context omitted.
And what is hard exactly about acquiring blank Java cards? Not harder than ordering anything else over the Internet.
Well, finding a reliable seller in Europe seems to be hard.
Or if you have a friend that knows Russian you can use this http://www.smart-card.ru/_catalog/?search=jcop
Re: Ask HN: What are the best practises for using SSH keys?
#99Re: Ask HN: What are the best practises for using SSH keys?
#100Earlier quoted context omitted.
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.
Userify is available as on-premise too. (btw I strongly agree with you... we're offering 5 server enterprise license model and we're looking at an unlimited stripped-down free version.) Also, you're probably running servers at a third party hypervisor already.. ;) they could be scanning your RAM and reading your disk and you'd never know.
I certainly wasn't trying to shit on you (or your company/employer) personally... but to me the idea of turning over ultimate control of all my servers, data, etc., to some unknown third-party and simply trusting them is absolutely fucking absurd.
I pretty much agree with everything cyberpunk said in this thread. I've been around long enough that it shouldn't but some of the things people do with regard to security sometimes surprises me and just leaves me standing there with my mouth hanging open, saying "WTF?".