3 ms·

I would say that is incorrect. A well versed attacker is going to have absolutely no issue finding your 'new' SSH port. Why do you think this is a security meas

by druiid 14y ago

I would say that is incorrect. A well versed attacker is going to have absolutely no issue finding your 'new' SSH port. Why do you think this is a security measure? As for shared keys... they also have their drawbacks. Someone can forget their shared key in the wrong place and suddenly you have an extremely easy entry-point into perhaps EVERY single server in an environment. Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it.

moe 14y ago
attacker is going to have absolutely no issue finding your 'new' SSH port. As I wrote in my initial comment: It's not about targeted attacks, it's about evading netblock scans. Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it. Bullshit. Use one password-protected keypair for each critical zone (work, personal, etc.). Keep it on your main machine and do not copy it to "places". Also don't spread FUD on public forums about the most secure ssh auth-option (short of multi-factor).
- druiid 14y ago
  Excuse me, what? FUD? I wasn't spreading FUD, I was saying that people overuse shared keys and end up putting themselves in situations where they are open to easy exploitation if they don't use them right. People will generate a key and the put it on their dev machine, backup machines and similar all which are generally less secure than production devices. Someone figures out a way in and boom. How is this FUD? It happens in real-world usage when people don't take the time to consider how they should be properly using shared keys.
  - moe 14y ago
    people overuse shared keys This is not a drawback of key-based authentication versus passwords because you have the exact same problem with passwords. If you want to explain proper key-management then explain it. But don't make it sound as if key-auth was some esoteric option that should be carefully considered versus password auth. Key auth should always be the default and password auth should always be disabled, exceptions to this rule are very rare.

by druiid 14y ago

moe 14y ago

attacker is going to have absolutely no issue finding your 'new' SSH port. As I wrote in my initial comment: It's not about targeted attacks, it's about evading netblock scans. Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it. Bullshit. Use one password-protected keypair for each critical zone (work, personal, etc.). Keep it on your main machine and do not copy it to "places". Also don't spread FUD on public forums about the most secure ssh auth-option (short of multi-factor).

druiid 14y ago
Excuse me, what? FUD? I wasn't spreading FUD, I was saying that people overuse shared keys and end up putting themselves in situations where they are open to easy exploitation if they don't use them right. People will generate a key and the put it on their dev machine, backup machines and similar all which are generally less secure than production devices. Someone figures out a way in and boom. How is this FUD? It happens in real-world usage when people don't take the time to consider how they should be properly using shared keys.
- moe 14y ago
  people overuse shared keys This is not a drawback of key-based authentication versus passwords because you have the exact same problem with passwords. If you want to explain proper key-management then explain it. But don't make it sound as if key-auth was some esoteric option that should be carefully considered versus password auth. Key auth should always be the default and password auth should always be disabled, exceptions to this rule are very rare.