No need for more hot air in the cloud

Is Amazon’s new music cloud the real deal? This is what Amazon CEO and Founder, Jeff Bezos, is offering you:

“Dear Customers,

Managing a digital music collection can be a bit messy. You can buy music from your phone, but how do you transfer it to your home or work computer? Also, if you’re not regularly backing up your music collection, you can lose it with a disk drive crash.

Today, we’re introducing an important new service to give you a simple way to keep your music safe and have it with you, everywhere. It’s called Amazon Cloud Player. MP3 songs and albums you purchase from, even those you purchased in the past, will be available in Cloud Player, which means you’ll have a secure backup copy of the MP3s you buy at Amazon, free of charge. We’ve also made it easy to get the rest of the music that’s on your computer to Cloud Player, even music purchased from iTunes or uploaded from CDs. We’ll match the songs on your computer to’s catalogue of over 20 million songs. All songs we match are instantly made available in Cloud Player and upgraded to high-quality 256 kbps audio. Music we can’t match will be uploaded to Cloud Player, so your entire digital music collection will be available.”

Yes, managing a digital music collection can be a bit messy at times. So it might be sensible and practical with the security that amazon offers your precious music collection. Just remember its only a backup solution for the music you purchased at Amazon. For Amazon there  is no need for more hot air in the cloud. All Jeff Bezos is offering you is a link to a music file in the Amazon music archive.

Reference:  Amazon Cloud Player

We No Longer Trust Google

Who is lurking in the darkness? Google is lurking the darkness as Gmonster if you ask me, friends of the Internet as well as quite a few grand organizations, legislators, government officials around the world dealing with privacy, security and data protection issues.

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:


Google: Eric Schmidt hints at China ambitions

Google Data Admission Angers European Officials 15. May 2010
WiFi data collection: an update 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
Google Rethinks Privacy, Scales Back Data Collection

Understanding SSH

SSH lets you send secure, encrypted commands to a computer remotely, as if you were sitting at the computer. You use the ssh tool in Terminal to open a command-line connection to a remote computer. While the connection is open, commands you enter are performed on the remote computer.

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 The key fingerprint is: 4a:5c:6e:9f:3e:35:8b:e5:c9:5a:ac:00:e6:b8:d7:96

    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 ( 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 "" 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.


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
    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: 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 rm /Users/anne/Documents/report
    $ ssh -l “rm /Users/anne/Documents/report”
    You’re prompted for the user’s password.

Mac OS X Server (v10.3 or Later): CommandLine Administration (Manual) p. 31 – 35

Test the SMTP Service

To test the SMTP service, follow these steps:
1. Type Telnet at a command prompt (Terminal) , and then press ENTER.
2. At the telnet prompt, type set LocalEcho, press ENTER, and then type open 25, and then press ENTER.
3. Type helo me, and then press ENTER.
The output resembles the following:
250 OK
4. Type mail, and then press ENTER.
The output resembles the following:
250 OK – mail from
5. Type rcpt, and then press ENTER.
The output resembles the following:
250 OK – Recipient
6. Type Data, and then press ENTER.
The output resembles the following:
354 Send data. End with CRLF.CRLF
7. Type Subject:This is a test, and then press ENTER two times.
8. Type Testing, and then press ENTER.
9. Press ENTER, type a period (.), and then press ENTER.
The output resembles the following:
250 OK
10. Type quit, and then press ENTER.
The output resembles the following:
221 Closing Port / Mail queued for delivery