If you have a home server or a small personal server, why do you need to expose port 22 to the Internet? Have iptables accept connections on 22 only from your local network, and add a second port to sshd_config that's memorable, like the last four digits of your phone number, or maybe your birth year. Or just use a random number generator and memorize it. I've been running SSH on my home server for over a year now, and I have zero (or pretty darn close) unauthorized attempts.

Or am I doing something wrong? Is there some compelling reason to use port 22? It wouldn't be the first time I've been wrong

Not wrong, but sometimes you may be in a situation where the public network of the hotel/library/conference center/else properly allows TCP/22 for SSH but not TCP/1234 or any other port that you have defined. And then you have created your own denial of service

The points are "do you need to get access to your server in any situation" or not and if you know in advance that you may be using restrictive networks or not.

OK. If I want to expose 22 to the 'net, what precautions should I take? I already use key-based authentication with password login disabled, and I'm pretty sure I've disabled root login as well; I can check this when I get home. Is there anything else I should be doing?

Rate limiting on your firewall. This will drop the connections if say more than 3 are done per second etc. Commonly done with brute force attacks. It takes more than one second to type a password so you wont get blocked. Hosts allow or deny to specify allowed users. Use a password on your certificates.

Alternatively,what i use. Block ssh over net and use tcp based vpn to connect to lan and then ssh on lan only network allow.

In the end of the day. Our goal is to prevent being hacked from scripts (99 of hack attempts). If a serious organization tries, I don't know about you guys but i will be up bums creek, but then again your slow connection and home network is not the goldmine the serious pros are after. So totally safe no, but most of our configs does not even properly show up as an amoebas excrement on the big boy radar, so doing that makes the typical home user pretty safe in my opinion. Now if I was microsofr or ibm etc, it is a different story, but they can also afford dedicate security teams.

The reply was meant for a different thread. How it got here only the admin knows. Maybe something happened when the thread I initially replied to got moved???

I like the analogy, but I think it may be a tad innacurate. For example, the plumber doesn't have to deal with people coming in and hammering on the pipes, or deploying something through the water meter designed to cause chaos. Similarly, the electrician doesn't have to deal with random outsiders playing with the voltage on the line, or walls lined with some rubber-eating acid.

I guess my point is that while yes, you never think the job is done, but in this case the job may never be done. I wish I remembered where I first heard this, but it really made re-think a few things.
With electricians and plumbers, what worked 50 years ago will still probable work today, maybe with minimal modifications. But if you tried to set up a production server today using 10-year-old software and security practices, you'd probably lose that job pretty quickly.

Just my 2 cents.

go through the ssh config, off the top of my head
- make it do protocol 2 only
- set the allowed ciphers, disable the des ones, have only AES-256.
- set the delay for failed login to something like 7 seconds or more

can't remember exactly but i believe you can limit what users on the system are allowed to use ssh also.

go through all user and system accounts and make all accounts that you can locked... using the passwd -Sa command will show LK for the account versus PS for active. also set the shells to accounts to /bin/false that don't need a log in shell.

as for changing your ssh port from 22 to something else, that only works if you have control of your firewall and proxy and other managed routers between you and the world. level 3 (i think) switches/routers can be programmed to block or not pass traffic i believe based on port numbers, at least that's what i recently concluded trying something where i chose an obscure port number for something then had to fall back to one of the common port numbers like for ftp, ssh, or http.

The original thread was to help the OP, questions pertaining your situation should be in your own thread, hence.

What I would probably do instead is to use VPN. And, within that, to use only digital certificates, not PSK's==Passwords.

Thus, the only way to get into the system, even to subsequently use SSH (although you could at that point simply use RSH ...), is to possess the unique digital certificate which was issued to your machine, as well as to know any password needed to unlock it.

An intruder, sniffing around the wall, encounters a solitary open port ... and a badge-reader, sitting next to it. If you possess the badge and the means to use it, the door opens willingly. If you do not, it cannot be opened. ("Speak friend and enter" won't cut it ... sorry, Dr. Tolkien.)

Every badge is unique. If anyone's phone or laptop gets stolen at the airport, that certificate quickly drops dead. Meanwhile, you also know exactly who is connecting. You can trace it, not to "someone who knows the magic word," but to a single person or machine.

How is that different from using SSH keys, which can also be password-protected? Either way, you need to possess a certian file that acts as the "magic badge" for your badge-reader analogy. Or are VPN keys "more secure"?

EDIT: The above is assuming that password login is disabled (which I have already been doing)

Just a practical data-point: I've run sshd open to the internet, key-based login only, no root access, for many years. I was constantly under attack, and it was occasionally fun to read through /var/log/messages and see the attempts.

However, during one software update, I inadvertently let my sshd config get overwritten which enabled password login. My passwords were complex enough to not get hacked, but I didn't notice for a week.

That prompted me to move the service to a non-standard port (and one not in the top-1000 ports for nmap), and I have NEVER noticed an attempt since. Never, in several years of running this way.

It, too, have opened port 22 to the internet (on a VM in my case) and watched the logs. That is the reason I would recommend not using port 22 if you can help it -- your logs will be absolutely full of hack attempts. Contrasted with having a non-standard port open and non (in my case) or virtually non and when it's just a home server (in my case a Pi) that's a lot of work or complexity you're saving yourself by just changing the port.

Ditto on using a non-standard port. I've run ssh on non-standard ports for over a decade now without ever seeing a break-in attempt. Contrasted with a few hundred log entries per day when port 22 was open on a public server. And that log count was from the early/mid 2000's.

In tems of ceritificates, yeah, vpn is the same as shh, but ssh gives you the machine vpn allows full network access. Of course ssh tunnels can achieve this also, but is a pain in the ass to setup.

The vpn also clears the logs for ssh login attempts (in itself easy to clear out with a simple grep -v) but in my case i prefer the vpn route because the biggest pain in the bum is changing ports for servers applications and on top of that rewriting rules of SELinux on every single machine to allow ssh daemon communication on non standard ports.