4 ms·

I don’t get it. Use ssh keys with a passphrase? Then stolen keys are useless?

by LogicX 6y ago

pat2man 6y ago
What if the passphrase gets stolen as well?
notretarded 6y ago
Or don't use them at all, then you don't need to worry about them getting stolen
genericstorage3 6y ago
Brute force. Usually people put a simple one
- dawnerd 6y ago
  Or worse, none at all since a lot of guides, especially for CI, tell you to just use none.
staticassertion 6y ago
A passphrase on your key is a great idea, but as soon as you unlock it once it's cached in memory. Since processes are not isolated within a user they're allowed to scrape the memory of other processes. If you check your running processes you're going to see that ssh-agent is running as your current user. But a far more likely scenario is that the attacker will simply leverage existing sessions/ steal a socket, which, notably, will bypass any sort of 2FA on SSH connections.
- chousuke 6y ago
  On Linux, you can harden a bit against memory dumping by disabling ptrace. Set the "kernel.yama.ptrace_scope" sysctl to 3 and the easiest attack will no longer work, if you have processes that don't explicitly request disallowing ptrace.
  - staticassertion 6y ago
    I actually don't believe that scraping memory is the easiest attack, I just mentioned it informationally. I strongly believe attackers are more likely to hijack sessions. But yeah, ptrace is definitely something to watch out for. Monitoring ptrace is also something defenders can do if they're not in a position to disable it (if you're working for a software company your engineers will ptrace).
  - ikiris 6y ago
    No, you should use short lived certificates, ideally locked inside hardware tokens and 2fa. This is just snake oil that doesn't actually add protection.
    - chousuke 6y ago
      But it does help; in most cases, it requires no effort whatsoever, in contrast to using something like SSH certificates which may not even be possible, depending on the environment. There's no such thing as perfect security, but that doesn't mean you shouldn't lock your door.
- dotancohen 6y ago
  Or store your keys in a different user. I personally use have the users dotancohen and dotancohens (trailing s for Secure) on my laptop. I simply su into dotancohens and then from there SSH into various servers. The /home/dotancohens/ directory has 0700 permissions.
  - jiveturkey 6y ago
    How does this help you? If your dotancohen acct is compromised, I will just capture the password for dotancohens when you su to that account.
    - dotancohen 6y ago
      Hmmm... Maybe I should calling the su binary directly from /usr/bin/. Any thoughts on that? Or should I open a new VT?
beermonster 6y ago
You'd want to use a strong passphrase. Even if you do, it's protecting the physical key. If an attacker has access to the that they can perform an offline attack. i.e. attacking a passphrase offline with decent hardware and no likelihood for being noticed means it had better be strong!

I don’t get it. Use ssh keys with a passphrase? Then stolen keys are useless?

by LogicX 6y ago

I don’t get it. Use ssh keys with a passphrase? Then stolen keys are useless?

pat2man 6y ago

What if the passphrase gets stolen as well?

notretarded 6y ago

Or don't use them at all, then you don't need to worry about them getting stolen

genericstorage3 6y ago

Brute force. Usually people put a simple one

dawnerd 6y ago
Or worse, none at all since a lot of guides, especially for CI, tell you to just use none.

staticassertion 6y ago

A passphrase on your key is a great idea, but as soon as you unlock it once it's cached in memory. Since processes are not isolated within a user they're allowed to scrape the memory of other processes. If you check your running processes you're going to see that ssh-agent is running as your current user. But a far more likely scenario is that the attacker will simply leverage existing sessions/ steal a socket, which, notably, will bypass any sort of 2FA on SSH connections.

chousuke 6y ago
On Linux, you can harden a bit against memory dumping by disabling ptrace. Set the "kernel.yama.ptrace_scope" sysctl to 3 and the easiest attack will no longer work, if you have processes that don't explicitly request disallowing ptrace.
- staticassertion 6y ago
  I actually don't believe that scraping memory is the easiest attack, I just mentioned it informationally. I strongly believe attackers are more likely to hijack sessions. But yeah, ptrace is definitely something to watch out for. Monitoring ptrace is also something defenders can do if they're not in a position to disable it (if you're working for a software company your engineers will ptrace).
- ikiris 6y ago
  No, you should use short lived certificates, ideally locked inside hardware tokens and 2fa. This is just snake oil that doesn't actually add protection.
  - chousuke 6y ago
    But it does help; in most cases, it requires no effort whatsoever, in contrast to using something like SSH certificates which may not even be possible, depending on the environment. There's no such thing as perfect security, but that doesn't mean you shouldn't lock your door.
dotancohen 6y ago
Or store your keys in a different user. I personally use have the users dotancohen and dotancohens (trailing s for Secure) on my laptop. I simply su into dotancohens and then from there SSH into various servers. The /home/dotancohens/ directory has 0700 permissions.
- jiveturkey 6y ago
  How does this help you? If your dotancohen acct is compromised, I will just capture the password for dotancohens when you su to that account.
  - dotancohen 6y ago
    Hmmm... Maybe I should calling the su binary directly from /usr/bin/. Any thoughts on that? Or should I open a new VT?

beermonster 6y ago

You'd want to use a strong passphrase. Even if you do, it's protecting the physical key. If an attacker has access to the that they can perform an offline attack. i.e. attacking a passphrase offline with decent hardware and no likelihood for being noticed means it had better be strong!