SSH: Connection closed by remote server - ssh

Question

I am trying to ssh login to my remote server. But whenever i try to login through terminal using ssh command:
ssh root#{ip_address}
I get error:
Connection closed by {ip_address}
I checked hosts deny and hosts allow, there is nothing in the file. I am not getting why it happening?
It happened when i changed my workstation and key got changed. When i tried ssh login, it asked to add key and i entered yes and then it closed the connection.
Is there any way to get connected with ssh again?
Your help is appreciated.
Thank you.
Edit:
Output of ssh -v -v -v -v root#{ip_address} is
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {ip_address} [{ip_address}] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/mona/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/mona/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/mona/.ssh/id_rsa-cert type -1
debug1: identity file /home/mona/.ssh/id_dsa type -1
debug1: identity file /home/mona/.ssh/id_dsa-cert type -1
debug1: identity file /home/mona/.ssh/id_ecdsa type -1
debug1: identity file /home/mona/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "{ip_address}" from file "/home/mona/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 151.236.220.15

Answer 1

Had the same issue but a simple remote server reboot helped.

Answer 2

Are you sure your server is permitting root logins via SSH?
If not, I suggest using a different account with sudo privileges instead of enabling root login - especially if the server's SSH port is accessible from the whole inernet.

Answer 3

try sudo ssh root#{ip_address}, it works for me.

Answer 4

I tried to connect with a user, which had :/bin/false in /etc/passwd. After changing it to :/bin/bash the connection was not closed anymore.

Answer 5

I had a similar issue that was resolved by lowering the MTU on the client side with the following command:
ip li set mtu 1400 dev eth0
I found this solution from a separate thread on serverfault.

Answer 6

I was getting the same "Connection closed by {ip_address}" error on one of my SSH connections. I tried all the usual solutions and nothing worked. Finally I found that the ~/.ssh/authorized_keys file on the host was corrupted. Someone had tried to append a key to the file, but they copied and pasted it with embedded line feeds where each line wrapped at the end. So what should have been one continuous string spanning three lines was actually three separate strings -- one per line. Since the embedded line feed was exactly at the end of the line, it was not apparent from looking at it.
I deleted the offending key and added my own. Then everything worked as expected.

Answer 7

I temporarily disabled my antivirus firewall and this maybe helped a bit.
Now it suddenly says Shell access is not enabled on yr account! Connection closed.
So I logged into my WHM server.domain_name:2087 and clicked on Modify domain and enabled Shell Access for the website.
(Or ask your host provider to enable SSh for you if you do not have a WHM server)
Login success, it now says:
Last login: 03:37 from . [user#whm_domain_name ~]$

Answer 8

I myself had same problems while working with cloud9 editor. Mine was cause from high CPU usage. It would get fine after stopping apache connection.

Answer 9

Check the name being used to connect to the ftp site, its either wrong or multiple names are being sent for uthentication.