Not able to connect with server. Connection closed by remote server
Solution 1
Following Fred's point in the comments (and actually reading the error message), I was incorrect and ssh was connecting. I will leave my original response at the bottom and additionally answer the question of not being able to connect to a running ssh.
Another good way to diagnose ssh issues when the sshd server refuses connections, and if the OP is correct nothing is getting logged in auth.log
or syslog
, is to run it on a separate port with debugging enabled (I've picked the arbitrary port of 44
).
/full/path/to/sshd -p 44 -d
You can then connect with your ssh client and get further debugging of the issue:
ssh -p 44 [email protected]
Root (as Fred pointed out in his answer) is a user that can potentially be restricted
via the ssh option PermitRootLogin
option in your sshd_config
. Also the types of authentication methods used by your sshd_config
can further restrict how you can access
your host:
RSAAuthentication
PubkeyAuthentication
RhostsRSAAuthentication
HostbasedAuthentication
ChallengeResponseAuthentication
PasswordAuthentication
KerberosAuthentication
GSSAPIAuthentication
Look at the man page for sshd_config (man 5 sshd_config
) for more information on those options. Usually most sshds have RSAAuthentication
, PubkeyAuthentication
and sometimes PasswordAuthentication
. RSAAuthentication
is specific to Protocol 1
and most hosts use Protocol 2
which uses PubkeyAuthentication
. Both rely on root
having a key file (usually found in /root/.ssh/authorized_keys
), but this location can be overridden by the AuthorizedKeysFile
option. It looks like PasswordAuthentication
is not enabled on your sshd.
For RSA and Pubkey authentication you need a keypair. Which you have generated and they live on your client machine in /home/mona/.ssh/id_rsa
and /home/mona/.ssh/id_rsa.pub
. The public half of these two files (the key contained in /home/mona/.ssh/id_rsa.pub) you would need to put in root's authorized_key
file mentioned above.
Original Answer, referring to a failure to connect remotely to the sshd process
That looks like either TCPWrappers or a firewall closing the initial connection.
Check your auth.log
or syslog
files in /var/log
as these may provide some clues as to which is blocking the connection.
TCPwrappers is usually implemented via a /etc/hosts.allow
file and on some unixes an additional or just the /etc/hosts.deny
file (i.e without a hosts.allow file).
Entries are usually of the form:
<service> : <access list> : <allow|deny>
OR
<service> : <access list>
depending on the type of tcp wrapper being used. The format of these files can usually be found with the hosts_access man page man 5 hosts_access
. You may have to add an entry to allow your remote IP access.
sshd : my.ip.address.here : allow
Most distributions with a Linux kernel tend to use iptables
as the main firewall, though some use ipchains
. (I know FreeBSD uses ipfw
which is ported from NetBSD). You service provider may also have a firewall, or router with a firewall in front of your service which is blocking these requests. As to which firewall your hosts uses will need some investigation.
iptables
firewall rules can be listed via the iptables -nvL
command (which must be ran as root, or via sudo). the INPUT
chain is the ruleset used to allow/disallow incoming connections your host. You may have to add a rule to allow SSH connections inbound:
iptables -I INPUT -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from all hosts"
You may want to make it only allow connections from a specific IP:
iptables -I INPUT -s 10.10.10.10 -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from the 10.10.10.10 host"
If your service provider blocks port 22, then you will probably need to put the service on a different port (port 2222
is quite popular) via the Port
option in your sshd_config
file (which usually lives in /etc/ssh
).
Solution 2
Happened to me as well. Here's how I diagnosed and fixed the problem:
When I ran sshd on a different port (not through "service ssh" but straight out of /usr/sbin), I saw some warnings. Turns out I changed the permissions of all the files in /etc/ssh to g+w, so I could edit them as another user in the root group. Bad move. sshd is very particular about this and ignores rsa key files which aren't readonly for anyone but root. I reverted the permissions change and was able to connect again.
Related videos on Youtube
user1957141
Updated on September 18, 2022Comments
-
user1957141 over 1 year
I am trying to ssh remote server from my local server. But whenever i run ssh command:
ssh [email protected]
I get error:
Connection closed by x.x.x.x
Output of ssh -v -v -v -v [email protected] 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 x.x.x.x [x.x.x.x] 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 "151.236.220.15" from file "/home/mona/.ssh/known_hosts" debug3: load_hostkeys: loaded 0 keys debug1: SSH2_MSG_KEXINIT sent Connection closed by x.x.x.x
I have loaded content of my id_rsa.pub in known_hosts keys.
I am not able to ssh login.
Can anybody help me in this? Will really appreciate it.
Thank you.
-
Drav Sloan over 10 yearsThat looks like either tcpwrappers or a firewall closing the connection.
-
user1957141 over 10 years@DravSloan Can u tell how to know which one is closing and how to stop it? Thanks.
-
-
user1957141 over 10 yearsHey, I checked in logs, can't see error related to ssh. My hosts.allow and hosts.deny files are commented. What should i do then?
-
Drav Sloan over 10 yearsCheck that you are running an sshd? Does
pgrep sshd
return anything? If it returns nothing then try:/etc/init.d/ssh start
. If pgrep does return a PID, then is there a firewall blocking the connections to sshd? -
user1957141 over 10 yearspgrep sshd returned number '895'. Is this pid?
-
Drav Sloan over 10 yearsYep that's it's process id or pid. So sshd is running. So it's either not listening on port 22, or a firewall or similar is blocking connections.
-
user1957141 over 10 yearsWhat should i do to make this work then?
-
Drav Sloan over 10 yearsYou can find out what addresses sshd is listening on with
sudo netstat -tulpn | grep sshd
. What addresses is listening on, and what ports.0.0.0.0:22
means it is listening to all interfaces on port 22. If that is the case it is definitely a firewall issue, and refer to my answer about iptables. -
user1957141 over 10 yearsThis is the output: tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 7275/sshd tcp6 0 0 :::22 :::* LISTEN 7275/sshd
-
user1957141 over 10 yearsdoes that mean it is firewall issue?
-
Drav Sloan over 10 yearsIt certainly looks that way...
-
user1957141 over 10 yearscan u tell how to solve it? Please.
-
user1957141 over 10 yearsI ran this command: iptables -I INPUT -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from all hosts" Also changed port to 2222. but still connection is closed. Please help.
-
Peter Choi over 10 yearsThe log seems to indicate the connection can be established: "debug1: Connection established." I don't think it is a firewall issue.
-
Drav Sloan over 10 years@Fred I totally failed to read the error messages! I've updated my answer to reflect that! Cheers