This is sort of a follow up to my SSH screencast series for remote access to your Mac. Maybe you are paranoid like me and want to know when a connection has been made to your mac, when a wrong user name has been tried or even a failure to login on a good username. You also want to know this no matter where you are.
I was inspired by the script written by Whitson Gordon, over at Macworld on automating turning off your wireless Airport interface. Note what I have below has only been tested on my Snow Leopard setup. I leave it up to you if you are on Leopard or even Tiger. BTW update your system if you are as far back as Tiger. C’mon join the modern world.
You will have to have Growl installed, also install growlnotify and last you need a Growl to push notification service like Prowl. Then have the Prowl app on your iPhone or iPad.
Read on for the scripts and how to get it all working.
Continue reading “Setting up SSH Alerts to iPhone”
These are targeted more at home users. I made them for educational purposes for http://www.typicalmacuser.com/
Several folks have asked about the both OpenDNS and SSH to Macs lately. So I thought I would toss the links together here in one spot.
SSH Remote Access for Mac
A long time back I made a post on running Bonjour iTunes sharing over SSH. It works but just for the machine you are SSH’ing into. Well now Yazsoft who makes Speed Downloader recently put out a tool called ShareTool.
Sharetool is a bonjour relay tool over an SSH connection. It uses the existing Remote Login service built into OSX. It can take advantage of your existing setup connection if you already use SSH to access your network from remote. The one odd technical thing I have found is that it seems capable of ignoring the requirement for public key authentication on an existing setup Remote Login configuration. But only when using the ShareTool itself. It does not even provide a means of specifying use of an authentication key. It still honors any user name restrictions you setup under the Remote Login preference panel.
*UPDATE* I found even though I had thought I moved my ssh key out of my folder for testing it had hung onto a key in another location and my passphrase had been cached in my keychain. ShareTool will automatically use your key authentication if the key is present in your .ssh folder and is unable to login to your mac if you require key authentication and the key is missing. Very sweet.
Connecting to remote services adverstised by Bonjour, screen sharing, file sharing etc all worked surprisingly well.
Some additional very nice features are UPnP to automatically configure your router, wanting to use non standard random high ports to avoid SSH bot attacks, updating of Dynamic DNS services like DNS-o-Matic, DynDNS etc. Lastly it passes through access to all Bonjour services on the network you are connecting into.
They provide a evaluation version of the tool that allows 15 minutes of functionality at a time to see if it meets your needs.
One last odd thing about the product. They require you purchase one license for each machine you load the software on. This is only strange because you can only use it in a minimum of a pair. One on the machine you are connecting to and the machine you want to connect from. Usually software that has to work in a pair usually lets you run that with one license up front then just add singles after that. They want you to purchase a single license for $20 USD. At least they offer a “special” $30 USD for a pair of licenses. So look at the product as costing $30 out of the box then $20 for each additional single license after that. A pack of 5 licenses is $75 USD.
You can check out my SSH Screencast Series over at Typical Mac User for more on using SSH/Remote Login services.
Well a nice long but fun screencast series is all in the can. You can find the first episode of eight over at typicalmacuser.com. I spent a good bit of time doing the recording and thanks to Victor for the editing and post production. By the time the series is over you will know pretty much everything I know about SSH. At least all the juicy functional parts. It is done for the target audience of Mac users so it is all about setting it up and tunneling all sorts of traffic through it to protect yourself when on public wifi hotspots or other risky public networks.
I was travelling this past week for my Grandfather’s funeral. He was 94 and did about everything you can imagine in his life.
We stopped at my dad’s place on the way home this weekend. I got to messing with iTunes over the Internet since I had not been able to sync my ipod etc during the week.
It seems iTunes checks the source address of any connections to streaming. So just opening TCP 3689 on my router via remote would not work. I had to trick it into thinking the connection was coming from the same private network segment as my main iTunes is on at home.
So you can add this to your SSH connection line when accessing your home Mac from remote. Replace the homeinternalIP as the local network IP of the mac doing the sharing inside your home network. It might be something like 10.0.1.200 if on an airport extreme N router. This will tell your SSH session to listen locally on the DAAP iTunes sharing port. One other thing. Make sure iTunes sharing on your laptop is off. That way the port is not already occupied.
Next you will need Network Beacon for OSX. This program lets you setup your own Bonjour aka mDNS announcements. This is necessary to fool iTunes into seeing the shared iTunes service. You can grab it at http://www.chaoticsoftware.com/ProductPages/NetworkBeacon.html
Add a beacon that looks like the below image. You will need to make sure your SSH connection is up. Give it a minute and it should start showing in your iTunes on your laptop as the service name. The example below would be homeMac. That is all there is too it. If you have a decent connection speed on both ends you can stream just as if you were on the same network segment at home.
Uploaded with plasq‘s Skitch!
I was playing around with rsync the other night. Now I have a scripted command so I can backup folders from my laptop back to the external harddrive on my iMac at home. You can find the command below.
We need to assume you have done several a couple of things to improve the security of your SSH at home.
- Moved from the standard tcp 22 port to a new port: example 5346
- Turned off password authentication in favor of public-private key authentication.
- Have your ssh private key saved somewhere on your laptop simple like the default ~/.ssh folder. The default keyname is id_rsa if you generated your key with a command like
ssh-keygen -t rsa
- The folder we want to backup is called Documents just in our home folder on our Apple Powerbook.
- We will assume you registered a Dyndns name for you home machine.: example home.homedns.org
- The username on your home iMac or *nix box is: username
- The external drive is called: ExternalDrive
Here is the command you would issue on your Mac or *nix laptop. It should all be on one line. The best part is that it will take a while depending on how much stuff you have in your Documents folder. After that it will only sync over the changes. Perfect when away from home and you want a backup safely off your laptop.
rsync -avrz -e “ssh -p 5346 -i .ssh/id_rsa” Documents firstname.lastname@example.org:/Volumes/ExternalDrive/Backups/Powerbook
I found out one more thing. iGet is hard coded to the default filename id_rsa for the private key. Save that with no passphrase in your .ssh folder and iGet will recognize the key and use it. Nothing else I could do worked. Even changing the name to iGet from id_rsa so I could recognize the key as being the unsecured key for iGet would not work. These guys really ought to take a page from Cyberduck.
Talk about the wrong way to make a piece of software. I was helping a friend get iGet working with his mac. We did not want to leave SSH running on port 22. It was getting hit with all sorts of brute force user guessing attacks. Here are some examples
Sep 4 09:29:27 sshd: Invalid user admin
Sep 4 09:29:37 sshd: Invalid user stud
Sep 4 09:29:45 sshd: Invalid user trash
Sep 4 09:29:51 sshd: Invalid user aaron
Sep 4 09:29:56 sshd: Invalid user gt05
Sep 4 09:30:00 sshd: Invalid user william
Sep 4 09:30:03 sshd: Invalid user stephanie
Sep 4 09:30:40 sshd: Invalid user gary from
Sep 3 16:51:06 sshd: Invalid user nagios
Sep 3 16:51:07 sshd: Invalid user backuppc
Sep 3 16:51:09 sshd: Invalid user wolfgang
Sep 3 16:51:10 sshd: Invalid user vmware
Sep 3 16:51:13 sshd: Invalid user stats
Sep 3 16:51:14 sshd: Invalid user kor
Sep 3 16:51:15 sshd: Invalid user wei
Sep 3 16:51:16 sshd: Invalid user cvsuser
Also we wanted to fix up public key authentication instead of passwords. So we used his Apple airport extreme to map an external port say 3622 to 22 on his Mac in his home network. Then we whipped up public-private key pair. “ssh-keygen -t rsa” was good enough to do that. We of course put a good strong passphrase on it.
Now things like iTerm and Cyberduck on the mac worked great with his new setup. Both the port and the private key. But he has this thing called iGet. It claims key support. But I did let it work with key authentication if the private key had a passphrase. So we had to whip up a second keypair just for that program and append the new public key to his authorized_keys file in his .ssh folder. The worst part is the vendor tried to say that using keys is not inherently more secure than a password because iGet just uses SSH to start the connection then takes over with its own protocol. How stupid. And such a bad attitude. Cyberduck is free and it works way better on key support. Sure iGet has some neat features like access to the remote machine’s spotlight etc. But kiss that advantage goodbye once Leopard comes out. But personally I would not give iGet my money for their product with that attitude and poor private key with passphrase support. By default keys get dumped right into your .ssh folder on a Mac. If there is no passphrase and someone somehow runs code that lets them grab the entire folder contents they would have your access into machines via SSH. At least if it has a passphrase they still have to brute force the key just to use it.
After all it is not two factor authentication if it is just a key without a passphrase. Its one factor. Something you have. Adding something you know (the passphrase) greatly improves the security so in the world of iGet 2=1.