Recently Google has been caught with their cute innocent Googli map cars sucking the data right out private WiFi networks around the globe in big citys. Reluctantly Google has admitted to this infringement on peoples privacy and has come up with an apology to the citizens of the World Wide Web. Google did not tell the whole truth at first. Google softly claims it to be an error of some unknowing technician. Ha ha.. Is this a joke!?

This mishap might end up having devastating consequences for Google. And this is not the only report about dodgy Google behavior. Google is known to suppress and censor certain undesirable data. Google sniff search keywords not yet submitted in search fields. Google does things to your gmail account you do not even wanna hear about. It all adds up. On behalf of the people of the Internet:

WE NO LONGER TRUST GOOGLE!

Links:
Google Data Admission Angers European Officials nytimes.com 15. May 2010
WiFi data collection: an update googleblog.blogspot.com 14. May 2010
Data collected by Google cars 27. April 2010

Background (just a few):
Countries ask Google to drop “launch now, fix later” policy arstechnica.com
Google Rethinks Privacy, Scales Back Data Collection pcworld.com
Google wikipedia.org

Note: If the SSH service ( sshd daemon ) is enabled you can use any application that supports SSH to connect to a computer running Mac OS X or Mac OS X Server.

How SSH Works

SSH works by setting up encrypted tunnels using public and private keys. Here is a description of an SSH session:

1. The local and remote computers exchange public keys. If the local computer has never encountered a given public key, SSH and your web browser prompt you whether to accept the unknown key.
2. The two computers use the public keys to negotiate a session key used to encrypt subsequent session data.
3. The remote computer attempts to authenticate the local computer using RSA or DSA certificates. If this is not possible, the local computer is prompted for a standard user-name/password combination.
4. After successful authentication, the session begins and remote shell, a secure file transfer, a remote command, or other action is begun through the encrypted tunnel.

The following are SSH tools:

• sshd—Daemon that acts as a server to all other commands
• ssh—Primary user tool that includes a remote shell, remote command, and port-
• forwarding sessions
• scp—Secure copy, a tool for automated file transfers
• sftp—Secure FTP, a replacement for FTP

Generating Key Pairs for Key-Based SSH Connections

By default, SSH supports the use of password, key, and Kerberos authentication. The standard method of SSH authentication is to supply login credentials in the form of a user name and password. Identity key pair authentication enables you to log in to the server without supplying a password.

Key-based authentication is more secure than password authentication because it requires that you have the private key file and know the password that lets you access that key file. Password authentication can be compromised without a private key file.

This process works as follows:

1. A private and a public key are generated, each associated with a user name to establish that user’s authenticity.
2. When you attempt to log in as that user, the user name is sent to the remote computer.
3. The remote computer looks in the user’s .ssh/ folder for the user’s public key. This folder is created after using SSH the first time.
4. A challenge is sent to the user based on his or her public key.
5. The user verifies his or her identity by using the private portion of the key pair to decode the challenge.
6. After the key is decoded, the user is logged in without the need for a password. This is especially useful when automating remote scripts.

Note: If the server uses FileVault to encrypt the home folder of the user you want to use SSH to connect as, you must be logged in on the server to use SSH. Alternatively, you can store the keys for the user in a location that is not protected by FileVault, but this is not secure.

To generate the identity key pair:

1. Enter the following command on the local computer: $ ssh-keygen -t dsa
2. When prompted, enter a filename in the user’s folder to save the keys in; then enter a password followed by password verification (empty for no password).For example:
   Generating public/private dsa key pair. Enter file in which to save the key (/Users/anne/.ssh/id_dsa): frog Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in frog. Your public key has been saved in frog.pub. The key fingerprint is: 4a:5c:6e:9f:3e:35:8b:e5:c9:5a:ac:00:e6:b8:d7:96 annejohnson1@mac.com

   This creates two files. Your identification or private key is saved in one file (frog in our example) and your public key is saved in the other (frog.pub in our example).

   The key fingerprint, which is derived cryptographically from the public key value, also appears. This secures the public key, making it computationally infeasible for duplication.

3. Copy the resulting public file, which contains the local computer’s public key, to the .ssh/authorized_keys file in the user’s home folder on the remote computer (~/.ssh/ authorized_keys).
4. The next time you log in to the remote computer from the local computer you won’t need to enter a password.

Note: If you are using an Open Directory user account and have logged in using the account, you do not need to supply a password for SSH login. On Mac OS X Server computers, SSH uses Kerberos for single sign-on authentication with any user account that has an Open Directory password. (Kerberos must be running on the Open Directory server.) For more information, see Open Directory Administration.

Updating SSH Key Fingerprints

The first time you connect to a remote computer using SSH, the local computer prompts for permission to add the remote computer’s fingerprint (or encrypted public key) to a list of known remote computers. You might see a message like this:

The authenticity of host "server1.example.com" can’t be established. RSA key fingerprint is a8:0d:27:63:74:f1:ad:bd:6a:e4:0d:a3:47:a8:f7. Are you sure you want to continue connecting (yes/no)?

The first time you connect, you have no way of knowing whether this is the correct host key. Most people respond “yes.” The host key is then inserted into the ~/.ssh/ known_hosts file so it can be verified in later sessions.

Be sure this is the correct key before accepting it. If possible, provide users with the encryption key through FTP, mail, or a download from the web, so they can be sure of the identity of the server.

If you later see a warning message about a man-in-the-middle attack (see below) when you try to connect, it might be because the key on the remote computer no longer matches the key stored on the local computer. This can happen if you:

Change your SSH configuration on the local or remote computer.

Perform a clean installation of the server software on the computer you are attempting to log in to using SSH.

StartupfromaMacOSXServerCDonthecomputeryouareattemptingtologinto using SSH.

AttempttouseSSHtoaccessacomputerthathasthesameIPaddressasacomputer that you used SSH with on another network.

To connect again, delete the entries corresponding to the remote computer (which can be stored by name and IP address) in the file ~/.ssh/known_hosts.

An SSH Man-in-the-Middle Attack

Sometimes an attacker can access your network and compromise routing information, so that packets intended for a remote computer are routed to the attacker, who then impersonates the remote computer to the local computer and the local computer to the remote computer.

Here’s a typical scenario: A user connects to the remote computer using SSH. By means of spoofing techniques, the attacker poses as the remote computer and receives information from the local computer. The attacker then relays the information to the intended remote computer, receives a response, and then relays the remote computer’s response to the local computer.

Throughout the process, the attacker is privy to all information that goes back and forth, and can modify it.

A sign that can indicate a man-in-the-middle attack is the following message that appears when connecting to the remote computer using SSH.

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

Protect for this type of attack by verifying that the host key sent back is the correct host key for the computer you are trying to reach. Be watchful for the warning message, and alert your users to its meaning.

Important: Removing an entry from the known_hosts file bypasses a security mechanism that would help you avoid imposters and man-in-the-middle attacks. Before you delete its entry from the known_hosts file, be sure you understand why the key on the remote computer has changed.

Connecting to a remote computer using SSH

Use the ssh tool to create a secure shell connection to a remote computer. To access a remote computer using ssh:

1. Open Terminal.
2. Log in to the remote computer by entering the following command:
   $ ssh -l username server Replace username with the name of an administrator user on the remote computer.
   Replace server with the name or IP address of the remote computer. For example:
   $ ssh -l anne 10.0.1.2
   If this is the first time you’ve connected to the remote computer, you’re prompted to continue connecting after the remote computer’s RSA fingerprint appears.
3. Enter yes.
4. When prompted, enter the user’s password for the remote computer.
   The command prompt changes to show that you’re connected to the remote computer. In the case of the previous example, the prompt might look like this:
   10.0.1.2:~ anne$
5. To send a command to the remote computer, enter the command.
6. To close a remote connection, enter logout.
   You can authenticate and send a command using a single line by appending the command to execute to the basic ssh tool. For example, to delete a file you could use:
   $ ssh -l anne server1.example.com rm /Users/anne/Documents/report
   or
   $ ssh -l anne@server1.example.com “rm /Users/anne/Documents/report”
   You’re prompted for the user’s password.

Reference:
Mac OS X Server (v10.3 or Later): Command-Line Administration (Manual) manuals.info.apple.com p. 31 – 35

• If you do not know how to..
• If you can’t get it to work the way it should..
• If you are stuck with something..
• If your are to your ears with..
• If you need help..

There is a good chance that I can help you online through iChat’s build in screen sharing function.

I am an experienced Apple Mac Super User. I have been working with supporting Apple computers, networks, servers, websites, development, programming, scripting, design, service and Apple users for more than a decade. I love my work.

3 Simple Prerequisites:

1. You have a reliable Internet connection (If you read this you probably have!)
2. iChat with Screen Sharing enabled (All Apple computers ship with iChat)
3. Get a Mac Service Ticket below (Easy and secure online payment with PayPal)

iChat or mail me – and I will help you with your Mac right now: docdyhr@me.com

Your Apple’s best friend, Thomas J. Dyhr

Links: Ichat apple.com

Mac Service Ticket

This is possible on Mac OS X with X11 Forwarding.

THIS ARTICLE HAS BEEN REWRITTEN (Manual set of the $DISPLAY variable is insecure!)

Prerequisites:

X11 environments on both the local and remote machine (see man X). Ensure network access for X11. In Mac OS X  on X11 Quartz check the authorization and client access options under Preferences in the Security pane.

Enable X11 Forwarding with the “X11Forwarding yes” option set in “/private/etc/sshd_config” for your SSH Daemon own local X11 host in order to recieve X11 client request back from  the remote machine through ‘ssh‘ with the -X option set.

Start or restart the Remote Login (SSH) Service  under System Preference / Sharing pane on Mac OS X. The SSH daemon should run on the remote machine as well!

See “man ssh”,  ”man ssh_config” and “man sshd_config” for the complete explanation.

3 Simple Steps to X11 Forward on Mac OS X

1. Open  ”Terminal” in Mac OS X Leopard.

2. ssh -X X11 Forward to your remote host (See “man ssh” for the use of the -X or -Y flag X11 forward):

ssh -X johndoe@123.456.789

3. Start your remote X11 program and view the user display on your local machine:

xeyes &

Voila it works! The X application will start up your X11 environment. Its quite easy to do X11 forwarding when you first get the hang of it.

Do elegant X11 stuff with ssh -X -f  like:

ssh -X -f user@remotehost xcalc -bg black -fg green

Caveat Notes:

Have the latest and updated versions of Mac OS X, Developer and X11.

3 Clues to successful X11 forwarding:

A. When you make changes to /etc/sshd_config remember to restart the Remote Login Service (SSH).

B. Remember to allow incoming access to X11 in the X11 preferences and through your firewall(s) and router!

C. And you have will of curse have to be accurate about your local and remote machine naming convention i.e. John-Does-iMac.local or privat.happycamper.com. Check with “echo $HOSTNAME”. On the remote machine you could also do a check with $REMOTEHOST (if set) to check your own machine name on the remote host.

NOT! Sometimes it is necessary to use xhost +remotehost and set the $DISPLAY environment variable manually on Mac OS X (something -X or -Y flag in ssh should normally do for you). Try “echo $DISPLAY” on the local machine and remote to get hints of the $DISPLAY status. You can always check your environment with “env” and “$”. On Mac OS X Leopard you use EXPORT with bash shell to set environment variables as opposed to tcsh that uses setenv. You should only set the $DISPLAY variable manually in a secure environment i.e. local network.

NEW! Do not set the DISPLAY variable on the client. You will most likely disable encryption. (X connections forwarded through Secure Shell use a special local display setting.)

If you have further problems try to use -v, -vv or even -vvv verbose flag with ssh to debug.

X11 Forwarding:
X11 Forwarding www.ssh.com
Configurering and running X11 Applications on Mac OS X developer.apple.com
X11 FAQ  - Technical Q&A QA1232 developer.apple.com
Technical Q&A QA1383 Enabling X11 Forwarding developer.apple.com
Forwarding X11 from a Remote Computer to the Mac oroborosx.sourceforge.net
ssh X forwarding debugging mac.com
Display Names xfree86.org

X11:
X Window System wikipedia.org
The X Window System freebsd.org (Introduktion from FreeBSD Handbook)
XQuartz project xquartz.macosforge.org (X11)

Command-Line Administration Version 10.5 Leopard (PDF) manuals.info.apple.com (Connecting to Remote Computers p. 31 – 37)
Introduction to Command-Line Administration Version 10.6 Snow Leopard (PDF) manuals.info.apple.com (Connecting to Remote Computers p. 27 – 33)

Open Source X11 developer.apple.com
UNIX & Open Source downloads apple.com

Check it out.. its super cool – and companies like Apple should learn from, integrate or even buy Last.fm

Links:
Last.fm
Fire.fm 1.1.3 Firefox plugin

The idea and promise from is no less than wonderful. For me this was a main reason reason to buy Mac OS X Leopard from Apple. From now on you do not have to think of domain names, dynamic domain names, bonjour identities, ip numbers, firewalls, security, passwords or even bother to start the service – it is just there under your fingertips. Or so I thought! Most of the time Back to My Mac works like a charm when on a local network, but as it turns out Back to My Mac only works sometimes on the Internet. If the moon and your lucky star is in conjunction.

I think Apple is very well aware of this fact and is working to solve issues related to Apple technologies. Some issues also involves Apple Remote Desktop. But there are unfortunately also other factors to be considered. There has been a lot of heated discussion about this topic in the the Apple Support Discussion Forums. Recently I have experienced that some of the threads oddly has disappeared from the forums.

Even with Mac OS X Leopard 10.5.2 I experience the following persistent problems:

1) Macs are unable to see each other over the Internet through Back to My Mac.
2) Back to My Mac Window Sharing asks unnecessarily for another password in mid session and will not accept the correct password.
3) Back to My Mac Service seems disappear and appear randomly.
4) Back to My Mac sometimes seem to break or interrupt access with Apple Remote Access.

What to do?

Links:
Using Back to My Mac in Mac OS X 10.5 Leopard apple.com
Back to My Mac: Supported router devices (Mac OS X 10.5) apple.com

James Allchin, Windows development chief

Windows development chief: ‘I would buy a Mac if I didn’t work for Microsoft’ computerworld.com 11. december 2006