4 ms·

This is an excellent article with a lot of original research instead of the typical security guides that I see that are pretty much copy paste jobs (look up any

This is an excellent article with a lot of original research instead of the typical security guides that I see that are pretty much copy paste jobs (look up anything about Apache HTTPD for a very good example of that). A couple of things about Linux security that really hinder ppl / I don’t think are promoted enough: - People forget to secure VIM. Even if you’ve secured everything, very easy to use the built in mini-shell in VIM to move to the actual shell. - Look at / focus on your SSH key fingerprints. These things matter. I didn’t pay attention to these things nearly as much as I should have the first two years of my career, but it’s so easy to just intercept your request, grab your private key, and then just pass you on to your regular server without you even knowing. - Please please secure your web servers. The default configuration can be very difficult to argue is secure, e.g. the fact that every web server reveals out of the box the exact semver of the Apache/Nginx or the lack of automatic HTTPS redirection that would be useful for 90% of modern deployments. Check out Caddy which helps with some of this.

computersnail 8y ago
Your private key is not sent to the ssh server. They could do something else nasty like collect keystrokes from your session on the fake server though.
- tialaramex 8y ago
  More specifically: Out of the box your SSH client will only use its private key to prove that it knows the key (it signs a message specific to the SSH connection) during login. I think this is properly designed so that a bad guy can't live proxy it - if the bad guy gives a victim parameters the bad guy can decrypt those don't match on a real server; if they use the real parameters they're no longer able to read the session so why bother. For environments where you want proxy behaviour (e.g. "jumpboxes") you can tell the client to volunteer to sign on behalf of further clients down the chain. Bad guys could use that but they still don't get the actual key so they must conduct any attack live, and clients could tell you about or even ask you to explicitly authorise every such request.
- RedComet 8y ago
  I think he is talking about the session key via a MITM.

computersnail 8y ago

Your private key is not sent to the ssh server. They could do something else nasty like collect keystrokes from your session on the fake server though.

tialaramex 8y ago
More specifically: Out of the box your SSH client will only use its private key to prove that it knows the key (it signs a message specific to the SSH connection) during login. I think this is properly designed so that a bad guy can't live proxy it - if the bad guy gives a victim parameters the bad guy can decrypt those don't match on a real server; if they use the real parameters they're no longer able to read the session so why bother. For environments where you want proxy behaviour (e.g. "jumpboxes") you can tell the client to volunteer to sign on behalf of further clients down the chain. Bad guys could use that but they still don't get the actual key so they must conduct any attack live, and clients could tell you about or even ask you to explicitly authorise every such request.
RedComet 8y ago
I think he is talking about the session key via a MITM.