Changing VNC password from Mac OSX terminal

As many of you might have already know MAC OSX has a somewhat integrated version of the ever popular VNC server under the name of screen Sharing; this will allow you to connect to the desktop of another MAC. This is all great, however what if you are not able to access that Mac to change the password and you only have SSH access into the device how can you change the password to allow you desktop access?

Don’t get me wrong being an enthusiast  of Linux I dont have a problem working from the terminal but certain things are better done with the GUI if you are pressed for time.

Some background; once you have enabled remote management and screen sharing on a MAC the following files are created within the /Library/Preferences folder:


If these files are not present then this service was not enabled and you can manually create these files from the terminal using your favorite text editor. The file of interest to us today is , this file contains a hashed value of the VNC password a simple 32 character alphanumeric string.

By default this file has a permission of 400 or read only and is only accessible to Root. So after I noticed that this file was present, I immediately changed the permission so I could read it and started thinking of ways to reverse the file. Since time was of the essence  I did the following instead:

  1. Change the file permission:

chmod 777

2. Next I created a VNC password on a MAC that I have access too then SSH into that MAC and copied the   hash value from that machine’s version of

3. I then SSH back into the original MAC that I was locked out of and echoed that new value into the same file on the first MAC.

$ echo “A8G8B8AOD8FHA8DFAHD8F” >

 4.  Lastly just restart the service and logo with your newly created password

 $ sudo /System/Library/CoreServices/RemoteManagement/ -restart -agent

Have fun and let me know if it worked! Sometimes the easiest solutions are the best ones 🙂


Notes for Linux Basix Eps019

The below post is just a quick writeup that can be serve as an addition to the show notes for my segment on the Linux Basix podcast.

Discussion Links:

  1. Gmail made you look like a spammer this week –>  Graham Cluley’s blog Over 4 million Gmail users had their email messages being sent multiple times. “At least if your home or business computer was spewing out spam you can pull the cable out of the back of your PC. With web base services like Gmail you dont have that option”
  2. and–> Great blogs for learning the commandline, keep reading and you will be a command line Ninja one day.
  3.–> Tons of interesting plug-ins for you to have fun with.
  4. –> 20 Linux System Monitoring Tools Every SysAdmin Should Know, with over 143 comments a **Must Read**.

Installing OpenSSH 5.6

Now in keeping with my theme of always keeping your software update, I notice that a new version of OpenSSH was released on August 24th. Why update you might as?

List of features that my change your mind:

Changes since OpenSSH 5.5

* Added a ControlPersist option to ssh_config(5) that automatically
starts a background ssh(1) multiplex master when connecting. This
connection can stay alive indefinitely, or can be set to
automatically close after a user-specified duration of inactivity.

* Hostbased authentication may now use certificate host keys. CA keys
must be specified in a known_hosts file using the @cert-authority
marker as described in sshd(8).

* ssh-keygen(1) now supports signing certificate using a CA key that
has been stored in a PKCS#11 token.

* ssh(1) will now log the hostname and address that we connected to at
LogLevel=verbose after authentication is successful to mitigate
“phishing” attacks by servers with trusted keys that accept
authentication silently and automatically before presenting fake
password/passphrase prompts.

Note that, for such an attack to be successful, the user must have
disabled StrictHostKeyChecking (enabled by default) or an attacker
must have access to a trusted host key for the destination server.

* Expand %h to the hostname in ssh_config Hostname options. While this
sounds useless, it is actually handy for working with unqualified

Host *.*
Hostname %h
Host *

* Allow ssh-keygen(1) to import (-i) and export (-e) of PEM and PKCS#8
keys in addition to RFC4716 (SSH.COM) encodings via a new -m option

* sshd(8) will now queue debug messages for bad ownership or
permissions on the user’s keyfiles encountered during authentication
and will send them after authentication has successfully completed.
These messages may be viewed in ssh(1) at LogLevel=debug or higher.

* ssh(1) connection multiplexing now supports remote forwarding with
dynamic port allocation and can report the allocated port back to
the user:

LPORT=`ssh -S muxsocket -R0:localhost:25 -O forward somehost`

* sshd(8) now supports indirection in matching of principal names
listed in certificates. By default, if a certificate has an
embedded principals list then the username on the server must match
one of the names in the list for it to be accepted for

sshd(8) now has a new AuthorizedPrincipalsFile option to specify a
file containing a list of names that may be accepted in place of the
username when authorizing a certificate trusted via the
sshd_config(5) TrustedCAKeys option. Similarly, authentication
using a CA trusted in ~/.ssh/authorized_keys now accepts a
principals=”name1[,name2,…]” to specify a list of permitted names.

If either option is absent, the current behaviour of requiring the
username to appear in principals continues to apply. These options
are useful for role accounts, disjoint account namespaces and
“user@realm”-style naming policies in certificates.

* Additional sshd_config(5) options are now valid inside Match blocks:


* Revised the format of certificate keys. The new format, identified as
ssh-{dss,rsa} includes the following changes:

– Adding a serial number field. This may be specified by the CA at
the time of certificate signing.

– Moving the nonce field to the beginning of the certificate where
it can better protect against chosen-prefix attacks on the
signature hash (currently infeasible against the SHA1 hash used)

– Renaming the “constraints” field to “critical options”

– Addng a new non-critical “extensions” field. The “permit-*”
options are now extensions, rather than critical options to
permit non-OpenSSH implementation of this key format to degrade
gracefully when encountering keys with options they do not

The older format is still supported for authentication and may still
be used when signing certificates (use “ssh-keygen -t v00 …”).
The v00 format, introduced in OpenSSH 5.4, will be supported for at
least one year from this release, after which it will be deprecated
and removed.

Install time…

I am attempting to install this on a headless Ubuntu server the first command I am going to try is:

# sudo apt-get install openssh-server openssh-client

Now since this was a recent release your average apt-get install command wouldn’t work here because it takes some time for the many repository to be populated with the new versions.

Obtaining your copy…

Just do a quick wget



You will need working installations of Zlib and OpenSSL.

Zlib 1.1.4 or or greater (earlier 1.2.x versions have problems):

OpenSSL 0.9.6 or greater:

Building / Installation
To install OpenSSH with default options:

make install

While I was waiting with excitement for my new app to build and install I keep getting the following error “configure: error: *** OpenSSL headers missing – please install first or check config.log ***”

Decided to upgrade to version Ubuntu 10.04

  1. Install update-manager-core if it is not already installed:
    sudo apt-get install update-manager-core
  2. Follow the on-screen instructions.
  3. sudo do-release-upgrade
  4. edit /etc/update-manager/release-upgrades and set Prompt=normal
  5. Launch the upgrade tool:

Only to realize that the fix was to install the libssl-dev package

apt-get install libssl-dev

Other useful commands I used:

uname -a –> Print basic information currently available from the system (Kernel version and so on)

ssh -v –> Shows you ssh version number

cat /etc/issue –> Shows you your Ubuntu build version

openssh version –> Shows you your openssh version number

Lastly you can take a read of my posting on the DLL hijacking issue if you haven’t been following it.