If you are in a campus computing environment or otherwise on the public Internet, you are probably having someone look through the windows and jiggle the doorknobs every few hours. These brute force attacks sometimes allow someone access to a system with a common password, in addition to causing your workstation to be spinning up dozens of sshd processes. On some systems, this can actually affect performance in addition to potentially causing common usernames to get locked out in enterprise environments that use Active Directory, Kerberos, or LDAP.

Easy Mode

Easiest thing to do is just disable the remote login service if you don’t need it. By disabling the service in the Sharing preference pane of System Preferences, the service isn’t available, and the problem is solved.

Filtering

You could (and should) have a local packet filter (firewall) policy for your workstation.

You can do a very basic “on/off” configuration in System Preferences but if you have remote login enabled, the firewall policy will merely allow it, and that isn’t going to help you much, is it?

On Snow Leopard systems this will use

, and you can use freeware like WaterRoof to configure a basic firewall policy that will allow certain networks to access your ssh service (or any other services running on that system). Lion and Mountain Lion prefer a different technology called

¹. The developer of WaterRoof has another utility for configuring a

firewall, called IceFloor. I know what you’re thinking, and no; I have no idea where he comes up with these names. I’m sure there is a naming convention or theme associated with them, but for the life of me I can’t figure it out. It’s just one of those inside jokes that programmers like to have. WaterRoof? IceFloor? I just want to make a firewall, not spend the next eight hours on Wikipedia.

I’m not a nerd

In the event of being confused by this, try the third option, NoobProof, which promises to be more helpful.

What should I allow in?

As mentioned earlier, a firewall that just allows everything isn’t helpful, so you’ll need to limit access to services based on networks and hosts you want to allow to access them. If you have access to a VPN service that will be perfect, since using the VPN will require some sort of authorization that may not be required elsewhere in your building, network, or campus. Every user of a VPN service maintained by your organization will have some sort of audit trail and that will really raise the opportunity cost of getting access to that service.

the Lazy Approach™

The other option is running your

on a non-standard port. People do this all the time for remote access protocols like Microsoft Remote Desktop Protocol (RDP), VNC, and

. It doesn’t really buy you anything in terms of real protection, since anyone taking the time to assess the system remotely will probably find it if they’re interested in targeting that host directly. The one thing it can help with however is those brute-force attempts to access your system, because most of them will go after systems listening on tcp ports

and

.
Scanning entire systems can take a while, so the scripts and code used for discovering and attempting to gain access via brute force focus their efforts on traditional/typical ports mainly because it’s faster. Best practice is to use a firewall policy that limits access to services to networks and hosts you can reasonably trust in conjunction with an alternate port and some configuration tweaks.

Show me Lazy

This isn’t a great way to do this, because it can possibly be stomped on after a software update to the OS.

/etc/services

You start by editting /etc/services with your favorite text editor. This will require you to be an administrator.

You want to find a couple of lines next to each other that look like this:

When a

job, or tools like

need to look up a port and identify it by service, they consult that table

. It’s just a table of over ten thousand known services, protocols, and other assorted nonsense.

Go ahead and add two new lines under those two and have it read:

Obviously the #comment is optional.

It can be any port number you don’t want to have any other services listening on, in general it should be over port 1024 and under 65535. I used 22744 because 22 is the standard port for

, and “ssh” on a phone keypad is “744”.

to the launchd!

Okay we have an alternate service port set aside, so now we go to

and edit the file (as root)

. The plist we’re editting is what handles

, and we’re going to tell it that instead of using port 22 like it usually does, we’d rather use 22744.

You will see a key called

.

This is telling launchd that it wants to put the

process on port 22 by virtue of it using a SockServiceName of

. Change

to read

and save the file.

We can now reload the launchd job by doing:

which will unload (and stop) the ssh service, and then load the ssh service’s launchd job and the alternate port. You can confirm via netstat:

which will show you if any service is listening on port 22744. You can also just use

or

, e.g.

and that will return a banner for the listening service, in this case it will say something like

.

This will persist across reboots, but like I said, a software update may change /etc/services or the ssh.plist. Should either of those get stomped, you’ll need to do it again. I don’t know how often it occurs, I’m more likely to rebuild or install an OS from scratch than I am to install a series of updates.

What’s the good way?

The good way is to create a new launchd plist that runs ssh on a high port instead of changing the one Apple gives you. If you want to go that route there are better resources to teach you.

Configuration Tweaks

You should edit

as root and make a few recommended changes. You’ll see a directive that reads

and you’ll want to say “well golly, why didn’t we just change it there?” and this is where I give you a finger-wag and tell you something about launchd, Apple’s launch services, and a bunch of stuff you don’t care about.

Suffice to say, changing the port number in this file doesn’t do anything on Mac OS X unless you also change how sshd starts up entirely and if you were going to do that, you wouldn’t have any interest in reading past the first paragraph of this document anyway.

We’ll be looking at these lines:

and we’ll change them to:

If you want to be extra awesome, you’ll also disable PasswordAuthentication and require public keys for authorization, but we’ll save that for another day.