0

I have recently been learning about how to set up and run a Linux server on Amazon and I have been wondering about the best practice for SSH into it from a public place. By public place I mean like a coffee shop.

I have the security group and the two solutions I can think of is change the inbound to everywhere or find the public ip that my laptop has and setting that as the temporary inbound.

These solutions seem strange to me that I would have change the security group every single time. Is this just normal? Or is there some other way?

Also when SSHing in a public place should I look into setting up a virtual private network or would that be over kill?

Josiah L.
  • 121
  • 1

2 Answers2

2

Yes, using a VPN for ssh access to EC2 is best. Even if you're closing access from a public address after you use it, it's still a risk while it's open, especially if someone is snooping traffic on, say, a coffee shop wifi.

If VPN is not an option, there are a few steps you can take to mitigate risk (you should really be doing these either way):

  1. Configure your sshd to accept keys only. No password logins. If you can do two-factor auth, even better.
  2. Don't re-use the same ssh key in multiple places.
  3. Limit the keys you use with ssh-agent. (This is a fun openssh bug.)
  4. Keep openssh/openssl patched.
Karen B
  • 534
  • 3
  • 7
  • Ok I will set up VPN. With a security group will I have to just change the inbound to fit my current outbound ip from my laptop? I saw somewhere else that someone created a script to edit the security group automatically to match their outbound ip – Josiah L. Jul 10 '16 at 19:56
  • 1
    Oh goodness no. Just push a local route to VPN clients and allow ssh only from inbound connections on that route. – Ryder Jul 10 '16 at 20:11
2

SSH is encrypted, so there's no need to double encrypt by using a VPN. Even if someone's snooping on the traffic they can't get access. Make sure you authenticate using public key, which is the default in AWS Amazon Linux instances, but may take a bit more work on other distributions.

If you plan to SSH in from various locations the best bet is to close it by default, add your regular IPs, and if you need access from a coffee shop log into the web interface (which you should be using 2FA for) and allow access from that IP. Don't forget to turn it off later. Leaving SSH open to the world probably isn't a huge risk, but I don't do it myself, because I don't ssh in from random locations. If your server is critical / sensitive I would be careful, but for other things the risk is probably low to moderate. Of course you need backups of data, EBS snapshots are sufficient.

Tim
  • 31,888
  • 7
  • 52
  • 78
  • 2
    I'd just add one thing - be certain to use key-based authentication only. Forbid password logins, so even in the unlikely case of someone at the same coffee shop trying to crack the server, they'll never manage it. – ceejayoz Jul 10 '16 at 20:14
  • This is a bad habit to develop. The point of a VPN isn't double-encryption, it's to provide a route to the host so you don't have to go poking holes in your firewall for every two-bit coffee shop with free wifi. It's too easy to get distracted or forget or have an emergency which leaves the firewall hole there, and waiting for anyone on that LAN to come knocking. – Ryder Jul 10 '16 at 20:15
  • Thank you, that answer gives me enough info to build on. Perhaps later I may look into setting up a script to handle the security inbound ip – Josiah L. Jul 10 '16 at 20:16
  • 1
    @Ryder makes a good point, a VPN could avoid having to change your firewall. If you use cafe's all the time and you have easy access to a trusted VPN maybe it makes sense. If it's occasional then changing the firewall is probably fine. The risk of leaving ssh open to a few random IPs is negligible especially if you use key based auth. – Tim Jul 10 '16 at 21:42
  • I can't agree with the comments above re VPNs. `sshd`, when set for public-key-authentication only, is a pretty safe service to expose to the internet-at-large, and there are excellent `iptables`-based rate-limiting techniques that can be applied to inbound ssh connection attempts if that's still not enough for you. Adding a VPN gives you another single-point-of-failure, in return for very little added security; +1 for this answer, from me. – MadHatter Jul 12 '16 at 08:00