13 ms·

One of my colleagues was asking me a question about this last week. Can all/any applications running on our device read the key? They work on a mac, and wrote a

One of my colleagues was asking me a question about this last week. Can all/any applications running on our device read the key? They work on a mac, and wrote a simple python script to confirm. Any program running in the userspace can read the private key file; have the private keys always been not so private all this time?

Bootvis 4y ago
That’s why ideally you use a pass phrase with you ssh key. Apps can still read it but not use it.
- progbits 4y ago
  Even better, if possible switch to something like PGP keys on Yubikey which prevents exfiltration of the private key, and will only sign things when you enter PIN / touch the device.
  - doubled112 4y ago
    This has been my SSH key solution for a while now. Worked smoothly on most systems. Kind of messy on Windows, because there are so many SSH agent implementations, but GPG4Win's latest version works with the native SSH now. Real progress.
    - tkanarsky 4y ago
      I find that the PIV smart card stack is needlessly complicated if all you're trying to do is add a resident SSH key to your yubikey. Look at `ed25519-sk` [0], which is supported by default by recent versions of OpenSSH (and dropbear? idk) [0]: https://news.ycombinator.com/item?id=29231396 https://news.ycombinator.com/item?id=29231396
      - doubled112 4y ago
        PGP is definitely complicated if you’re not going to use it for other functionality. And that’s completely separate to the PIV functionality on the key.
        tkanarsky 4y ago
        Oh, I was under the impression that PIV referred to the smart card protocol and PGP was an application making use of that protocol, something like TCP and HTTP. Looks like I'm mistaken, thanks!
    - egberts1 4y ago
      Not the map you are looking for but there is this comparison chart of SSH clients and its algorithms. https://ssh-comparison.quendi.de/comparison/cipher.html https://ssh-comparison.quendi.de/comparison/cipher.html
      - doubled112 4y ago
        https://github.com/rupor-github/win-gpg-agent/blob/main/docs/pic1.png https://github.com/rupor-github/win-gpg-agent/blob/main/docs... Don’t forget this diagram of all the agents, protocols and bridges you might hit on Windows.
        egberts1 4y ago
        That is the scariest system diagram chart that I have ever seen. It should be a prime example of what NOT to do.
- grishka 4y ago
  But then enter it every time you need to use the key, thus negating the advantage of just magically logging in without passwords? Because if you use ssh-add and only enter the passphrase once per reboot, apps will be able to use it, that's the point.
  - Xylakant 4y ago
    You can (and should) use ssh-agent/ssh-add to handle the key for you. It will still protect you against apps reading the key - ssh-agent only performs crypto operations on behalf of programs and will not hand out the private key.
    - jesprenj 4y ago
      The app in question can just dump the memory of ssh-agent and obtain the private key from there. Or not?
      - tristor 4y ago
        Usually no. It requires root / Admin to dump memory of other processes, generally. Although vulnerabilities do exist.
        jesprenj 4y ago
        Are you sure this is how, let's say, Linux behaves? I tested it now in a minimal privilege account in a chroot on Debian 11 that I use for login from untrusted machines, and strace worked. This is how I captured a password entered into a ssh client password prompt, opened in another login shell of the same user: -bash-5.1$ ps aux | grep abcde z 2502130 0.0 0.3 9500 6132 ? S+ 18:04 0:00 ssh abcde@localhost z 2502140 0.0 0.1 6316 2336 ? S+ 18:04 0:00 grep abcde -bash-5.1$ strace -p 2502130 strace: Process 2502130 attached read(4, "s", 1) = 1 read(4, "e", 1) = 1 read(4, "c", 1) = 1 read(4, "r", 1) = 1 read(4, "e", 1) = 1 read(4, "t", 1) = 1 read(4, "\n", 1) = 1 write(4, "\n", 1) = 1 ioctl(4, TCGETS, {B38400 opost isig icanon -echo ...}) = 0
EthicalSimilar 4y ago
You can store them in the Secure Enclave on OSX and require TouchID to use the key for signing. See: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive
- cassianoleal 4y ago
  I've been using Secretive for a long time now. It's a great piece of tech. Even if you don't require TouchID, no apps will be able to upload your private keys anywhere as they never leave the enclave. Sure, they can still _use_ the keys without your permission but to do that they need to be running on the workstation. That said, TouchID is really not very inconvenient and if you couple that with control persistence, muxing and keepalive on the SSH client, it's really a no-brainer.
TheBrokenRail 4y ago
Yeah, un-sandboxed programs can access all your user files. That's why there has been such a large push for sandboxing tech like Flatpak. (In general though, you really shouldn't be running programs you don't trust in anything but a VM.)
- the_af 4y ago
  I understand the principle, but it seems too onerous on the end user. What is a program you "trust"? Something you bought online from a curated app store? Those occasionally have trojans as well. Something you downloaded? Well, if it's open source, that's the norm. Something you build from source? Most people wouldn't be able to spot an exploit hidden in the source code. So.. it's run everything sandboxed by default the recommendation for regular users? Or is it "do not download or buy anything, it's simply not safe"?
  - Taywee 4y ago
    I trust the maintainers of my distro software repositories. Any non-distro software, I want to audit before I install or it should be sandboxed. And yes. The recommendation is to not just download and run programs you find on the web.
    - the_af 4y ago
      Unfortunately I think the option you propose (sandboxing) is unreasonable for most users. A lot of the software you want to run (e.g. games, but also lots of special software, including apps/experiments featured on HN) is not available as part of your distro. It's unreasonable to expect end users to sandbox everything just in case. It may be the only think that works, but it's also an unreasonable expectation. In practice, this makes it a non-solution. A security solution must both work and be reasonably doable by most users.
      - LarryMullins 4y ago
        It doesn't have to be reasonable for most users. GNU/Linux in general isn't reasonable for most users.
pluc 4y ago
Only if they run under your user as your private key permission should be only you can read it. Programs running as you are basically you.
_def 4y ago
> have the private keys always been not so private all this time? It's not called private key because it is very secure and can't be accessed... It's on you to ensure that!
calvinmorrison 4y ago
Use a pass phrase!
- njsubedi 4y ago
  I do. Most probably they do too, but since any running apps can access the user’s private keys, the whole security depends on the strength of the passphrase that can be brute forced offline?
  - mr_mitm 4y ago
    Don't run apps you don't trust outside of a container. If there is malware on your system, your SSH keys are only one of your many troubles.
    - the_af 4y ago
      What are apps you do trust?
  - throwaway290 4y ago
    Use a long one.
  - jeroenhd 4y ago
    Passphrases protect against silent key exfiltration. Make them long enough (six or seven words these days, I think?) and they won't be cracked in your life time unless the quantum people figure their stuff out or you become a vampire. If you're trying to protect against running programs, you also need to protect against key loggers. Using hardware-backed keys and systems like Windows Hello for validation can help with that, as their UI is not easily interceptable. In the end, there's no perfect way to protect your keys if you have a virus running on your computer.
jesprenj 4y ago
That's usually my argument when someone mocks me for logging into all my computers as root. Having a separate nonprivileged user and running tons of desktop/shell programs isn't really much better considering all those programs have access to your ~, which is on a PC usually the most inportant directory IMHO. firejail is a program that helps mitigate this issue by restricting syscalls of programs.
- nl 4y ago
  This is wrong. Data is important but so too is control of executable programs installed on your computer. Running as root allows a bug in an application like a browser to be exploited and give them root access. Then they can modify programs like firejail and suddenly things you thought were protected aren't.
  - jesprenj 4y ago
    Fair point, but a browser bug leading to code execution in an unprivileged user could, as mentioned, read my SSH private keys, GPG private keys, ... This in turn would allow an attacker to login to my servers and other computers leading to a total compromise, as well as breaking trust and integrity of my email (PGP keys). For my PC a compromise of the user I login as would mean total chaos and compromise, regardless if this user is root or not. Installation of executable programs isn't limited to the root user, a normal unprivileged one can have them as well. I mentioned firejail because running the browser inside firejail should provide more protection against attacks (provided it's correctly cofigured, as a sibling comment points out), as the attacker couldn't escape the browser sandbox. Though in the current modern world, a browser context compromise could be enough to exploit a power user -- webmail, domain registrar web interface, stored passwords. I doubt many power users actualy separate their workflow well enough as to change to a different VT (or SSH connection when working remotely) when performing administrative tasks on the computer that require root access. Because if users don't do that and just use a suid binary, like sudo, a malicious attacker with access to code execution in the context of an unprivileged user that elevates privileges with sudo could snoop the password entered by ptrace or simpler means, like a wrapper binary that gets installed without user's knowledge. (I am by no means a security expert and my opinion shouldn't be treated as useful advice!)
vasco 4y ago
It's totally fine, just do that npm install or `curl | bash`, no need to read anything.
- njsubedi 4y ago
  You forgot the /s
tinus_hn 4y ago
Yes, it’s actually a bit disappointing they didn’t implement keychain support which makes this a lot harder. But then people would be screaming that Apple is peeping at your private keys, even though Apple can’t see the contents of the keychain.
mac-chaffee 4y ago
Yep, same with cookies and cloud credentials: https://www.macchaffee.com/blog/2023/hacking-myself/ https://www.macchaffee.com/blog/2023/hacking-myself/
adrianmsmith 4y ago
> Any program running in the userspace can read the private key file; have the private keys always been not so private all this time? That's right, and the reason for that seeming surprising is that the threat model has quietly changed. Previously: You owned your computer and your data on it, and you ran programs you trusted e.g. you'd buy Microsoft Word and you'd assume that that program acted in your interests, after all the seller wants you to buy the program. Desktop operating systems originated from the time when this was the current threat model. Now: Programs don't necessarily act in your interest, and you can't trust them. The mobile phone operating systems were built with this threat model in mind, so mobile "apps" run in a sandbox. As an example of a modern program that doesn't act in your interest, Zoom "accidentally" left a web server on Macs, even after it was uninstalled. https://techcrunch.com/2019/07/10/apple-silent-update-zoom-app/ https://techcrunch.com/2019/07/10/apple-silent-update-zoom-a...
- exabrial 4y ago
  Correction: Mobile phone operating systems are designed to give a single player in the market unlimited access to your privacy while locking out competitors. The operating system is not your friend. Bravo on the rest, you nailed it.
  - judge2020 4y ago
    Correction: The operating system is a friend that vets your friends. Sometimes I don't want to have to do a full background check on "everyone" I want to "friend" so I let the OS do it for me.
    - franga2000 4y ago
      More like an abusive parent that unilaterally decides who you're allowed to do what with - sometimes because they think they know better than you and sometimes just because it's more convenient to them.
      - danuker 4y ago
suchar 4y ago
This is true for SSH key, but not for all data on MacOS, e.g. if you run `find ~/Library/Application Support/AddressBook` the OS will ask you if you want to give access to contacts to iTerm2/whatever (unless you have given it before). I'm not aware of a way to create additional sandboxed "folders". Also, some applications on MacOS are sandboxed, IIRC Mail is one of them. Also, some (all?) applications installed from AppStore. That's the reason I prefer installing applications from AppStore: they seem to be at least somewhat sandboxed. For development, I try as much as possible to leverage remote development via [JetBrains Gateway](https://www.jetbrains.com/remote-development/gateway/ https://www.jetbrains.com/remote-development/gateway/) and [JetBrains Fleet](https://www.jetbrains.com/fleet/ https://www.jetbrains.com/fleet/). VSCode also has remote development but they explicitly assume that remote machine is trusted (in the security note in the remote extension plugin readme). In the case of JetBrains tools I have not seen any explicit declaration whether remote host is trusted (as in: if remote machine is pwnd then we may as well let pwn your personal machine), but at a glance it seems like there are minimal precautions (if you run web application and open it in a browser, the Gateway will ask if you want to be redirected to a browser etc.) Probably best scenario for such remote development clients on MacOS would be to put them in AppStore: this way they could leverage sandboxing and in the case of thin client, the sandboxing likely won't limit functionality.
dijit 4y ago
This is how it has been, there are ways around this though: 1) use a pgp derived key, this means that anything authenticating will hit your gpg agent and only that, nothing is using that key then 2) load your key and then remove it, which I’ve done before using a LUKS encrypted partition (then load the key into ssh-agent, then remove the volume). 3) Storing your keys in the secure enclave on Apple computers. A little bit onerous if you use an external keyboard without touchID though. I have a program on my computer that watches for read events in that folder to see if anything actually tries to read an access key. I can publish the source if you want. it uses inotify in linux.
- hdjjhhvvhga 4y ago
  Not that it's very practical, but you can always encrypt your key with a passphrase. Useless for automation, very useful for cases like these.
Karellen 4y ago
> Any program running in the userspace can read the private key file; Only programs running as you (or `root`). It's private to you⁰. Programs running as other users cannot read the file. (Assuming you've not changed the permissions on the file or the `~/.ssh/` directory) ⁰ and the sysadmin - but if they're not trustworthy they could just replace `/bin/bash` or the kernel with their own version that copied everything you typed anyway.
johnklos 4y ago
That's why it's a good idea to use a passphrase with your key so that the key by itself is not useful to anyone. It's not easy for people to run only trustworthy software, or even software that has been reasonably vetted by others. Not everyone has the aptitude to know how to check for surreptitious file accesses, or have the desire to learn just to make functional use of their computers.

Bootvis 4y ago

That’s why ideally you use a pass phrase with you ssh key. Apps can still read it but not use it.

progbits 4y ago
Even better, if possible switch to something like PGP keys on Yubikey which prevents exfiltration of the private key, and will only sign things when you enter PIN / touch the device.
- doubled112 4y ago
  This has been my SSH key solution for a while now. Worked smoothly on most systems. Kind of messy on Windows, because there are so many SSH agent implementations, but GPG4Win's latest version works with the native SSH now. Real progress.
  - tkanarsky 4y ago
    I find that the PIV smart card stack is needlessly complicated if all you're trying to do is add a resident SSH key to your yubikey. Look at `ed25519-sk` [0], which is supported by default by recent versions of OpenSSH (and dropbear? idk) [0]: https://news.ycombinator.com/item?id=29231396 https://news.ycombinator.com/item?id=29231396
    - doubled112 4y ago
      PGP is definitely complicated if you’re not going to use it for other functionality. And that’s completely separate to the PIV functionality on the key.
      - tkanarsky 4y ago
        Oh, I was under the impression that PIV referred to the smart card protocol and PGP was an application making use of that protocol, something like TCP and HTTP. Looks like I'm mistaken, thanks!
  - egberts1 4y ago
    Not the map you are looking for but there is this comparison chart of SSH clients and its algorithms. https://ssh-comparison.quendi.de/comparison/cipher.html https://ssh-comparison.quendi.de/comparison/cipher.html
    - doubled112 4y ago
      https://github.com/rupor-github/win-gpg-agent/blob/main/docs/pic1.png https://github.com/rupor-github/win-gpg-agent/blob/main/docs... Don’t forget this diagram of all the agents, protocols and bridges you might hit on Windows.
      - egberts1 4y ago
        That is the scariest system diagram chart that I have ever seen. It should be a prime example of what NOT to do.
grishka 4y ago
But then enter it every time you need to use the key, thus negating the advantage of just magically logging in without passwords? Because if you use ssh-add and only enter the passphrase once per reboot, apps will be able to use it, that's the point.
- Xylakant 4y ago
  You can (and should) use ssh-agent/ssh-add to handle the key for you. It will still protect you against apps reading the key - ssh-agent only performs crypto operations on behalf of programs and will not hand out the private key.
  - jesprenj 4y ago
    The app in question can just dump the memory of ssh-agent and obtain the private key from there. Or not?
    - tristor 4y ago
      Usually no. It requires root / Admin to dump memory of other processes, generally. Although vulnerabilities do exist.
      - jesprenj 4y ago
        Are you sure this is how, let's say, Linux behaves? I tested it now in a minimal privilege account in a chroot on Debian 11 that I use for login from untrusted machines, and strace worked. This is how I captured a password entered into a ssh client password prompt, opened in another login shell of the same user: -bash-5.1$ ps aux | grep abcde z 2502130 0.0 0.3 9500 6132 ? S+ 18:04 0:00 ssh abcde@localhost z 2502140 0.0 0.1 6316 2336 ? S+ 18:04 0:00 grep abcde -bash-5.1$ strace -p 2502130 strace: Process 2502130 attached read(4, "s", 1) = 1 read(4, "e", 1) = 1 read(4, "c", 1) = 1 read(4, "r", 1) = 1 read(4, "e", 1) = 1 read(4, "t", 1) = 1 read(4, "\n", 1) = 1 write(4, "\n", 1) = 1 ioctl(4, TCGETS, {B38400 opost isig icanon -echo ...}) = 0

EthicalSimilar 4y ago

You can store them in the Secure Enclave on OSX and require TouchID to use the key for signing. See: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive

cassianoleal 4y ago
I've been using Secretive for a long time now. It's a great piece of tech. Even if you don't require TouchID, no apps will be able to upload your private keys anywhere as they never leave the enclave. Sure, they can still _use_ the keys without your permission but to do that they need to be running on the workstation. That said, TouchID is really not very inconvenient and if you couple that with control persistence, muxing and keepalive on the SSH client, it's really a no-brainer.

TheBrokenRail 4y ago

Yeah, un-sandboxed programs can access all your user files. That's why there has been such a large push for sandboxing tech like Flatpak. (In general though, you really shouldn't be running programs you don't trust in anything but a VM.)

the_af 4y ago
I understand the principle, but it seems too onerous on the end user. What is a program you "trust"? Something you bought online from a curated app store? Those occasionally have trojans as well. Something you downloaded? Well, if it's open source, that's the norm. Something you build from source? Most people wouldn't be able to spot an exploit hidden in the source code. So.. it's run everything sandboxed by default the recommendation for regular users? Or is it "do not download or buy anything, it's simply not safe"?
- Taywee 4y ago
  I trust the maintainers of my distro software repositories. Any non-distro software, I want to audit before I install or it should be sandboxed. And yes. The recommendation is to not just download and run programs you find on the web.
  - the_af 4y ago
    Unfortunately I think the option you propose (sandboxing) is unreasonable for most users. A lot of the software you want to run (e.g. games, but also lots of special software, including apps/experiments featured on HN) is not available as part of your distro. It's unreasonable to expect end users to sandbox everything just in case. It may be the only think that works, but it's also an unreasonable expectation. In practice, this makes it a non-solution. A security solution must both work and be reasonably doable by most users.
    - LarryMullins 4y ago
      It doesn't have to be reasonable for most users. GNU/Linux in general isn't reasonable for most users.

pluc 4y ago

Only if they run under your user as your private key permission should be only you can read it. Programs running as you are basically you.

_def 4y ago

> have the private keys always been not so private all this time? It's not called private key because it is very secure and can't be accessed... It's on you to ensure that!

calvinmorrison 4y ago

Use a pass phrase!

njsubedi 4y ago
I do. Most probably they do too, but since any running apps can access the user’s private keys, the whole security depends on the strength of the passphrase that can be brute forced offline?
- mr_mitm 4y ago
  Don't run apps you don't trust outside of a container. If there is malware on your system, your SSH keys are only one of your many troubles.
  - the_af 4y ago
    What are apps you do trust?
- throwaway290 4y ago
  Use a long one.
- jeroenhd 4y ago
  Passphrases protect against silent key exfiltration. Make them long enough (six or seven words these days, I think?) and they won't be cracked in your life time unless the quantum people figure their stuff out or you become a vampire. If you're trying to protect against running programs, you also need to protect against key loggers. Using hardware-backed keys and systems like Windows Hello for validation can help with that, as their UI is not easily interceptable. In the end, there's no perfect way to protect your keys if you have a virus running on your computer.

jesprenj 4y ago

That's usually my argument when someone mocks me for logging into all my computers as root. Having a separate nonprivileged user and running tons of desktop/shell programs isn't really much better considering all those programs have access to your ~, which is on a PC usually the most inportant directory IMHO. firejail is a program that helps mitigate this issue by restricting syscalls of programs.

nl 4y ago
This is wrong. Data is important but so too is control of executable programs installed on your computer. Running as root allows a bug in an application like a browser to be exploited and give them root access. Then they can modify programs like firejail and suddenly things you thought were protected aren't.
- jesprenj 4y ago
  Fair point, but a browser bug leading to code execution in an unprivileged user could, as mentioned, read my SSH private keys, GPG private keys, ... This in turn would allow an attacker to login to my servers and other computers leading to a total compromise, as well as breaking trust and integrity of my email (PGP keys). For my PC a compromise of the user I login as would mean total chaos and compromise, regardless if this user is root or not. Installation of executable programs isn't limited to the root user, a normal unprivileged one can have them as well. I mentioned firejail because running the browser inside firejail should provide more protection against attacks (provided it's correctly cofigured, as a sibling comment points out), as the attacker couldn't escape the browser sandbox. Though in the current modern world, a browser context compromise could be enough to exploit a power user -- webmail, domain registrar web interface, stored passwords. I doubt many power users actualy separate their workflow well enough as to change to a different VT (or SSH connection when working remotely) when performing administrative tasks on the computer that require root access. Because if users don't do that and just use a suid binary, like sudo, a malicious attacker with access to code execution in the context of an unprivileged user that elevates privileges with sudo could snoop the password entered by ptrace or simpler means, like a wrapper binary that gets installed without user's knowledge. (I am by no means a security expert and my opinion shouldn't be treated as useful advice!)

vasco 4y ago

It's totally fine, just do that npm install or `curl | bash`, no need to read anything.

njsubedi 4y ago
You forgot the /s

tinus_hn 4y ago

Yes, it’s actually a bit disappointing they didn’t implement keychain support which makes this a lot harder. But then people would be screaming that Apple is peeping at your private keys, even though Apple can’t see the contents of the keychain.

mac-chaffee 4y ago

Yep, same with cookies and cloud credentials: https://www.macchaffee.com/blog/2023/hacking-myself/ https://www.macchaffee.com/blog/2023/hacking-myself/

adrianmsmith 4y ago

> Any program running in the userspace can read the private key file; have the private keys always been not so private all this time? That's right, and the reason for that seeming surprising is that the threat model has quietly changed. Previously: You owned your computer and your data on it, and you ran programs you trusted e.g. you'd buy Microsoft Word and you'd assume that that program acted in your interests, after all the seller wants you to buy the program. Desktop operating systems originated from the time when this was the current threat model. Now: Programs don't necessarily act in your interest, and you can't trust them. The mobile phone operating systems were built with this threat model in mind, so mobile "apps" run in a sandbox. As an example of a modern program that doesn't act in your interest, Zoom "accidentally" left a web server on Macs, even after it was uninstalled. https://techcrunch.com/2019/07/10/apple-silent-update-zoom-app/ https://techcrunch.com/2019/07/10/apple-silent-update-zoom-a...

exabrial 4y ago
Correction: Mobile phone operating systems are designed to give a single player in the market unlimited access to your privacy while locking out competitors. The operating system is not your friend. Bravo on the rest, you nailed it.
- judge2020 4y ago
  Correction: The operating system is a friend that vets your friends. Sometimes I don't want to have to do a full background check on "everyone" I want to "friend" so I let the OS do it for me.
  - franga2000 4y ago
    More like an abusive parent that unilaterally decides who you're allowed to do what with - sometimes because they think they know better than you and sometimes just because it's more convenient to them.
    - danuker 4y ago

suchar 4y ago

This is true for SSH key, but not for all data on MacOS, e.g. if you run `find ~/Library/Application Support/AddressBook` the OS will ask you if you want to give access to contacts to iTerm2/whatever (unless you have given it before). I'm not aware of a way to create additional sandboxed "folders". Also, some applications on MacOS are sandboxed, IIRC Mail is one of them. Also, some (all?) applications installed from AppStore. That's the reason I prefer installing applications from AppStore: they seem to be at least somewhat sandboxed. For development, I try as much as possible to leverage remote development via [JetBrains Gateway](https://www.jetbrains.com/remote-development/gateway/ https://www.jetbrains.com/remote-development/gateway/) and [JetBrains Fleet](https://www.jetbrains.com/fleet/ https://www.jetbrains.com/fleet/). VSCode also has remote development but they explicitly assume that remote machine is trusted (in the security note in the remote extension plugin readme). In the case of JetBrains tools I have not seen any explicit declaration whether remote host is trusted (as in: if remote machine is pwnd then we may as well let pwn your personal machine), but at a glance it seems like there are minimal precautions (if you run web application and open it in a browser, the Gateway will ask if you want to be redirected to a browser etc.) Probably best scenario for such remote development clients on MacOS would be to put them in AppStore: this way they could leverage sandboxing and in the case of thin client, the sandboxing likely won't limit functionality.

dijit 4y ago

This is how it has been, there are ways around this though: 1) use a pgp derived key, this means that anything authenticating will hit your gpg agent and only that, nothing is using that key then 2) load your key and then remove it, which I’ve done before using a LUKS encrypted partition (then load the key into ssh-agent, then remove the volume). 3) Storing your keys in the secure enclave on Apple computers. A little bit onerous if you use an external keyboard without touchID though. I have a program on my computer that watches for read events in that folder to see if anything actually tries to read an access key. I can publish the source if you want. it uses inotify in linux.

hdjjhhvvhga 4y ago
Not that it's very practical, but you can always encrypt your key with a passphrase. Useless for automation, very useful for cases like these.

Karellen 4y ago

> Any program running in the userspace can read the private key file; Only programs running as you (or `root`). It's private to you⁰. Programs running as other users cannot read the file. (Assuming you've not changed the permissions on the file or the `~/.ssh/` directory) ⁰ and the sysadmin - but if they're not trustworthy they could just replace `/bin/bash` or the kernel with their own version that copied everything you typed anyway.

johnklos 4y ago

That's why it's a good idea to use a passphrase with your key so that the key by itself is not useful to anyone. It's not easy for people to run only trustworthy software, or even software that has been reasonably vetted by others. Not everyone has the aptitude to know how to check for surreptitious file accesses, or have the desire to learn just to make functional use of their computers.