Tiny Deathstars of Foulness

I am getting so sick and tired of seeing brute force attempts against SSH traffic. Let’s just change the port that it listens on and then miraculously watch all those brute force attempts disappear. There are a few different ways to go about this in Mac OS X.

The first is to just change the port entries in /etc/services (mileage may vary). To do so open /etc/services in your favorite text editor and look for the lines that begin with ssh. These should look something like the following:

# Jon Postel
ssh 22/udp # SSH Remote Login Protocol
ssh 22/tcp # SSH Remote Login Protocol
# Tatu Ylonen

Just change the 22 to something else, like 2020 or even something that won’t be blocked by many firewalls like 80 or 443 (stateful or deep packet inspection notwithstanding) provided that those ports aren’t already in use. Now restart ssh and you should be listening on your new port (port scan to verify). You can then scan your localhost ( and verify that you’re listening on the correct port.
That’s the most popular way to do this going back to the beginning of time, but Apple can just change things whenever they like in an OS update and blow out your SSH connectivity (given that /etc/services isn’t protected from such a thing). Therefore, you can also do this using launchd. To do so you’ll look at /System/Library/LaunchDaemons/ssh.plist. You can copy this to /Library/LaunchDaemons and rename it to something like CustomSSH.plist, providing a new label and SockServiceName. If you wanted to stick with port 443 you could do the SockServiceName of https. If you choose to go this route, the next step would be to load your new LaunchDaemon and then check that it is working (unloading your old sshd listener in the process). Oh, and you can remove the Bonjour key from listeners as well if you don’t want it out there…

If you are simply trying to protect against external threats and not internal then another method would be to remove access to SSH on the organization’s border firewall. Oh wait, many can’t do that. So then you could simply do a port redirect on the firewall appliance. Basically you would route port 443 to port 22 on the internal LAN for the IP in question. This is pretty basic and supported in even prosumer types of appliances these days. This would effectively make the traffic look like https traffic to the outside world and when you are behind the firewall it would be port 22.

These steps do not remove the need to edit sudoers and other steps many use to secure SSH, they’re just here to change the port so that the logs can show fewer invalid attempts.

October 21st, 2010

Posted In: Mac Security

Tags: , , , , , ,

Macworld 2011 will be this upcoming January 26th through January 29th. With sessions ranging throughout the Mac OS X ecosystem there is surely going to be something for everyone.

For those interesting in attending Macworld 2011, I will be there and presenting on a little bit of a different topic than what I usually talk about at Macworld: Home Automation. It’s not going to be a surprise to many of the readers who have seen posts here and there about extending the capabilities of what your Macs can manage from the digital into the physical. This session will be a little bit of product awareness, a little bit of scripting and plenty of imagination. So if you’re interested in conserving energy, making life easier and getting a little of what all those sci-fi books we read in school promised us then swing on by.

Oh, and there will be schwag at this session as well!

October 19th, 2010

Posted In: public speaking

FallCon is the Falls biggest comic book extravaganza in Minneapolis. And it’s happening today, October 16th at the Minneapolis State Fairgrounds. If you’re like me and you are still trying to get over the fact that you horfed down too many corn dogs at the State Fair a little while back then go ahead and get over it and head down.

There’s free parking, a low cover of $7 (bring a food shelf donation and drop that by $1), over 100 comic book personalities, lots of places to pick up those geeky t-shirts that will inspire awe in all the women you meet (or not) and schwag (aka prizes). See ya’ here!

October 16th, 2010

Posted In: personal

Tags: ,

Disturbingly accurate.

October 15th, 2010

Posted In: personal

In Xsan Admin you can easily label LUNs that are available on your Fibre Channel fabric. Using the cvlabel command, you can also easily label a LUN that isn’t on a Fibre Channel fabric. Labeling a LUN writes data to the LUN, thus allowing Xsan to somewhat mark its territory (insert vivid imagery of an Xsan shaped like a dog taking a whiz on a poor thumb drive). If you then look at that LUN from a Mac OS X system without Xsan installed, the computer will have greyed out options in Disk Utility and will not be able to treat the LUN as a “disk.” You also can’t use diskutil to reformat it.

As much as we love our RAIDs, at times they will be ready to put out to pasture (more vivid imagery, this time of a RAID chassis grazing gleefully in the sunshine). This is where cvlabel comes in again (retiring the LUN, not the imagery). The cvlabel command can be used to unlabel a LUN and move it back to what amounts to free space. If you run cvlabel with a -l option you will see a list of LUNs:

cvlabel -l

If you want to unlabel a LUN, first remove it from your SAN. That typically involves something akin to backing up the volume and restoring it following a rebuild or using snfsdefrag to migrate all data off it and then removing it from the volume), typically with the volume stopped. Once the LUN has been removed, find the LUN in the list provided using that -l option and then run the following command (replacing MyLUN with the name of your LUN):

cvlabel -v -u MyLUN

Make sure that you’re using the name of the LUN when you run this and not the name of the volume, or the name of the wrong LUN. Also make sure that the LUN is no longer a member of an Xsan (or StorNext SAN), etc. Once you have unlabeled the LUN, fire up Disk Utility and you should be ready to format the new drive. Seems like this ends up getting done via ssh a lot, which doesn’t have Disk Utility, so to do so with diskutil, run:

diskutil list

Then with the output find the unformated space, which will likely say something akin to disk1 or disk2. You won’t usually find that an empty LUN will have slices like disk0s1, disk0s2, etc. Once you locate it in the list, you can then run (assuming the disk from the output of the previous command was disk1 and the name you want the volume to have is MyVolume):

diskutil eraseDisk HFS+ MyVolume disk1

Note: You must install Xsan to get cvlabel.

October 14th, 2010

Posted In: Xsan

Tags: , , , , ,

In Windows 7 (and previous versions for that matter), you can change the port that RDP listens on for new Remote Desktop connections. To do so you would fire up regedit and then browse to the following key:


Here, you would change the PortNumber to a new decimal value that is the port you wish to listen on. Save, reboot and you’re good to go.

October 12th, 2010

Posted In: Windows XP

Tags: , , ,

And here I thought I had some zingers…

Thanks Naveen@UUASC!

October 10th, 2010

Posted In: personal, Unix


October 9th, 2010

Posted In: personal

I’ve been finding recently that practically every netatalk implementation is using bdb instead of cdb (the default), due to the fact that cdb seems to be more susceptable to corruption. To make this change, you open the netatalk configuration file at /etc/default/netatalk. Here you will see the following options:


To switch from cdb to the dbd scheme change CNID_METAD_RUN = no to CNID_METAD_RUN = yes.  Save the netatalk file and then restart using the ‘netatalk restart’ command (with sudo or as root):

/etc/init.d/netatalk restart

No further changes need to be made in AppleVolumes.default or afpd.conf, but do be sure to check that the users you want to have access are in the appropriate structure.

Thanks to Bruce for pointing out my typo!

October 8th, 2010

Posted In: Ubuntu, Unix

Tags: , , , ,

Next Page »