New answers tagged

0

After having read the answers, I think I have developed a model that is sufficiently secure for my threat model. I get three VPS. I allow my IPs in the first VPS. I allow only the first VPS's IP in the second VPS's configuration. I allow only the second VPS's IP in the third VPS's configuration. I use the first VPS as a SSH tunnel. I login to the second ...


1

See https://help.github.com/en/github/authenticating-to-github/testing-your-ssh-connection for the expected host fingerprint. I used ssh -v -T git@github.com to see the host key my ssh client verified, and it was nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 which is listed on their page, so the connection is not MiTM'd. I don't know why it happened. I guess ...


0

No, IMHO, this is still a chain, a "consistent" way to build security. This scheme are still vulnerable to the same MiTM attacks with or without midpoint. Instead, try to add "parallel" security, like MFA. This will protect you from MiTM, however you will still be susceptible if someone will have a physical access to your computer. In order to protect ...


3

By allowing SSH connections to the midpoint VPS from any source IP, then allowing SSH connections from the midpoint VPS to the target VPS, you are just moving the security hole from one location to another. At best, this is 'security by obscurity'. I would suggest you scrap the idea of the midpoint VPS, and try to harden security on the target VPS as much ...


8

Compression before encryption is a problem if the attacker can control parts of the transferred data and then use the detectable compression ratio (i.e. amount of transferred data vs. original data) to make conclusions about some of the traffic. This was in TLS used within BREACH and CRIME attacks to infer cookies and CSRF tokens. Making such attacks work ...


5

Even if you have a password that is very strong, it's best to block attacks immediately, preferably at firewall level - something that fail2ban and other similar tools do. You could do nothing and let the hackers pound in vain against your server forever, but that is a waste of CPU and bandwidth. There is no reason why you should allow this. In addition to ...


0

As to -t dsa in particular, that is up for debate. I believe this answer regarding DSA remains accurate as it relates to OpenSSH at this time. The rest of this answer will use the phrase 'encrypted key' to mean a key encrypted with modern best practices that should be as infeasible to crack as it can be (and that exists nowhere else on or around the same ...


1

I really love the power and convenience of running SOCKS5 via ssh to my own server out in the data center (as the posted pointed out). TAhough I think I use the syntax "ssh -f -Nn -D $LOCAL:$LPORT -p $RPORT $USER@$HOST". Not only does this securely tunnel my DNS requests and on line banking and DNS requests securely past my ISPs prying eyes (once you ...


Top 50 recent answers are included