vadipp said:
That's generally true, but it's my personal server, and I want to be able to easily connect to it from anywhere using plain SSH to access my data. So it doesn't make sense for me to restrict SSH connections. I just want to see if someone is trying to hack into root or any other existing user on the server. I think I'm not alone in this situation, but I encourage everyone to make their own security decisions.
If this is the case and securing behind a VPN is not feasible, I'd still definitely recommend setting up log in via SSH keys.
The need for an overly complex password is significantly lessened by using public/private key authentication.
Public/private key authorization may seem scary at first, but once you've done it a few times it will become familiar - and it is MUCH more secure if used properly (i.e., with a passphrase on your private key).
In case you're not aware of how to do it, this is the process (brief overview):
On your personal non-exposed machine (e.g., your personal laptop, workstation, etc.), run ssh-keygen to generate a public/private keypair. This will give you 2 files, depending on which options you select (v1 vs. v2, DSA vs RSA key type), will be
~/.ssh/identity and
~/.ssh/identity.pub, or
id_rsa and
id_rsa.pub, or
id_dsa and
id_dsa.pub.
In any case, the .pub file is your "public" key, and the contents of this file should be added to
~/.ssh/authorized_keys on any remote machine you want to access (either cut/paste using a text editor or
cat identity.pub >> ~/.ssh/authorized_keys). The corresponding "identity" file (e.g., the filename without .pub on the end) is your private key, and should be protected - kept on a private, secure machine and not disclosed to anyone, ever. This key can optionally be password protected (in case someone manages to steal your private key, they still need to enter a password to decrypt it) as well.
Once you have the public key on your remote machine in
~/.ssh/authorized_keys, you should be able to connect via key authentication and can then turn off password authentication. If you have a password on your key, you'll still need to enter the password when using the key, but this traffic is never sent over the wire, key decryption using your key's passphrase is done locally before the connection is made.
Once you've done this, for someone to break in via
ssh they will need to crack (or steal) your private key, which is much, much more difficult than a dictionary attack on your password (i.e., 1024 bits of entropy or more, vs say 110-120 bits of entropy for a fully random 16 character password). IF someone does manage to steal your private key, the passphrase will prevent them from using it in the time frame between you having it stolen and realizing that you've had it stolen, and replacing it. A known or suspected stolen key should be removed from authorized_keys on all machines and a new public/private key pair generated, in case someone who has the key manages to brute-force your passphrase on the key. If your key has no passphrase, anyone who has it can log in.
Step by step process available here:
http://www.petefreitag.com/item/532.cfm (not my guide). Only difference is that FreeBSD uses "
authorized_keys" and not "
authorized_keys2". Also the guide doesn't specify using a passphrase (ssh-keygen
will prompt you for one, however). USE a passphrase on your key. This will prevent someone who steals your key from being able to use it.
You can even reduce the need to keep entering your passphrase with ssh keys by using a program like
ssh-agent, or if you are a Windows user, Putty Agent.
