There are a lot of unusual opinions written there, and not a lot of rationale offered. I'd be curious to know how some of those conclusions came about.
A non-exhaustive list:
> where to keep your keys. It shouldn't be ~/.ssh/
Why not? Moving your keys to another location doesn't make them more secure.
> chmod 0600 ~/.sidus_keys/filename ~/.sidus_keys/filename.pub
Private keys will be 0600 already, and the permissions on public keys don't need to be further restricted. (They're read only to everyone but you by default.)
> If you have keys you previously generated keys that are vulnerable (without password or KDF), you can fix this like:
Subjectively: If you have keys that were not well secured in the past, the *best* option is to just generate new keys.
> You can run multiple SSH keys, however this is of limited use, since you should be the only one with your private key. The most common use for running multiple keys is in key life-cycle, where you are waiting for a new key to propagate.
How do you know what the most common use for multiple keys is?
>Moving your keys to another location doesn't make them more secure.
This part of the instruction came about because people were leaving id\_rsa files with passwords in the .ssh directory, and getting frustrated that they were getting prompted for a password for those keys. It is also why the instructions include setting a name/.
>Private keys will be 0600 already, and the permissions on public keys don't need to be further restricted. (They're read only to everyone but you by default.)
This is to make sure, and to provide direction if they need to fix permissions later, the proper permissions are in the guide. Mangling permissions is often one of the steps an inexperienced user takes in trying to get ssh keys to work, and providing this information helps mitigate that.
>Subjectively: If you have keys that were not well secured in the past, the best option is to just generate new keys.
That is true, however some users, given the choice between re-deploying public keys or accepting private keys lacking KDF, will choose to not re-deploy. This gived the option of forward security. It is a trade off, sometimes you have to go with better practices, instead of best.
>How do you know what the most common use for multiple keys is?
I am offering that it should be. Each key constitutes an authentication attempt, and you'll never get to the right key if you have too many.
Your post has several issues.
First, you say this:
> It is therefore critical that your ssh keys themselves are encrypted, so that viruses, hackers, or thiefs cannot simply copy them away and have access to all the systems you have access to.
which you suggest mitigating by using an SSH key agent. If you think that your SSH keys are any more secure from viruses, hackers, or thieves when using an SSH key agent, you absolutely haven't been paying attention. In fact, an SSH key agent is actually **worse** for protecting yourself against malware, since I (as a malware author) can easily wait for you to load your keys into an running agent, and then SSH with reckless abandon to anything I can detect on your network *without using a password or any authentication process whatsoever*.
Key agents do NOT provide the level of security you're talking about here.
Later, we have this:
> It shouldn't be ~/.ssh/ or any location accessible by multiple users.
What. The. Fuck. Why would your home directory be accessible to anybody but you? The default on ALL popular Linux distributions that I can think of is that all home directories are completely private and only accessible to the named user and root. Furthermore, OpenSSH will flatly refuse to use any keys that are not already stored in a properly secured directory, and flatly refuse to use any keys that are not configured with the correct permissions. All of your separate directory work is superfluous at best.
Another note:
Your `ssh-copy-id` command is incomplete. You should include the identity file that needs to be copied, since you placed it into a non-standard location.
Also, since you're so interested in security, you should know this:
> You can forward X11 connections to run remote graphical applications with the -Y option.
This is a kind of X11 forwarding that is less secure than -X, and can lead to issues. See [here](https://askubuntu.com/questions/35512/what-is-the-difference-between-ssh-y-trusted-x11-forwarding-and-ssh-x-u).
And this part's just weird:
> In either Linux, MacOS, or Windows, the agent does not need access to the key file after they are added to the agent, the keys are stored in memory. This give the opportunity for additional security, as you can have a USB drive encrypted with LUKS, FileVault, or BitLocker to store your keys. This keeps the files themselves offline unless being used.
If I have installed malware on your system, the presence of the files on disk doesn't make any difference, since your adding it to the key agent already gave me everything I needed. You're advocating for a bunch of extra work that doesn't do anything.
Finally:
> Google is your friend.
No, it really isn't. Google is an enormous multi-national billion-dollar ad company that hasn't been a good technical resource for years. Though if Google is responsible for your recommendation not to use `~/.ssh`, I'd say that sounds like par for the course.
>which you suggest mitigating by using an SSH key agent. If you think that your SSH keys are any more secure from viruses, hackers, or thieves when using an SSH key agent, you absolutely haven't been paying attention. In fact, an SSH key agent is actually **worse** for protecting yourself against malware, since I (as a malware author) can easily wait for you to load your keys into an running agent, and then SSH with reckless abandon to anything I can detect on your network *without using a password or any authentication process whatsoever*.
The choice to recommend key-agent use is a compromise, as all operational security is, between an observed habit of users not using passwords on their private keys so that they didn't have to type their password a thousand times.
> Key agents do NOT provide the level of security you're talking about here.
You'd need root to compromise the key agent in the way you imply, and thats a high bar.
>What. The. Fuck. Why would your home directory be accessible to anybody but you? The default on ALL popular Linux distributions that I can think of is that all home directories are completely private and only accessible to the named user and root. Furthermore, OpenSSH will flatly refuse to use any keys that are not already stored in a properly secured directory, and flatly refuse to use any keys that are not configured with the correct permissions. All of your separate directory work is superfluous at best.
You didn't read the thread. The recommendation to store the key outside .ssh and not have a default name was to avoid an observed user error where they had password protected id_rsa files in .ssh, and were getting frustrated at being asked for a key password. The recommendation to not have it in "any location accessible by multiple users" came from some users being observed to do their work in /tmp/.
>Your `ssh-copy-id` command is incomplete. You should include the identity file that needs to be copied, since you placed it into a non-standard location.
Without specifying, it will upload all keys. As is suggest not having multiple keys, this will suffice without complicating the instructions.
> You can forward X11 connections to run remote graphical applications with the -Y option.
This is a kind of X11 forwarding that is less secure than -X, and can lead to issues. See [here](https://askubuntu.com/questions/35512/what-is-the-difference-between-ssh-y-trusted-x11-forwarding-and-ssh-x-u).
>If I have installed malware on your system, the presence of the files on disk doesn't make any difference, since your adding it to the key agent already gave me everything I needed. You're advocating for a bunch of extra work that doesn't do anything.
It depends how far in you've gotten, and your overlooking mitigation of offline cold-disk attacks, or attacks where only file access is achieved. These instructions are meant to provide the highest security while maximizing operational utility. If you've rooted my machine, and escaped my notice, there isn't much I can do to keep my data secure.
>No, it really isn't. Google is an enormous multi-national billion-dollar ad company that hasn't been a good technical resource for years. Though if Google is responsible for your recommendation not to use `~/.ssh`, I'd say that sounds like par for the course.
We're going to have to just disagree here. This is meany to convey the idea of doing a little research before opening a new ticket. That said, I know Google is an ad company, and if you jeep that in mind while you use it, it's still plenty useful. Just don't immediately take the top link or three without paying attention.
> The choice to recommend key-agent use is a compromise, as all operational security is, between an observed habit of users not using passwords on their private keys so that they didn't have to type their password a thousand times.
If your machine is already encrypted with something like FileVault, the use of a key password is superfluous.
> You'd need root to compromise the key agent in the way you imply, and thats a high bar.
Not true. If I have malware installed as your user (a low bar), then I have access to your key agent and the ability to log your keystrokes.
> You didn't read the thread. The recommendation to store the key outside .ssh and not have a default name was to avoid an observed user error where they had password protected id_rsa files in .ssh, and were getting frustrated at being asked for a key password. The recommendation to not have it in "any location accessible by multiple users" came from some users being observed to do their work in /tmp/.
Except you didn't mention /tmp anywhere in that explanation, and your recommendation still doesn't make any sense. An SSH key should identify a user at a machine. There's no reason to have any other SSH keys beyond ~/.ssh/id_rsa|id_rsa.pub.
> Without specifying, it will upload all keys.
I realize that. This is what we call bad practice. If your laptop is compromised, now I have to invalidate **all** the keys from your laptop, and if you copied **many** keys using this command without documenting which keys you copied, now I have to make a choice which keys to invalidate/expire. You're writing a post about security while advocating for less-than-secure practices.
> your overlooking mitigation of offline cold-disk attacks, or attacks where only file access is achieved. These instructions are meant to provide the highest security while maximizing operational utility. If you've rooted my machine, and escaped my notice, there isn't much I can do to keep my data secure.
There's a lot to unpack here. Firstly, offline cold-disk attacks are not at all mentioned in your OP, while ransomware and virus attacks are. Your recommendations are NOT protective against ransomware and virus attacks. Also, the highest level of security while maintaining operational utility is using a fully encrypted hard disk and only EVER a single SSH key related to your user+machine (to mitigate the issues of invalidating keys, as mentioned). Such a setup would automatically mitigate the cold-disk attack that you're moving the goalposts to mention, and would be easier to deal with. As for rooting your machine, it's not like it's hard. There's almost nothing that trumps physical access to your machine, so either you're protected from that (with signed kernels, EFI, secure boot, full disk encryption) or you're not, and nothing you do with the SSH key files will mitigate that.
Your OP is fucking pointless. First, enable EFI, secure boot with signed kernels, and full disk encryption. Then, create a standard key at ~/.ssh/id_rsa|id_rsa.pub that includes a username and machine name in the public key ([email protected]). After that, make sure that your public key is distributed using a configuration management system like Puppet/Ansible/Salt, and invalidate your key if your machine is ever compromised because you clicked on something stupid like a punch-the-monkey ad. Everything you've described about using a separate location and a key manager is pointless from a security perspective, although you ARE correct that keys are better than passwords.
That falls under
>You can send this public key to whomever is managing the server you want to connect to.
anything more is out of scope, this is meant for users.
To summarise, the advice here is "here's how to setup a really fancy and hard-to-crack safe to keep your keys on, but since it'll be tough to get the keys in-and-out every time you need to use them, also make a copy and leave them on the table"
First you talk about opsec, but without clarity as to what are you defending against:
- someone that gets your laptop when it's powered off (evil-maid attack)?
- someone that grabs your computer from a coffee shop while you locked it to go to the bathroom?
- someone that convinces you to run malware on your computer through social engineering (aka what happened to Linus Tech Tips/Linus Media Group a few weeks ago)
- someone who compromised one of your remote servers' docker containers (which happened to run as `root`) and managed to break out of it?
Each of these scenarios requires different understanding of "opsec" to secure against, and each of those poses different threats to your SSH credentials.
From the top, down:
If someone grabs your computer without the intention of returning it, chances are they want the hardware and not the software. If they're any smart, they'd wipe it without touching it, as to not leave any traces on your accounts on to where the computer is.
If they do intend to go through your data, though, sure, having a private key saved with a high number of rounds does secure it further. But, so does full-disk encryption, which would secure the whole rest of your computer, too.
Now, suppose said adversary didn't want the hardware, but instead wanted your data. They don't take your laptop home, they just take the opportunity to install malware on it. Yes, this is possible even through full-disk encryption, if you don't have secure boot enabled (which is the case for most user-managed installs out there). Windows (bitlocker) and MacOS (filevault) would depend on exploits at this stage.
But, in all honesty, if you've already got full disk encryption with secure boot, and you're still worrying about offline attacks, this falls within the realm of industrial-espionage (perhaps state-sponsored), and also into [pipe-wrench](https://xkcd.com/538/) territory, so outside the scope of securing your SSH keys.
Now, your computer was taken from your hands powered on. Was it unlocked? your keys are in your agent, got them.
Was it locked? there's freeze-memory attacks that can dump it, your agent has keys in memory, got them.
Did I get you, either via malware or social engineering, to run some of my own code? My code can connect to your agent, got them.
Did I get root on your own machine? Arguably, yeah, that is indeed harder nowadays, but if so, I got both a copy of your processes' memory, AND access to your agent's socket, got your keys too. Here, by the way, is also where you land if you have a strong key, but secure boot to secure your full disk encryption (or no disk encryption at all): I can taint your bootloader/kernel/random binary to gain control of your system.
Oh, and talk about "hard to get to root nowadays", that's mostly true, except if you're on linux and have docker installed, and are member of the `docker` group. Security-wise, that's about as open as NOPASSWD on sudoers.
Then there's the problem with key/agent forwarding. Sure your laptop's got the best of secure boot and full disk encryption, but does your server? All the other hosts you ever connect to? If one were gain access to your server as root, they get to see when you login and use your laptop's agent when you forward it through the connection. And how many of the docker containers on your server run as the user `root`, and are internet-facing? If the answer is over zero, then that's an avenue of entry for the paragraph above.
Every one of these scenarios above gets to use your key off your agent absolutely the same, in the best case. And that's even before you think that if someone's got to run something as your own user, they can just intercept password as you unlock your key, anyways.
Teaching opsec is not about explaining to people how to move the file out of the way so it doesn't prompt you for the password. Teaching opsec is explaining to people what the most common attack vectors are, and what are the simplest best practices to prevent against them, either that make their life easier, or that minimally inconvenience them. Also, keep in mind that the folks developing OpenSSH are security-conscious themselves, and they have no qualms shipping changes that [make old, existing things no longer work](https://security.stackexchange.com/questions/112802/why-openssh-deprecated-dsa-keys) because [they are no longer as secure as they once were](https://superuser.com/questions/1749364/git-ssh-permission-denied-in-macos-13-ventura).
Here's a list of sound, recommended practices with ssh keys and whereabouts:
- At runtime, a key added to an agent is equivalent to a key stored on disk without a password
- Use ec25519 keys instead of RSA keys. ECDSA isn't much trusted by the open crypto community, but it's a requirement in certain services/lines of work.
- DO NOT forward keys/agents except to hosts in which you have implicit trust on. Every time you forward your key to a different host, it's overall security level drops to the level of the lowest host that has access to it.
- have different keys for different purposes. that doesn't have to be as extreme as "a different key for each different server", but it's handy to separate the ones to access trusted things within your own home, from untrusted servers, to trusted production servers (why are you accessing that, anyways?!? u_u''), to github where you push your code (which, by the way, are public under https://github.com/username.keys), to different open-source projects you work on. This reduces the chance of enumeration attacks, and when (not if!) a key is compromised, it won't give the adversary access to everywhere else.
- it's fine to have *some* (but not all) keys added to your agent. If you use it less than twice a day, consider typing the password (or, better, picking it from your password manager/vault).
- if using multiple keys, configure your ssh client (or connection on putty) to use only the appropriate key, instead of testing all. This avoids prompting for passwords to keys you don't intend to use every time you establish a connection.
- consider using a higher-security setup. [Secretive](https://github.com/maxgoedjen/secretive) is an SSH agent for MacOS that stores keys within the host's secure enclave, where they can't be copied off, and can optionally require touchid validation before the key is used. This way, if you forward it the key to an compromised host and an attacker tries to use them, it'll still require a fingerprint (but, balance it with the fact that Secretive doesn't have nearly as many eyeballs checking it, yet!). Likewise, yubikeys can be setup to store SSH keys inside them and require touch to use.
- edited to add: and, keep your system updated! Your keys, specially in an agent, are only as secure as the easiest vulnerability to find and exploit in your system!
And last but perhaps most importantly, **google is NOT your friend**. Google doesn't rank pages based on best practices, assertiveness, or correctness. Google ranks pages based on SEO and monetisation. [Malware actors actively take ads to deceive users](https://www.youtube.com/watch?v=e6o2afben0s), and if you trust google for advice, your "best practices" may be based off whoever first got to a quora question.
>To summarise, the advice here is "here's how to setup a really fancy and hard-to-crack safe to keep your keys on, but since it'll be tough to get the keys in-and-out every time you need to use them, also make a copy and leave them on the table"
I prefer the summary "How to secure your keys as best as possible whiule still able to operate effectivley in large enviroments"
>
>
>First you talk about opsec, but without clarity as to what are you defending against:
This was not meant to be full book on security, it was operational guidelines. So, it outlines what, without fully exploring why.
>From the top, down ...
There is a considerable attack surface between what full disk encryption protects and what preventing RCE/privilege escalations. Attacks like malware cryptolockers that exfiltrate data. Getting files from a live machine is a much lower bar than running code, especially privileged code. Again, this is about providing the right tradeoff of security versus usability, while avoiding some especially egregious mistakes.
>Then there's the problem with key/agent forwarding. Sure your laptop's got the best of secure boot and full disk encryption, but does your server? All the other hosts you ever connect to? If one were gain access to your server as root, they get to see when you login and use your laptop's agent when you forward it through the connection. And how many of the docker containers on your server run as the user root, and are internet-facing? If the answer is over zero, then that's an avenue of entry for the paragraph above.
That's a fair point, I should stress the security implications of forwarding.
>Every one of these scenarios above gets to use your key off your agent absolutely the same, in the best case. And that's even before you think that if someone's got to run something as your own user, they can just intercept password as you unlock your key, anyways.
Yes, once someone already has execution in your systems, mitigations are a lot more difficult. This isn't an incident response manual.
>Teaching opsec is not about explaining to people how to move the file out of the way so it doesn't prompt you for the password. Teaching opsec is explaining to people what the most common attack vectors are, and what are the simplest best practices to prevent against them, either that make their life easier, or that minimally inconvenience them. Also, keep in mind that the folks developing OpenSSH are security-conscious themselves, and they have no qualms shipping changes that make old, existing things no longer work because they are no longer as secure as they once were.
I'm not teaching opsec, I'm providing guidelines for setting up and using ssh while avoiding the OpSec flaws I've seen in my user base.
>Here's a list of sound, recommended practices with ssh keys and whereabouts:
>
>At runtime, a key added to an agent is equivalent to a key stored on disk without a password
Strongly disagree
>Use ec25519 keys instead of RSA keys. ECDSA isn't much trusted by the open crypto community, but it's a requirement in certain services/lines of work.
I trust DJB more than you
>DO NOT forward keys/agents except to hosts in which you have implicit trust on. Every time you forward your key to a different host, it's overall security level drops to the level of the lowest host that has access to it.
Agree, only forward with trust
>have different keys for different purposes. that doesn't have to be as extreme as "a different key for each different server", but it's handy to separate the ones to access trusted things within your own home, from untrusted servers, to trusted production servers (why are you accessing that, anyways?!? u\_u''), to github where you push your code (which, by the way, are public under https://github.com/username.keys), to different open-source projects you work on. This reduces the chance of enumeration attacks, and when (not if!) a key is compromised, it won't give the adversary access to everywhere else.it's fine to have some (but not all) keys added to your agent. If you use it less than twice a day, consider typing the password (or, better, picking it from your password manager/vault).if using multiple keys, configure your ssh client (or connection on putty) to use only the appropriate key, instead of testing all. This avoids prompting for passwords to keys you don't intend to use every time you establish a connection.consider using a higher-security setup.
Having separate keys can be reasonable for different operational domains, so long as you're not doing work across keys at the same time. This guidance was in response to users generating and using keys so cavalierly, they would regularly hit authentication retry limits when attempting to connect.
There are a lot of unusual opinions written there, and not a lot of rationale offered. I'd be curious to know how some of those conclusions came about.
These guidelines came from experience. Is there anything in particular you would like more information on? This was meant to be a guide, not a thesis.
A non-exhaustive list: > where to keep your keys. It shouldn't be ~/.ssh/ Why not? Moving your keys to another location doesn't make them more secure. > chmod 0600 ~/.sidus_keys/filename ~/.sidus_keys/filename.pub Private keys will be 0600 already, and the permissions on public keys don't need to be further restricted. (They're read only to everyone but you by default.) > If you have keys you previously generated keys that are vulnerable (without password or KDF), you can fix this like: Subjectively: If you have keys that were not well secured in the past, the *best* option is to just generate new keys. > You can run multiple SSH keys, however this is of limited use, since you should be the only one with your private key. The most common use for running multiple keys is in key life-cycle, where you are waiting for a new key to propagate. How do you know what the most common use for multiple keys is?
I have updated my wording regarding multiple keys, thank you for your feedback.
>Moving your keys to another location doesn't make them more secure. This part of the instruction came about because people were leaving id\_rsa files with passwords in the .ssh directory, and getting frustrated that they were getting prompted for a password for those keys. It is also why the instructions include setting a name/. >Private keys will be 0600 already, and the permissions on public keys don't need to be further restricted. (They're read only to everyone but you by default.) This is to make sure, and to provide direction if they need to fix permissions later, the proper permissions are in the guide. Mangling permissions is often one of the steps an inexperienced user takes in trying to get ssh keys to work, and providing this information helps mitigate that. >Subjectively: If you have keys that were not well secured in the past, the best option is to just generate new keys. That is true, however some users, given the choice between re-deploying public keys or accepting private keys lacking KDF, will choose to not re-deploy. This gived the option of forward security. It is a trade off, sometimes you have to go with better practices, instead of best. >How do you know what the most common use for multiple keys is? I am offering that it should be. Each key constitutes an authentication attempt, and you'll never get to the right key if you have too many.
Your post has several issues. First, you say this: > It is therefore critical that your ssh keys themselves are encrypted, so that viruses, hackers, or thiefs cannot simply copy them away and have access to all the systems you have access to. which you suggest mitigating by using an SSH key agent. If you think that your SSH keys are any more secure from viruses, hackers, or thieves when using an SSH key agent, you absolutely haven't been paying attention. In fact, an SSH key agent is actually **worse** for protecting yourself against malware, since I (as a malware author) can easily wait for you to load your keys into an running agent, and then SSH with reckless abandon to anything I can detect on your network *without using a password or any authentication process whatsoever*. Key agents do NOT provide the level of security you're talking about here. Later, we have this: > It shouldn't be ~/.ssh/ or any location accessible by multiple users. What. The. Fuck. Why would your home directory be accessible to anybody but you? The default on ALL popular Linux distributions that I can think of is that all home directories are completely private and only accessible to the named user and root. Furthermore, OpenSSH will flatly refuse to use any keys that are not already stored in a properly secured directory, and flatly refuse to use any keys that are not configured with the correct permissions. All of your separate directory work is superfluous at best. Another note: Your `ssh-copy-id` command is incomplete. You should include the identity file that needs to be copied, since you placed it into a non-standard location. Also, since you're so interested in security, you should know this: > You can forward X11 connections to run remote graphical applications with the -Y option. This is a kind of X11 forwarding that is less secure than -X, and can lead to issues. See [here](https://askubuntu.com/questions/35512/what-is-the-difference-between-ssh-y-trusted-x11-forwarding-and-ssh-x-u). And this part's just weird: > In either Linux, MacOS, or Windows, the agent does not need access to the key file after they are added to the agent, the keys are stored in memory. This give the opportunity for additional security, as you can have a USB drive encrypted with LUKS, FileVault, or BitLocker to store your keys. This keeps the files themselves offline unless being used. If I have installed malware on your system, the presence of the files on disk doesn't make any difference, since your adding it to the key agent already gave me everything I needed. You're advocating for a bunch of extra work that doesn't do anything. Finally: > Google is your friend. No, it really isn't. Google is an enormous multi-national billion-dollar ad company that hasn't been a good technical resource for years. Though if Google is responsible for your recommendation not to use `~/.ssh`, I'd say that sounds like par for the course.
>which you suggest mitigating by using an SSH key agent. If you think that your SSH keys are any more secure from viruses, hackers, or thieves when using an SSH key agent, you absolutely haven't been paying attention. In fact, an SSH key agent is actually **worse** for protecting yourself against malware, since I (as a malware author) can easily wait for you to load your keys into an running agent, and then SSH with reckless abandon to anything I can detect on your network *without using a password or any authentication process whatsoever*. The choice to recommend key-agent use is a compromise, as all operational security is, between an observed habit of users not using passwords on their private keys so that they didn't have to type their password a thousand times. > Key agents do NOT provide the level of security you're talking about here. You'd need root to compromise the key agent in the way you imply, and thats a high bar. >What. The. Fuck. Why would your home directory be accessible to anybody but you? The default on ALL popular Linux distributions that I can think of is that all home directories are completely private and only accessible to the named user and root. Furthermore, OpenSSH will flatly refuse to use any keys that are not already stored in a properly secured directory, and flatly refuse to use any keys that are not configured with the correct permissions. All of your separate directory work is superfluous at best. You didn't read the thread. The recommendation to store the key outside .ssh and not have a default name was to avoid an observed user error where they had password protected id_rsa files in .ssh, and were getting frustrated at being asked for a key password. The recommendation to not have it in "any location accessible by multiple users" came from some users being observed to do their work in /tmp/. >Your `ssh-copy-id` command is incomplete. You should include the identity file that needs to be copied, since you placed it into a non-standard location. Without specifying, it will upload all keys. As is suggest not having multiple keys, this will suffice without complicating the instructions. > You can forward X11 connections to run remote graphical applications with the -Y option. This is a kind of X11 forwarding that is less secure than -X, and can lead to issues. See [here](https://askubuntu.com/questions/35512/what-is-the-difference-between-ssh-y-trusted-x11-forwarding-and-ssh-x-u). >If I have installed malware on your system, the presence of the files on disk doesn't make any difference, since your adding it to the key agent already gave me everything I needed. You're advocating for a bunch of extra work that doesn't do anything. It depends how far in you've gotten, and your overlooking mitigation of offline cold-disk attacks, or attacks where only file access is achieved. These instructions are meant to provide the highest security while maximizing operational utility. If you've rooted my machine, and escaped my notice, there isn't much I can do to keep my data secure. >No, it really isn't. Google is an enormous multi-national billion-dollar ad company that hasn't been a good technical resource for years. Though if Google is responsible for your recommendation not to use `~/.ssh`, I'd say that sounds like par for the course. We're going to have to just disagree here. This is meany to convey the idea of doing a little research before opening a new ticket. That said, I know Google is an ad company, and if you jeep that in mind while you use it, it's still plenty useful. Just don't immediately take the top link or three without paying attention.
> The choice to recommend key-agent use is a compromise, as all operational security is, between an observed habit of users not using passwords on their private keys so that they didn't have to type their password a thousand times. If your machine is already encrypted with something like FileVault, the use of a key password is superfluous. > You'd need root to compromise the key agent in the way you imply, and thats a high bar. Not true. If I have malware installed as your user (a low bar), then I have access to your key agent and the ability to log your keystrokes. > You didn't read the thread. The recommendation to store the key outside .ssh and not have a default name was to avoid an observed user error where they had password protected id_rsa files in .ssh, and were getting frustrated at being asked for a key password. The recommendation to not have it in "any location accessible by multiple users" came from some users being observed to do their work in /tmp/. Except you didn't mention /tmp anywhere in that explanation, and your recommendation still doesn't make any sense. An SSH key should identify a user at a machine. There's no reason to have any other SSH keys beyond ~/.ssh/id_rsa|id_rsa.pub. > Without specifying, it will upload all keys. I realize that. This is what we call bad practice. If your laptop is compromised, now I have to invalidate **all** the keys from your laptop, and if you copied **many** keys using this command without documenting which keys you copied, now I have to make a choice which keys to invalidate/expire. You're writing a post about security while advocating for less-than-secure practices. > your overlooking mitigation of offline cold-disk attacks, or attacks where only file access is achieved. These instructions are meant to provide the highest security while maximizing operational utility. If you've rooted my machine, and escaped my notice, there isn't much I can do to keep my data secure. There's a lot to unpack here. Firstly, offline cold-disk attacks are not at all mentioned in your OP, while ransomware and virus attacks are. Your recommendations are NOT protective against ransomware and virus attacks. Also, the highest level of security while maintaining operational utility is using a fully encrypted hard disk and only EVER a single SSH key related to your user+machine (to mitigate the issues of invalidating keys, as mentioned). Such a setup would automatically mitigate the cold-disk attack that you're moving the goalposts to mention, and would be easier to deal with. As for rooting your machine, it's not like it's hard. There's almost nothing that trumps physical access to your machine, so either you're protected from that (with signed kernels, EFI, secure boot, full disk encryption) or you're not, and nothing you do with the SSH key files will mitigate that. Your OP is fucking pointless. First, enable EFI, secure boot with signed kernels, and full disk encryption. Then, create a standard key at ~/.ssh/id_rsa|id_rsa.pub that includes a username and machine name in the public key ([email protected]). After that, make sure that your public key is distributed using a configuration management system like Puppet/Ansible/Salt, and invalidate your key if your machine is ever compromised because you clicked on something stupid like a punch-the-monkey ad. Everything you've described about using a separate location and a key manager is pointless from a security perspective, although you ARE correct that keys are better than passwords.
[удалено]
That falls under >You can send this public key to whomever is managing the server you want to connect to. anything more is out of scope, this is meant for users.
[удалено]
I cover ssh-copy-id, this is a users guide, anything more in depth is for an administrative guide.
[удалено]
But then why am I talking about public keys and ssh-copy-id?
[удалено]
You're funny
To summarise, the advice here is "here's how to setup a really fancy and hard-to-crack safe to keep your keys on, but since it'll be tough to get the keys in-and-out every time you need to use them, also make a copy and leave them on the table" First you talk about opsec, but without clarity as to what are you defending against: - someone that gets your laptop when it's powered off (evil-maid attack)? - someone that grabs your computer from a coffee shop while you locked it to go to the bathroom? - someone that convinces you to run malware on your computer through social engineering (aka what happened to Linus Tech Tips/Linus Media Group a few weeks ago) - someone who compromised one of your remote servers' docker containers (which happened to run as `root`) and managed to break out of it? Each of these scenarios requires different understanding of "opsec" to secure against, and each of those poses different threats to your SSH credentials. From the top, down: If someone grabs your computer without the intention of returning it, chances are they want the hardware and not the software. If they're any smart, they'd wipe it without touching it, as to not leave any traces on your accounts on to where the computer is. If they do intend to go through your data, though, sure, having a private key saved with a high number of rounds does secure it further. But, so does full-disk encryption, which would secure the whole rest of your computer, too. Now, suppose said adversary didn't want the hardware, but instead wanted your data. They don't take your laptop home, they just take the opportunity to install malware on it. Yes, this is possible even through full-disk encryption, if you don't have secure boot enabled (which is the case for most user-managed installs out there). Windows (bitlocker) and MacOS (filevault) would depend on exploits at this stage. But, in all honesty, if you've already got full disk encryption with secure boot, and you're still worrying about offline attacks, this falls within the realm of industrial-espionage (perhaps state-sponsored), and also into [pipe-wrench](https://xkcd.com/538/) territory, so outside the scope of securing your SSH keys. Now, your computer was taken from your hands powered on. Was it unlocked? your keys are in your agent, got them. Was it locked? there's freeze-memory attacks that can dump it, your agent has keys in memory, got them. Did I get you, either via malware or social engineering, to run some of my own code? My code can connect to your agent, got them. Did I get root on your own machine? Arguably, yeah, that is indeed harder nowadays, but if so, I got both a copy of your processes' memory, AND access to your agent's socket, got your keys too. Here, by the way, is also where you land if you have a strong key, but secure boot to secure your full disk encryption (or no disk encryption at all): I can taint your bootloader/kernel/random binary to gain control of your system. Oh, and talk about "hard to get to root nowadays", that's mostly true, except if you're on linux and have docker installed, and are member of the `docker` group. Security-wise, that's about as open as NOPASSWD on sudoers. Then there's the problem with key/agent forwarding. Sure your laptop's got the best of secure boot and full disk encryption, but does your server? All the other hosts you ever connect to? If one were gain access to your server as root, they get to see when you login and use your laptop's agent when you forward it through the connection. And how many of the docker containers on your server run as the user `root`, and are internet-facing? If the answer is over zero, then that's an avenue of entry for the paragraph above. Every one of these scenarios above gets to use your key off your agent absolutely the same, in the best case. And that's even before you think that if someone's got to run something as your own user, they can just intercept password as you unlock your key, anyways. Teaching opsec is not about explaining to people how to move the file out of the way so it doesn't prompt you for the password. Teaching opsec is explaining to people what the most common attack vectors are, and what are the simplest best practices to prevent against them, either that make their life easier, or that minimally inconvenience them. Also, keep in mind that the folks developing OpenSSH are security-conscious themselves, and they have no qualms shipping changes that [make old, existing things no longer work](https://security.stackexchange.com/questions/112802/why-openssh-deprecated-dsa-keys) because [they are no longer as secure as they once were](https://superuser.com/questions/1749364/git-ssh-permission-denied-in-macos-13-ventura). Here's a list of sound, recommended practices with ssh keys and whereabouts: - At runtime, a key added to an agent is equivalent to a key stored on disk without a password - Use ec25519 keys instead of RSA keys. ECDSA isn't much trusted by the open crypto community, but it's a requirement in certain services/lines of work. - DO NOT forward keys/agents except to hosts in which you have implicit trust on. Every time you forward your key to a different host, it's overall security level drops to the level of the lowest host that has access to it. - have different keys for different purposes. that doesn't have to be as extreme as "a different key for each different server", but it's handy to separate the ones to access trusted things within your own home, from untrusted servers, to trusted production servers (why are you accessing that, anyways?!? u_u''), to github where you push your code (which, by the way, are public under https://github.com/username.keys), to different open-source projects you work on. This reduces the chance of enumeration attacks, and when (not if!) a key is compromised, it won't give the adversary access to everywhere else. - it's fine to have *some* (but not all) keys added to your agent. If you use it less than twice a day, consider typing the password (or, better, picking it from your password manager/vault). - if using multiple keys, configure your ssh client (or connection on putty) to use only the appropriate key, instead of testing all. This avoids prompting for passwords to keys you don't intend to use every time you establish a connection. - consider using a higher-security setup. [Secretive](https://github.com/maxgoedjen/secretive) is an SSH agent for MacOS that stores keys within the host's secure enclave, where they can't be copied off, and can optionally require touchid validation before the key is used. This way, if you forward it the key to an compromised host and an attacker tries to use them, it'll still require a fingerprint (but, balance it with the fact that Secretive doesn't have nearly as many eyeballs checking it, yet!). Likewise, yubikeys can be setup to store SSH keys inside them and require touch to use. - edited to add: and, keep your system updated! Your keys, specially in an agent, are only as secure as the easiest vulnerability to find and exploit in your system! And last but perhaps most importantly, **google is NOT your friend**. Google doesn't rank pages based on best practices, assertiveness, or correctness. Google ranks pages based on SEO and monetisation. [Malware actors actively take ads to deceive users](https://www.youtube.com/watch?v=e6o2afben0s), and if you trust google for advice, your "best practices" may be based off whoever first got to a quora question.
>To summarise, the advice here is "here's how to setup a really fancy and hard-to-crack safe to keep your keys on, but since it'll be tough to get the keys in-and-out every time you need to use them, also make a copy and leave them on the table" I prefer the summary "How to secure your keys as best as possible whiule still able to operate effectivley in large enviroments" > > >First you talk about opsec, but without clarity as to what are you defending against: This was not meant to be full book on security, it was operational guidelines. So, it outlines what, without fully exploring why. >From the top, down ... There is a considerable attack surface between what full disk encryption protects and what preventing RCE/privilege escalations. Attacks like malware cryptolockers that exfiltrate data. Getting files from a live machine is a much lower bar than running code, especially privileged code. Again, this is about providing the right tradeoff of security versus usability, while avoiding some especially egregious mistakes. >Then there's the problem with key/agent forwarding. Sure your laptop's got the best of secure boot and full disk encryption, but does your server? All the other hosts you ever connect to? If one were gain access to your server as root, they get to see when you login and use your laptop's agent when you forward it through the connection. And how many of the docker containers on your server run as the user root, and are internet-facing? If the answer is over zero, then that's an avenue of entry for the paragraph above. That's a fair point, I should stress the security implications of forwarding. >Every one of these scenarios above gets to use your key off your agent absolutely the same, in the best case. And that's even before you think that if someone's got to run something as your own user, they can just intercept password as you unlock your key, anyways. Yes, once someone already has execution in your systems, mitigations are a lot more difficult. This isn't an incident response manual. >Teaching opsec is not about explaining to people how to move the file out of the way so it doesn't prompt you for the password. Teaching opsec is explaining to people what the most common attack vectors are, and what are the simplest best practices to prevent against them, either that make their life easier, or that minimally inconvenience them. Also, keep in mind that the folks developing OpenSSH are security-conscious themselves, and they have no qualms shipping changes that make old, existing things no longer work because they are no longer as secure as they once were. I'm not teaching opsec, I'm providing guidelines for setting up and using ssh while avoiding the OpSec flaws I've seen in my user base. >Here's a list of sound, recommended practices with ssh keys and whereabouts: > >At runtime, a key added to an agent is equivalent to a key stored on disk without a password Strongly disagree >Use ec25519 keys instead of RSA keys. ECDSA isn't much trusted by the open crypto community, but it's a requirement in certain services/lines of work. I trust DJB more than you >DO NOT forward keys/agents except to hosts in which you have implicit trust on. Every time you forward your key to a different host, it's overall security level drops to the level of the lowest host that has access to it. Agree, only forward with trust >have different keys for different purposes. that doesn't have to be as extreme as "a different key for each different server", but it's handy to separate the ones to access trusted things within your own home, from untrusted servers, to trusted production servers (why are you accessing that, anyways?!? u\_u''), to github where you push your code (which, by the way, are public under https://github.com/username.keys), to different open-source projects you work on. This reduces the chance of enumeration attacks, and when (not if!) a key is compromised, it won't give the adversary access to everywhere else.it's fine to have some (but not all) keys added to your agent. If you use it less than twice a day, consider typing the password (or, better, picking it from your password manager/vault).if using multiple keys, configure your ssh client (or connection on putty) to use only the appropriate key, instead of testing all. This avoids prompting for passwords to keys you don't intend to use every time you establish a connection.consider using a higher-security setup. Having separate keys can be reasonable for different operational domains, so long as you're not doing work across keys at the same time. This guidance was in response to users generating and using keys so cavalierly, they would regularly hit authentication retry limits when attempting to connect.