I'm attempting to ssh into an emr instance. The ip and key information are correct. Ideas as to what the problem might be?
session trace:
> ssh -vv -i pemfile.pem hadoop@xx.xx.xx.xx
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file pemfile.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file pemfile.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
ssh_exchange_identification: Connection closed by remote host
> ls -al pemfile.pem
-rw-r--r-- 1 user staff 1692 Aug 24 15:09 pemfile.pem
This can be caused by a number of issues, steps to test are as follows.
Check /etc/hosts.deny and /etc/hosts.allow
Many have reported configuring these to values properly has helped. However, I seen this issue even when hosts.* files were not a factor.
root@host # grep sshd /etc/hosts.allow
sshd: ALL
Missing Dependencies
This one typically happens after a glibc or openssl upgrade. Many distros can install updates to glibc or openssl libs and not require a restart to sshd.
On any distro you can recognize it when after an update, then use lsof to see where sshd has open files. Some will be pointed to DEL, because those libs were deleted on update.
~ # lsof -n | grep ssh | grep DEL
When an SSH connection comes in the sshd daemon forks and attempts to attach (ld) these lib files, and fails resulting in this error.
Corrupted Fingerprint / Keys
Some how one or the other of the fingerprints or keys has become corrupted (did you manually edit one of these files?). Remove the server-side fingerprint in the clients ~/.ssh/known_hosts and try again. When you re-connect you will be prompted to accept the host identity again.
If you are able to access the machine another way you may want to back-out and re-create the server-side ~/.ssh/authorized_keys.
Along the same lines as this issue, if the files /etc/ssh/key are removed and sshd is not restarted then this error will show up too. Check for the key files in the sshd configuration directory.
Heavy Server Load
Have also seen this happen when server was under heavy load from for example, brute force attack. Increase the amount of connections sshd can run.
root@host # grep MaxStartups /etc/ssh/sshd_config
# Old Style
MaxStartups 12
# New Style
MaxStartups 10:20:30
Reference: http://edoceo.com/notabene/ssh-exchange-identification