Version 10 (modified by Jackrabbit, 9 years ago) (diff)


What is secure shell?

Secure shell (also known by its abbreviation: ssh) is a method for securely connecting from one computer (your laptop or desktop computer) to a remote computer (in this case, one of the May First/People Link servers that contains your files).

By connecting to a remote computer via secure shell, you can execute commands on that remote computer, such as setting a cron job or creating your own MySQL database.

Secure Shell uses the same method for authentication as secure FTP. So, if you already know your username, password and host for connecting to your server via secure FTP, you can use the exact same information to connect via secure shell.

How do I run a secure shell program?

Macintosh and Linux

On Macinstosh and Linux computers, secure shell programs are usually installed with your operating system (on Mac OS X it's called the Terminal program and can be found in Applications -> Utilities, on Linux there are a variety of programs with the word terminal in them - check your system menus).

Once you are in a terminal program you can type the following to connect:

ssh username@host

Replace username with your actual username and host with your primary server ( or, etc.).


If you are running Windows, we recommend that you install the free Putty program. The first time you run the program it will prompt you for your host ( or, etc), username and password.


The first time you connect to a server you will be warned that you are connecting to a server for the first time and asked if you want to accept the server's "fingerprint." Please consult with our fingerprints page, comparing the fingerprint you are being offered with the one we have published to make sure they are the same. If so, you may safely tell your program to remember the fingerprint.

I have a command prompt, now what?

There are a number of tutorials on the web. seems to be a good one.

I pointed my DNS servers at Mayfirst and can't get in with my domain name...?

Let's say that when you were developing your site, the URL was During development, you would have ssh'd or sftp's into the server with something like:


But then you launched (congratulations!) and when you try to ssh or sftp with the new URL:

sftp gives you something that looks like:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for has changed, and the key for the according IP address is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is...


Why is this happening?

Your ssh client is giving you a warning about this change. It's alerting you to the fact that it is connecting to a different server than the one you last connected to with the very same domain name. This is handy - in case someone was tampering with your DNS in order to trick you into loging into their server that is masquerading as - ssh is warning you against entering your password or any other sensitive info.

Since the fingerprint you are being offered matches our fingerprint for june, it looks like you are safe to continue.

If you want the error message to go away, you can type:

ssh-keygen -R

That will remove the line from your ssh known hosts file. Then, re-connect and you should only be prompted to confirm the new fingerprint. You can avoid this situation by always connecting to servers using their canonical name (e.g. This might be harder, especially if you are managing a lot of sites on different servers, because you have to remember which may first server each of your web sites is on. I find it easier in the long run because then I can easily connect to a server in use prior to a DNS change and the new server without getting confused.