Why won’t terminal let me ssh in to the lan server when Windows/Putty works fine

There is a lot of conflicting information I've read whenever I look up information on using ssh-agent (passphrase saving/reusing process) under Mac OS X. Most resources seem to suggest that simply issuing ssh-add -K will let you store your passphrase, and will automatically configure OS X to launch ssh-agent automatically and load your stored passphrase.

Note: Running ssh-add -K will only work if you have your private key file in one of the common locations, those locations being limited to: ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/identity. If the file is located anywhere else you should specify that path after the -K in the command above.

The reason you are getting the key file passphrase dialog when connecting to the second (key-less) server is likely because the default configuration of SSH servers is to use public key authentication first, and 'keyboard interactive' authentication second.

Because you have a public key with a standard name/location (~/.ssh/id_rsa), your OpenSSH client helpfully submits the private key in order to allow the server to match it against an allowed authorized_keys file.

There are a small handful of ways to prevent this, the easiest two being to pass a flag on the command line, or add it as a permanent configuration item in your ~/.ssh/config file.

1. When connecting to the secondary/key-less server, you can add -o "PubkeyAuthentication=no" when connecting. Something like ssh -o "PubkeyAuthentication=no" me@devserver2.

2. Open up ~/.ssh/config in your favorite text editor, create it first if you must, and enter the following:

   Host devserver2  
       User me  
       PubkeyAuthentication no
   

Now, if you simply type ssh devserver2 the username and pubkey configuration will be read in and used, and you should be prompted for your password and nothing else.

(Note: Replace devserver2 with the actual hostname of the server. Alternatively, pick a nice hostname, such as devserver2, and add a property between User and PubkeyAuthentication called 'Hostname' and put the name or IP address of the server there. Afterwards, you actually can simply type 'ssh devserver2' and all the configuration properties will work their respective magic.)

The first time you connect to a server, you are prompted to accept the fingerprint for the host you are connecting to. The fingerprint is a combination of a digital signature, the host name and the IP address of the server. When you do accept, the fingerprint is saved in ~/.ssh/known_hosts as being a "trusted" host.

For some reason, the server's fingerprint has changed since the first time you connected to it. This may be because it is not the server you expect it to be, for example when your request is being intercepted and redirected to a different server. Hence the security warning. The explanation might also be less malicious, for example when the server was replaced/reinstalled without restoring it's previous digital signature, or when the IP address has changed.

If despite the security warning, you still trust the server you are connecting to, you should open ~/.ssh/known_hosts and look for the line starting with the address of the server you are connecting to. Remove the entire line and save your changes, then reconnect to the server. The first time you connect, it should again prompt you to accept the updated fingerprint, after which you should have no more troubles connecting to that host.

The reason why it would work with sudo is because in those conditions you are running it as a different user (root), and each user has it's own known_hosts file (for root this is located at /private/var/root/.ssh/known_hosts). root may have never recorded the previous fingerprint of that host, and therefor has no way of comparing it to the current one, and no reason to distrust the server.