So, to start you need ssh access to a server on the network you want access to. Check

Now you need to know the port of the service on the remote machine you need access to.ARD uses port 5900 for control/observe. Check.

Now, you just need to forward the port like so

ssh -L 9999/10.1.32.25/5900 helios.lcsd2.org

I’ll break that down a bit.

-L 9999/10.1.32.25/5900

The -L requests that port 9999 on the local machine be bound to a secure tunnel over ssh to the remote machine. 10.1.32.25 is the machine that i am trying to access ultimately and 5900 is the port that i want.

helios.lcsd2.org

This is the remote machine i am ssh’ing to. This is the one i have access to outside the network that i use to connect to the computer i want access to inside the network.

So, to recap. I establish a secure connection to helios.lcsd2.org. I choose a local port on the local machine that i want to use to access that secure tunnel. I choose the machine and the port and the end of the tunnel that i want access to. Now all thats left is to connect.

I am assuming here that you are running leopard. In Finder, go to the “Go” menu and choose “Connect to Server”

Now, in the “Connect to Server” box, enter vnc://localhost:9999.

Now, if all is well, you should see a prompt asking for a username and password on the remote machine. Just enter in your credentials and your done! You should now see the screen of the remote machine and have full access to it.

I should point out that this basic technique can applied to just about anything. I used to use it to access my router configuration page when i was away. Just change the ip address to the router and the port to 80 and your good. You could also use this to access internal websites at your company, school, whatever.

Enjoy! Please leave a comment if this was helpful.

In Mac OS X there are at least two methods for resetting a password. And it does require resetting. This isn’t windows, you can’t just boot off a cd and automatically crack the password. Apple decided to used modern encryption techniques 10 years ago that were probably 10 years old then to protect your passwords. Microsoft still hasn’t.

Method number 1: Follow the instructions here to boot off a disc and reset your password the apple way.

Method number 2: Follow my instructions below and reset it the “cool” way.

Before i begin, there’s something i should talk about. In the traditional *nix world (unix, linux, solaris…nix), the idea of storing passwords in a flat file on the filesystem is the norm. Usually, in linux anyway, user info is in /etc/passwd (user id, shell, name, etc.) and the password data is encrypted in /etc/shadow. You will notice in OS X that the file /etc/fstab exists. So that file is where all user account data is stored, right? WRONG! This file exists but it is only consulted/used in any way in single user mode (i’ll get to that later). The thing to take away here is that in OS X, account data is stored in a database. Prior to 10.5 (maybe 10.4 too??) this database was apple’s proprietary netinfo database. In 10.5, netinfo was done away with completely and replaced something else ( i think its openldap). Either way, theres a little more to it than editing a text file.

I mentioned single user mode before. In the *nix world (again. unix, linux, etc.), there is some concept for allowing access to the system without loading the entire system up. You know, in case of emergencies or for maintenance reasons. Microsoft actually does this also with the recovery console…kinda. The important thing is, (unless you’ve locked it down) it gives you access to the system without authenticating. Whats more is that it gives you “root” access.

Ok, lets get to it. To enter single user mode, reboot the machine and, at the chime, hold down the “apple” and the “s” keys. Keep holding them down until you are presented with a text only prompt. We will be modifying files on the filesystem so we need to remount the filesystem as read/write. Type the following:

mount -uw /

Next step, we need to load the daemon responsible for providing access to the account database. This is a little different between 10.4 and 10.5. In 10.4, despite my sincerest efforts, i was unable to find a reliable way of starting only the process needed. I’ve only had trouble on clients 10.4.9 and below and i’m pretty sure its an apple bug. It just doesn’t work right (hangs at blue aqua screen). If you’re using 10.4.9 or below, good luck or check the end of this document for an alternative.

10.4:

sh /etc/rc

In 10.5, apple will actually give you the command to use if you try to use dscl (directory services command line utility).

10.5:

launchctl load /System/Library/LaunchDaemons/com.apple.DirectoryServicesLocal.plist

Now the daemon is running and you have access to the database. What we’re going to do here is enable the root account. Remember how i said that you currently have root access? Well, you can’t type passwd, give it a password and be done. The reason is like i said, right now /etc/passwd is being consulted. At best the command would fail. At worst, nothing would happen. You need to change the directory database root user’s password. I’m pretty sure this is the same in 10.4 and 10.5. We’ll be doing this interactive mode:

dscl .

This opens the command line utility and gives you “shell” access to the database. Next, we navigate to the right user like so…

cd /Users

Pretty easy so far. Now we’ll give the root account a password thus enabling it on boot. You can also substitute “root” here for any other account you see after typing ls to reset that password.

/Users > passwd root
New Password:
/Users >

Just enter your password of choice after “New Password” and your done. Type exit and then reboot to reboot into normal mode

exit
reboot

When the computer comes up, either click on other and type root for user and the password you gave or just type it in the name a password fields and voila! Superuser access. Now be careful. “With Great Power Comes Great Responsibility”. Seriously, the superuser isn’t inhibited by any permissions or many of the security features of the system. You can cause real damage and not even be warned about it with him. That said, you can also use it to ignore permissions and retrieve files or whatever you need to do.

Method 2.b. Make your own account.

Maybe you need into the computer but don’t want to bother any account data already there. The following commands, in non-interactive mode, will create a user called Administrator with administrative privileges.

dscl . -create /Users/"admin"
dscl . -create /Users/"admin" UserShell /bin/bash
dscl . -create /Users/"admin" RealName "Administrator"
dscl . -create /Users/"admin" UniqueID "id"
dscl . -create /Users/"admin" PrimaryGroupID "20"
dscl . -create /Users/"admin" NFSHomeDirectory /Users/admin
dscl . -passwd /Users/"admin" "password"
dscl . -append /Groups/admin GroupMembership admin

One thing about the above. The UniqueID. This has to be unique. One thing you can do to determine a usable uniqueid is to run this command:

echo $[$(dscl . -list /Users uid | awk '{print $2}' | sort -n | tail -n1)+1]

Of course, you’re probably safe using a high number like 550 provided you don’t have 50 or more local users on your machine. You can change the commands above to create a user with a different name, etc. but be careful. Theres a little more to it than that. Here are apples instructions on creating users this way but they leave out creating a group for the user and just using staff instead. Thats probably fine but i’ve had trouble not creating a group before. I may do a writeup on that later.

Now, the security conscious people out there are probably wondering, “isn’t this a huge security hole? I mean anyone can gain root whenever they want”. First, no they can’t. This might sound obvious but to do any of this, they have to be sitting in front of the machine. For years, security experts have said physical security is the first step to a secure system. Seriously, any machine can be compromised if you have physical access to it. FWIW, there are any number of tools available online to reset windows passwords. This same basic technique can also be applied to any linux system that hasn’t been really locked down but again, with physical access, you can reset it. That said, you can’t always have physical security. In a school for example, kids may be in a position to reboot a computer and do this without a teacher really noticing. If you want to, there are a few things you can do to mitigate the problem.

1. Set a firmware password. Here are apple’s instruction for doing so. The upside is it prevents both single user mode and booting from a disc without the password. The downside however is once again, physical security. If you have physical access to the machine you can reset the firmware password by removing some memory, turning it on and off, and putting the memory back in. This is, however, much less easy to do in a school lab environment.
2. Turn on filevault. Filevault will encrypt your home folder and all files in it using aes encryption. Filevault requires your account password to decrypt it or alternatively, the master password. The master password cannot be reset because only the one that encrypted it can decrypt it. This secures your data but a new account could still be made allowing someone to use the machine.
3. Disable single user mode. I hesitate to mention this because people might think its a legitimate thing to do. Don’t. Unless you’re sure you know what you’re doing, don’t. I’m not going to post instructions or links here but a quick google search should give you what you want.

Alternative method.

There is another thing you can do. If you don’t care about the current user account or its corrupt or something, you can reset it completely. Understand that all your login credentials will be wiped out and you will have to create a new one. First, enter single user mode and mount the filesystem read/write. Then do this:

10.4

rm -Rf /var/db/netinfo

10.5

rm -Rf /var/db/dslocal
rm /var/db/.AppleSetupDone

This removes the database files and forces Mac OS X to go through the setup assistant again allowing you to create an administrative account as though it were a brand new machine

Well, i hope this article has been informative. Please leave a comment if you like or have any suggestions/corrections to make.

*Update. Turns out i was a little off on (at least)one thing. In Mac OS X 10.5, netinfo has been completely dropped in favor of xml based files /var/db/dslocal. It looks like the directory services daemon starts at runtime and reads these in allowing for database style queries to it.

*Update 2. I really need to learn to proofread. Corrected many spelling errors and added commands where i had previously left placeholders. Enjoy.

*Update 3. Mac (seriously “mac”? thats the best you could do?) has pointed out that i’ve made a mistake. In 10.5 there is an additional step to take after deleting the directory database. I’ve added it above.

Now, first things first; you need to run your own dns server. Secondly, the target must be using your dns server for lookups.

The first thing we need is the ip address to kittenwar.com. Thats easy. Its 64.111.96.38. I shouldn’t have even mentioned this part.

Secondly, we need to construct a zone declaration that will claim to be the master for anything. I used the following:

zone "." {
	type master;
	file "kittenwar/all.hosts";
	};

It worked great. See, in dns, all domains end with an usually implied “.”. (Its the one between the quotes) This dot represents the root nameservers and how they’re the start of the domain name system. I claim here to be the master authoritative namerserver for any domain ending in “.”. That is to say, all domains.

Next, is the actual redirection…trickery…dns spoofing…whatever. We now need to match all domains to have an A record of 64.111.96.38. Luckily, this is easy. I used the following:

$TTL	86400
@			IN	SOA	localhost. root.localhost. (
					      2		; Serial
					 604800		; Refresh
					  86400		; Retry
					2419200		; Expire
					  86400 )	; Negative Cache TTL
;
@			IN	NS	localhost.
@			IN	A	64.111.96.38
*			IN	A	64.111.96.38

Which also worked great. Most of that isn’t strictly necessary for a zone like this but, i already had that one mostly made. As you can see, we define “.” to have an A record for kittenwar as well as anything else “*”. Well thats great, your done, your target is now going to kittenwar.com and there’s nothing he can do, right? WRONG!! You still need to select that victim to be the one that feels your wrath.

This next step involves views. If your not using views, well, you should. The tricky thing about them is every zone *must* be in a view if even one is. So, remember that. Bind cries bloody tears of pain everytime you don’t. Sorry just wanted to make that point as graphic as possible. You can add them manually if you want. The way i did it, was with acl’s. I used the following:

acl kittened { 192.168.0.102; 192.168.0.110; };

This matches both my brother (192.168.0.102) and myself (192.168.0.110). I added myself so i could test that its working. I recommend doing this temporarily. Now, add the acl to any views that the hosts may already be matched by.

view "internal" {
    match-clients { !kittened; localnets; };
    recursion yes;
    include "/etc/bind/internal/internal.conf";
};

There i’ve removed the acl “kittened” and all its hosts from normal service because i’m going to add them to a completely separate view. Now, lets create that view. The syntax is fairly simple, really just copy and paste from above where necessary.

view "kittenwar" {
    match-clients { kittened; };
    recursion no;
    include "/etc/bind/kittenwar/kittenwar.conf";
};

And thats it. I turned off recursion for this view because its already authoritative for everything. You don’t need to. Give bind a good restart (it tends to like restarts better for changes like this) and try it out. Now any domain/website that the target attempts to visit will simply bring up the page kittenwar.com.

*Note. Operatings systems and browsers both tend to cache dns lookups. It may take some time for these to expire and the effects to be seen. For best results, have ssh access to the machine and clear the cache yourself/reboot the machine. Also, you can do this for any site for which visiting the ip address takes you to the site. Thats not always true, especially with shared hosting. If you have any questions at all, leave a comment.

*Note 2. When the target goes insane and begins chasing you around the house with a bloody chainsaw (why do the chainsaws always already have blood on them?). And it will happen. Its very easy to reverse this. Just remove the ip address from the acl declaration and restart bind. Then restart the machine/clear caches. Intense “The Shining” style killing urges should subside after a while. If it doesn’t, use your telepathic powers to summon the black guy to his death. Somehow thats relevant and everything ends with you living despite being a retarded 9 year old vs a madman with an axe.

I like managing a webserver. I like manually managing bind and apache from the command line. I like the sense of control i feel when i am able to make any changes i want any time i want. What i don’t like though, is email. Email is evil. Go ahead, take a look at the configuration files for sendmail sometime. Try postfix, not much better. I don’t want to do email but i want to get email. So what did i do? I went with google apps for your domain.

Google apps for your domain is a godsend. I make a few small changed to my dns, which i can easily do; specifying google as my mail exchanger (mx) and i’m done. Below i’ve included the records required for email.

@           IN    MX 1     aspmx.l.google.com.
@           IN    MX 5     alt1.aspmx.l.google.com.
@           IN    MX 5     alt2.aspmx.l.google.com.
@           IN    MX 10    ASPMX2.GOOGLEMAIL.COM.
@           IN    MX 10    ASPMX3.GOOGLEMAIL.COM.
@           IN    MX 10    ASPMX4.GOOGLEMAIL.COM.
@           IN    MX 10    ASPMX5.GOOGLEMAIL.COM.

Google handles all my email for me. I can use their nice, friendly-ish web interface to add up to 100 users for email. I can add mailing lists so that an email sent to, for example, lists@jessecole.org would go to whoever i added to that list. I can tie in my other domains with it so that jesse@jessecole.info works just as well as jesse@jessecole.org and it gets delivered to the same mailbox. On top of all of this, i get google’s fantastic! email filtering. I never get a single spam message through and very rarely do i see a false positive. Google even provides pop, smtp, and imap access to my email.

Another feature that isn’t talked about so much is google talk. Thats right, every user i make can log in to google talk with user@domain.com. The can also use any jabber client to log in. Also, i recently implemented XMPP server dialback as per section 14.4 of RFC 3920 allowing virtually all jabber clients to talk to anyone logged in. Ok, fine. All that is accurate but i just followed google’s instructions here. Incidently, its perfectly legal in dns-ese to paste the following into your zone file or include it globally.

_xmpp-server._tcp   IN SRV  5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp   IN SRV 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server._tcp   IN SRV 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server._tcp   IN SRV 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server._tcp   IN SRV 20 0 5269 xmpp-server4.l.google.com.

_jabber._tcp        IN SRV  5 0 5269 xmpp-server.l.google.com.
_jabber._tcp        IN SRV 20 0 5269 xmpp-server1.l.google.com.
_jabber._tcp        IN SRV 20 0 5269 xmpp-server2.l.google.com.
_jabber._tcp        IN SRV 20 0 5269 xmpp-server3.l.google.com.
_jabber._tcp        IN SRV 20 0 5269 xmpp-server4.l.google.com.

Fully qualified domain names are for quitters.

With google apps for your domain you get all this and all of the google apps. Thats right. Your <employee>@jessecole.org account also gets its own google docs, google calendar, google everything!. Its no wonder some businesses are using for their site. The best part about all of this is that its free! You can pay extra and get more users, features, support, etc. Not necessary. This is a great thing for little websites like me.

I hope you enjoyed my little post (post? this is an article!) on google apps. Please, leave me a comment if you liked it/disagree/hate me/whatever.

*Update* I am officially declaring the whitespace stripping in pre text a wordpress bug. I think i’ll actually file one later today. It won’t do it if you step just right through the posting process though so it should look good now.

Quarterly report 2008-01

http://www.jessecole.org

Total uptime:99.13% Downtime:6 hour(s) 13 min(s)
Quarterly uptime:99.13% Downtime:6 hour(s) 13 min(s)
Month 2008-03 Uptime:99.13% Downtime:6 hour(s) 13 min(s)

*Update*So, wordpress helpfully stripped the white space. Yay!

16527
 
time.apple.com


16188
 
www.google.com


4513
 
weather.wapp.wii.com


4235
 
ad.yieldmanager.com


2315
 
news.wapp.wii.com


1907
 
www.symantec.com


1852
 
ad.doubleclick.net


1612
 
105.0.168.192.in-addr.arpa


1347
 
cfh.wapp.wii.com


1320
 
202-177-19-148.kdd.net.hk.jessecole.org

Ok, we can see we have several very popular sites. The first is not quite what you’d expect, its time.apple.com. You don’t think about it but every computer and device you own likely keeps itself synchronized with a time server. Every time it goes to synchronize, it has to do a dns lookup. Actually this number is a tad distorted by the fact that my router decided it should update its time 10 or 11 times a day, (thank you Dlink). I actually got sick of it a made it use the ip address for time.apple.com instead of the hostname so hopefully that number won’t go up so much.

The next most popular query is for www.google.com. No surprise there. Every time you type in the website or use the search bar in your browser and possibly even just visiting certain websites will cause a query to be performed.

The most interesting out of all these though is the fact that, in my top 10 queries, 2 of them (ad.yieldmanager.com and ad.doubleclick.com) are well known ad servers. What a waste of time and bandwidth that is. In the future, i may start blocking queries to well known ad sites just to avoid giving them stats on us.

1319
202.177.19.148
 
692
root


352
84.200.29.111
 
81
admin


275
213.223.16.236
 
79
test


168
211.53.78.104
 
41
guest


156
208.100.6.172
 
34
user


137
61.218.44.69
 
27
clark


120
216.234.56.210
 
23
oracle


105
205.206.124.18
 
21
smith


104
209.189.91.8
 
21
anderson


84
210.192.124.242
 
19
staff

ps. For the love of god if you know how to format that so that both columns are next to each other, tell me! I’ll give you a treat. Really, it will happen.

*Update* I cheated and got a table to do what i want. If anyone can tell me a better way please do. The treat thing still stands.

*Update 2* Nevermind, i’ve decided i like the way looks. After looking around a bit, it appears that there really isn’t a more elegant solution so i’m going to stick with it.

Key-based authentication is an alternative way of authenticating over ssh. Instead of a user name and password, you use a public/private key pair and authenticate this way. A user can optionally be specified as well.

To begin you’ll need to open Terminal.app in your Applications/Utilities folder.

Issue the following command into terminal:

mkdir ~/.ssh

This creates the necessary directory to hold your key.

Now navigate to the directory

cd ~/.ssh

In this directory issue the following command

ssh-keygen

Press enter at every prompt, you should see something similiar to this:

Jesse-Coles-MacBookPro:~/.ssh a$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/a/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/a/.ssh/id_rsa.
Your public key has been saved in /Users/a/.ssh/id_rsa.pub.
The key fingerprint is:
66:e2:df:a0:09:dd:41:aa:4b:d4:6f:f3:22:b3:a2:b4 a@Jesse-Coles-MacBookPro.local

The next step is to copy the public key to the remote machine. First though, the directory must be created.

Initiate an ssh connection to the remote machine.

ssh user@host

Enter your password like usual.

Next create the .ssh on the remote machine.

mkdir ~/.ssh

Now end the connection so you can copy the file to the remote machine.

exit

And copy the id_rsa.pub file to the remote machine

scp id_rsa.pub @:~/.ssh/new.pub

Notice i named the destiation file new.pub, this is so that if the destination machine already has key-based authentication already set up, you won’t overwrite its public key.

Now you need to initiate another ssh connection the the remote machine. This will be the last time you type your password for ssh.

ssh user@host

Now copy your public key to the users list of authorized keys

cat ~/.ssh/new.pub >> ~/.ssh/authorized_keys
exit

Your done!

From now on when you ssh to the remote machine, you will not be prompted for you password.