Can some one help me to get rid of following:
vijay13@ubuntu:~$ git clone git://anongit.kde.org/plasma-mediacenter
Cloning into 'plasma-mediacenter'...
fatal: read error: Connection reset by peer
And
vijay13@ubuntu:~$ git clone git@git.kde.org:plasma-mediacenter
Cloning into 'plasma-mediacenter'...
Read from socket failed: Connection reset by peer
fatal: The remote end hung up unexpectedly
How to get rid of both above issues?
Machavity♦
30.5k27 gold badges90 silver badges100 bronze badges
asked Jul 31, 2013 at 17:37
0
If internet connection is also fine, just run
git gc
and try again. It cleans up unnecessary files and optimize the local repository. For more details: git documentation
answered Dec 22, 2015 at 11:25
user846316user846316
5,7775 gold badges27 silver badges39 bronze badges
5
I also have faced with this problem.
The problem is solved when i replace «git://» with «https://»
root@ubuntu:~# git clone git://github.com/osrg/ryu.git
Cloning into 'ryu'...
fatal: read error: Connection reset by peer
root@ubuntu:~# git clone https://github.com/osrg/ryu.git
Cloning into 'ryu'...
remote: Counting objects: 25613, done.
remote: Compressing objects: 100% (5/5), done.
Receiving objects: 37% (9609/25613), 18.68 MiB | 60.00 KiB/s
answered Jul 5, 2017 at 11:21
Yavuz SertYavuz Sert
2,1672 gold badges11 silver badges25 bronze badges
This can also be an issue when deleting repos (but not permanently). Make sure the repo is deleted in the trash/ recycling bin before cloning.
Alternatively press SHIFT + DEL to delete a folder/ file permanently.
answered Sep 21, 2017 at 9:26
Aaron ThompsonAaron Thompson
1,8111 gold badge24 silver badges31 bronze badges
This may be due to outdated git dependency library. Try updating curl for your operating system.
answered Jan 17, 2019 at 6:06
Rajan TwanabashuRajan Twanabashu
4,4865 gold badges42 silver badges53 bronze badges
For me, this issue happened when changed my PHP version to 7.0.10 from 5.6 version in WAMP. for quick solution, reverting the change, fixed my issue back.
answered Oct 8, 2020 at 5:57
PamiraPamira
1297 bronze badges
For the first issue
vijay13@ubuntu:~$ git clone git://anongit.kde.org/plasma-mediacenter
Cloning into 'plasma-mediacenter'...
fatal: read error: Connection reset by peer
Here you are trying to check out a code by using the above command.
I even encounter this error : Connection reset by peer when try to check out a code.
It is a problem with your internet connection.
Check your internet connection and try again.
It helped me.
answered May 8, 2015 at 9:33
SkittySkitty
1,66918 silver badges20 bronze badges
I tried using git config —global http.postBuffer 157286400 but did not work.
Then tried one more time and it work so looks like intermittent network issue.
answered Nov 19, 2021 at 9:50
Introduction
A remote machine has prevented an SSH connection you were attempting to establish or maintain. The “ssh_exchange_identification: read: Connection reset by peer” message is not specific enough to immediately explain what triggered the error.
To be able to resolve the issue successfully, we first need to identify its cause. This article provides an in-depth analysis of the likely causes and provides the most effective solutions.
By reading this tutorial, you will learn how to fix the “ssh_exchange_identification: read: Connection reset by peer” Error.
Prerequisites
- Necessary permissions to access remote server
- A user account with root or sudo privileges
The “ssh_exchange_identification: read: Connection reset by peer” error indicates that the remote machine abruptly closed the Transition Control Protocol (TCP) stream. In most instances, a quick reboot of a remote server might solve a temporary outage or connectivity issue.
Note: Network-based firewalls or load-balancers can sometimes distort IPs or security permissions. This type of problem can be resolved by contacting your service provider.
Learning how to troubleshoot this issue, and determining the underlying cause, helps you prevent future occurrences on your system. The most common causes of the “ssh_exchange_identification: read: Connection reset by peer” error are:
- The connection is being blocked due to the Host-Based Access Control Lists.
- Intrusion prevention software is blocking your IP by updating firewall rules (Fail2ban, DenyHosts, etc.).
- Changes to the SSH daemon configuration file.
Check the hosts.deny and hosts.allow File
The hosts.deny and hosts.allow files are TCP wrappers. As a security feature, these files are used to limit which IP address or hostname can establish a connection to the remote machine.
Note: Inspect the hosts.deny and hosts.allow files on the remote server, not on the local client.
How to Edit hosts.deny File
Access your remote server and open the hosts.deny file using your preferred text editor. If you are using nano on a Debian based system, enter the following command:
sudo nano /etc/hosts.denyEmpty lines and lines starting with the ‘#’ symbol are comments. Check if you can locate your local IP or host-name in the file. If it is present, it should be removed or commented out, or else it prevents you from establishing a remote connection.
After making the necessary changes, save the file and exit. Attempt to reconnect via SSH.
How to Edit hosts.allow File
As an additional precaution, edit the hosts.allow file. Access rules within the hosts.allow are applied first. They take precedence over rules specified in hosts.deny file. Enter the following command to access the hosts.allow file:
sudo nano /etc/hosts.allowAdding host-names and IPs to the file defines exceptions to the settings in the hosts.deny file.
For example, a strict security policy within the etc/hosts.deny file, would deny access to all hosts:
sshd : ALL
ALL : ALLSubsequently, you can add a single IP address, an IP range, or a hostname to the etc/hosts.allow file. By adding the following line, only the following IP would be allowed to establish an SSH connection with your remote server:
sshd : 10.10.0.5, LOCALKeep in mind that such a limiting security setting can affect administering capabilities on your remote servers.
Check if fail2ban Banned Your IP Address
If you’ve tried to connect on multiple occasions, your IP might be blocked by an intrusion prevention software. Fail2ban is a service designed to protect you from brute force attacks, and it can misinterpret your authentication attempts as an attack.
Fail2ban monitors and dynamically alters firewall rules to ban IP addresses that exhibit suspicious behavior. It monitors logs, like the hosts.deny and hosts.allow files we edited previously.
In our example, we used the following command to check if the iptables tool is rejecting your attempted connections:
sudo iptables -L --line-numberThe output in your terminal window is going to list all authentication attempts. If you find that a firewall is indeed preventing your SSH connection, you can white-list your IP with fail2ban. Otherwise, the service is going to block all future attempts continuously. To access the fail2ban configuration file, enter the following command:
sudo nano /etc/fail2ban/jail.confEdit the file by uncommenting the line that contains "ignoreip =" add the IP or IP range you want to white-list.
Fail2ban is now going to make an exception and not report suspicious behavior for the IP in question.
Check the sshd_config File
If you are continuing to experience the ‘ssh_exchange_identification: read: Connection reset by peer’ error, examine the authentication log entry. By default, the SSH daemon sends logging information to the system logs. Access the /var/log/auth.log file after your failed attempt to login. To review the latest log entries type:
tail -f /var/log/auth.logThe output presents the results of your authentication attempts, information about your user account, authentication key, or password.
The log provides you with information that can help you find possible issues in the sshd configuration file, sshd_config. Any changes made to the file can affect the terms under which an ssh connection is established and lead the remote server to treat the client as incompatible. To access the sshd_config file type:
sudo nano /etc/ssh/sshd_configThe sshd configuration file enables you to change basic settings, such as the default TCP port or SSH key pairs for authentication, as well as more advanced functions such as port-forwarding.
For example, the MaxStartups variable defines how many connections a system accepts in a predefined period. If you have a system that makes a large number of connections in a short timeframe, it might be necessary to increase the default values for this variable. Otherwise, the remote system might refuse additional attempted ssh connections.
Anytime you edit the sshd_config file, restart the sshd service for the changes to take effect:
service sshd restartOnly edit the variables that you are familiar with. A server can become unreachable as a result of a faulty configuration file.
Conclusion
You have thoroughly checked the most common reasons behind the “ssh_exchange_identification: read: Connection reset by peer” error. By looking at each possibility, in turn, you have successfully solved the issue and now know how to deal with similar problems going forward.
The number of potential causes is vast and difficult to troubleshoot in every respect. Ultimately, if the error persists, it might be necessary to contact your host.
I am on OS X trying to ssh into a ubuntu 12.04 server. I was able to SSH in — until abruptly stuff stopped working. I’ve read online to use the -v to debug this. Output is shown below. If I ssh into a different box and then ssh from that box to the server I am able to login. I have no idea how to debug this problem but would like to learn.
$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer
So far (on advice of message boards) I have looked for a hosts deny file — but there is no such file on my machine.
$ cat /etc/hosts.deny
cat: /etc/hosts.deny: No such file or directory
I have admin access on client machine but not on server.
phemmer
69.3k19 gold badges181 silver badges219 bronze badges
asked Aug 24, 2014 at 3:49
7
The abrupt change could be the result of a change in the configuration file on the servers sshd configuration, but you indicate cannot check or alter that without admin right. You can still try the following if the server’s admins cannot be reached (in time).
Your log only indicates the local version string, you should check the versions of sshd running on the server and the intermediate machine.
If these versions differ (especially between the local machine and the server and less between the intermediate machine and the server) there might be some negotiation incompatibility, this has happened before in ssh. The solution used to be to shorten the Ciphers, HostKeyAlgorithms and/or MACs entries, either on the commandline (ssh -c aes256-ctr, etc.) or on in your /etc/ssh/ssh_config.
You should look in the debug information (from connecting via the intermediate to the server) for appropriate values as argument for the -c/Ciphers, -o HostKeyAlgorithms/HostKeyAlgorithms and -m/MACs commandline resp. ssh_config changes.
I haven’t had this problem myself for a while, but IIRC when I did it was enough to manually force the Ciphers and HostKeyAlgorithms setting, after which I could update the server’s sshd version and the problem went away.
answered Aug 24, 2014 at 5:33
AnthonAnthon
77k42 gold badges159 silver badges217 bronze badges
4
You may have been banned by fail2ban or denyhosts. In such a case (and also to check it), if you don’t want to bother with your server provider assistance, you need to log into your server from another IP address : e.g. another server, or a friend’s home connection, or a wifi hot spot, or using SSH with TOR.
Once logged in, check that your IP address indeed appears in /etc/hosts.deny (on the server side). If so, then fail2ban or denyhosts must be the culprit indeed.
See answers to this question for the procedure to prevent denyhosts to block your address continuously. For fail2ban find your ip with iptables -L --line-number and unban you ip with iptables -D <chain> <chain number>, you check details on howtoforge.
You may want to add your IP address to fail2ban and denyhosts whitelists (respectively /etc/fail2ban/jail.conf, line ignoreip, and /var/lib/denyhosts/allowed-hosts, create it if needed (but beware that the path may be different on your distribution)) to prevent the issue to happen again.
answered Feb 3, 2015 at 9:44
0
On the host server, remove the ssh pub.key located here: ~/.ssh/authorized_keysfor your mac. Then tail -f /var/log/auth.log while you open another terminal and try to ssh again ssh -v me@server. If you are prompted for a password then there was a problem with your ssh key. If you are still seeing the ‘ssh_exchange_identification: read: Connection reset by peer’ response, then you should be able to identify what the problem is from the log entry in the ‘/var/log/auth.log’ file after your failed attempt to login.
If you still failed to connect, post the logged entry from the auth file here and I’ll revise my answer.
answered Aug 28, 2014 at 15:22
devnulldevnull
5,23520 silver badges35 bronze badges
1
This can happen if you have multiple machines on the network with the same MAC address (for example, if you make a copy of a virtual machine and forget to change the MAC).
answered Jun 8, 2015 at 16:48
elCapitanoelCapitano
1811 silver badge2 bronze badges
0
Your log means that server-side drops the connection. To find out the reason, you should consult server-side logs, they should show reason for disconnection. You should be almost always be able to find logs in /var/log/messages
I could guess that, as connection dropped just after client sent version number, server somehow threats client as incompatible.
answered Jan 6, 2015 at 12:59
gena2xgena2x
2,34712 silver badges20 bronze badges
I was faced with the same problem. I would open ssh session successfully but it would get reset after some time. When i tried to connect gain immediately i would get the error «Connection refused».
when i debugged the session i got this message at the time when the connection was getting reset
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote host 10.x.y.z: Connection reset by peer
Connection to 10.x.y.z closed.
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1
debug1: Exit status -1
At this point i realized that there was an IP address conflict on the network. I changed to another address and problem was resolved
HalosGhost
4,64410 gold badges32 silver badges40 bronze badges
answered Jan 6, 2015 at 12:26
DavidDavid
811 silver badge3 bronze badges
0
I was getting this due to my ISP’s nameservers in /etc/resolv.conf. These nameservers are often overloaded and if reverse DNS lookup fails sshd will drop the connection. I solved the problem by using more reliable nameservers, e.g. 8.8.8.8.
answered Dec 17, 2014 at 18:38
njahnkenjahnke
1751 silver badge7 bronze badges
I had the same problem but it turned out the cause was different: I was using wrong port.
On newer versions of ssh the error given is Connection refused or Bad port.
On older versions the error given is ssh_exchange_identification: read: Connection reset by peer
So when you get such error check if port is correct.
answered Apr 28, 2017 at 17:31
I know this question is old, but I wanted to share some findings I had. Check if /var/empty/sshd on the server has appropriate ownership and permissions.
We had a chef script that was modified to update some directory permissions, but inadvertently updated the directory below the intended target, changing ownership of /var to an application user/group and changing the permissions to 775.
answered May 20, 2015 at 16:44
0
I ran into this exact error when trying to connect to all my remote hosts via the Wi-Fi bridge option on my Android device (Huawei P30 Pro). When I used the USB tethering option to share the same Internet connection, no problem.
Absolutely nothing else changed in the SSH configuration or options on the client or servers.
TL;DR: sometimes, nothing you can do.
answered Nov 25, 2019 at 17:07
Dan DascalescuDan Dascalescu
7,2314 gold badges18 silver badges24 bronze badges
In my case it was a different IP address prefix length.
The server had set 192.168.0.2/24 while client was 192.168.1.1/23. There was no connectivity issues whatsoever (for example cups printing works) until I tried to ssh.
Check ip addr show on both sides.
answered Dec 15, 2021 at 19:57
mkkotmkkot
1165 bronze badges
I cannot connect to my server via ssh using my computer, but I can connect to this server via my cell phone using termius app. I have checked /etc/hosts.allow and /etc/hosts.deny and my iptables, and I have alse searched google, it seems no answer fits this problem. I don’t know how to solve it , here is ssh -v 183.17.228.80 output
debug1: Connecting to 183.17.228.80 [183.17.228.80] port 22.
debug1: Connection established.=======================
debug1: permanently_set_uid: 0/0
debug1: SELinux support disabled
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
ssh_exchange_identification: read: Connection reset by peer
I can ping this server, here is telnet
telnet 183.17.228.29 22
Trying 183.17.228.29...
Connected to 183.17.228.29.
Escape character is '^]'.
Connection closed by foreign host.
asked May 25, 2017 at 5:18
11
Just reboot your server which you want to ssh. It worked for me, previously I was facing the same issue.
answered Oct 27, 2017 at 16:55
5
That actually means that your IP is blacklisted by the server. Try to whitelist your IP address to be able to login.
You may take a look at the /etc/hosts list to see if your server’s ip address have changed.
answered Aug 16, 2017 at 13:39
RazzRazz
1751 silver badge3 bronze badges
5
I had the same issue but after restarting the sshd daemon I could connect to host.
sudo systemctl restart sshd && systemctl status sshd
This is only a temporary workaround until you increase the MaxAuthTries parameter.
Fabby
34.1k38 gold badges96 silver badges191 bronze badges
answered Jun 26, 2019 at 8:47
1
The way I solved the problem is I went to the host machine and ran a few commands.
sudo mkdir /var/run/sshd
sudo chmod 755 -R /var/run/sshd
sudo service ssh restart
I got connected to the machine after that.
karel
107k93 gold badges263 silver badges290 bronze badges
answered Jan 22, 2019 at 13:48
It looks like ssh daemon on the server is hung. Are you sure it is running? When you telnet to ssh, you have to see a signature. Something like:
telnet unixhow.com 22
Trying 35.228.26.20...
Connected to unixhow.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
What I see from your output is ssh daemon not responding on server side. I recommend to connect via IP-KVM (or in some other way) to the remote machine and restart sshd.
answered Feb 8, 2019 at 5:54
adm.unixadm.unix
761 silver badge4 bronze badges
3
The above error happen when you have limit of failed try to authenticate to the server and you have too many ssh keys on your client (more than value of MaxAuthTries)
What you can try is to increase the value of MaxAuthTries and restart sshd daemon. Or you can limit the number of keys in your ~/.ssh directory and use subdirectories and ~/.ssh/config file to define key per host/group of hosts
answered May 25, 2017 at 6:58
Romeo NinovRomeo Ninov
6996 silver badges12 bronze badges
2
This could be because you do not have an openssh server running on your ubuntu. You can run the below command to check the status of your openssh server.
ubuntu@ubuntu:~$ sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-03-20 11:52:16 GMT; 5min ago
Process: 1034 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 1058 (sshd)
Tasks: 1
Memory: 5.1M
CPU: 122ms
CGroup: /system.slice/ssh.service
└─1058 /usr/sbin/sshd -D
Mar 20 11:52:15 ubuntu systemd[1]: Starting OpenBSD Secure Shell server...
Mar 20 11:52:16 ubuntu sshd[1058]: Server listening on 0.0.0.0 port 22.
Mar 20 11:52:16 ubuntu sshd[1058]: Server listening on :: port 22.
Mar 20 11:52:16 ubuntu systemd[1]: Started OpenBSD Secure Shell server.
Mar 20 11:52:24 ubuntu sshd[1131]: Connection closed by 10.0.2.2 port 60566 [preauth]
Mar 20 11:53:59 ubuntu sshd[1135]: Accepted password for ubuntu from 10.0.2.2 port 60654 ssh2
Mar 20 11:53:59 ubuntu sshd[1135]: pam_unix(sshd:session): session opened for user ubuntu by (uid=0)
Mar 20 11:57:48 ubuntu sshd[1238]: Accepted password for ubuntu from 10.0.2.2 port 61124 ssh2
Mar 20 11:57:48 ubuntu sshd[1238]: pam_unix(sshd:session): session opened for user ubuntu by (uid=0)
If the status is not active (running), you might want to install and/or start the openssh-server. You can do so with the commands shown below.
sudo apt update
sudo apt install openssh-server
answered Mar 20, 2019 at 12:00
My solution is add my local IP address to the /etc/hosts.allow:
sshd:192.168.10.88:allow
this works for me.
answered Jan 16, 2020 at 14:43
aircraftaircraft
1731 gold badge1 silver badge7 bronze badges
There may be many reasons but one of most possible reason can be(in my case it was) ssh / port 22 is not allowed by firewall.
You can allow ssh connection by User-interface (some providers allow that) or If you have any alternative method to login (Ex. digitalocean provide a console button ) you can run below command
sudo ufw allow ssh
sudo ufw allow 22
answered Feb 8, 2019 at 5:39
BSBBSB
4032 silver badges6 bronze badges
I’m using my cellular hot spot to connect to the web, while I was working the console froze, and I couldn’t connect any more ssh_exchange_identification: read: Connection reset by peer
I tried to reset the SRV but it didn’t help
Only when I change my network connection (to a hotspot on a different cellular) I could connect again.
NOTE: I can still use the old connection to connect to SRVs on a different AWS, strange…
answered Jun 11, 2018 at 7:28
Elia WeissElia Weiss
1331 silver badge10 bronze badges
To solve the issue, proceed as follows:
- Reboot your server from server online terminal.
If this does not work,
- Edit the file
$HOME/.ssh/known_hosts - Delete any content inside this file, when it will reconnect to any servers you ssh then you must re-accept connections.
ThunderBird
1,90513 gold badges19 silver badges31 bronze badges
answered Oct 29, 2018 at 7:40
1
I had this same thing happen, and needed to ssh -v ‘ip addr’ and then i saw that i needed to accept the certificate.
Also may be an ACL or route rule blocking putty: example —
Putty client has 10.x.x.x addr with firewalls blocking enterprise network from talking to DMZ hosts, but your cell phone at 58.x.x.x whatever public ip address can talk to the dmz host youre trying to reach.
so I’d look at the ssh -v info when you try to connect again, see if you can glean any info, and then check if there are rules keeping you from getting to your server at a firewall or router level, not in a denyhosts file on the server itself.
answered Feb 4, 2019 at 21:16
DannyDanny
111 bronze badge
- Check that sshd in installed and running of the server.
- Make sure that the daemon is installed and started.You must be able to ‘man sshd’. I think that package it is in is open-ssl, and you will need to start the daemon ( and stop it when you don’t need it.).
answered May 25, 2017 at 5:34
1
After many days, I do not know what was the problem in the end, perhaps I really had too many tries and had to wait. Or it was another thing, like a missing openssh installation. I posted a working guide how to use ssh to download a git repo here, with the core of it as follows:
# first image only to download the git repo
FROM alpine as MY_TMP_GIT_IMAGE
RUN apk add --no-cache git
RUN mkdir -p /root/.ssh && chmod 700 /root/.ssh
COPY /.ssh/id_ed25519 /root/.ssh/id_ed25519
RUN chmod 600 /root/.ssh/id_ed25519
RUN apk -yqq add --no-cache openssh-client && ssh-keyscan -t ed25519 -H gitlab.com >> /root/.ssh/known_hosts
RUN git clone git@gitlab.com:GITLAB_USERNAME/test.git
RUN rm -r /root/.ssh
# Start of the second image
FROM MY_BASE_IMAGE
COPY --from=MY_TMP_GIT_IMAGE /MY_GIT_REPO ./MY_GIT_REPO
answered Mar 23, 2021 at 15:51
When I tried to connect to the server via SSH, I’m getting the following error,
[root@oneeighty ~]# ssh -vvv -p 443 root@xxx.xxx.xxx
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.xxx.xxx [IP] port 443.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
ssh_exchange_identification: read: Connection reset by peer
I have checked the SSH configuration on server and client and there are no issues.
Restarted the SSH Service on Server and then restarted the server/client, but the issues is not resolved.
Nakilon
1281 gold badge1 silver badge8 bronze badges
asked Nov 3, 2012 at 12:55
1
This can be a result of number of things.
Few things you can quickly try are as follows,
- Look in /etc/hosts.deny for any entry like
sshd: ALL -
Perhaps, add
sshd: ALLto/etc/hosts.allow -
It is possible that your SSHD’s HostKeys are corrupt. They’re present in /etc/ssh/ directory. You may delete them and restart sshd and it shall re-generate them. In case it gives an errors, please use the following commands
$ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key $ ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key $ ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key $ /etc/init.d/sshd start
answered Nov 3, 2012 at 13:37
vagarwalvagarwal
8456 silver badges8 bronze badges
2
The next line in the debug should look like:
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7
You’ve confirmed on StackOverflow that you’re using NATing/port forwarding from an external IP address. You’ve also verified that you can ssh from the local box to itself. As sshing locally to port 443 works then you need to verify the port mapping works.
Try:
- SSH from another box in the same subnet
- Run
iptables -Land check that port 443 is open or INPUT and OUTPUT is set to ACCEPT - Run
tcpdump -A -s 0 port 443and then try sshing to the external IP. You should see data arrive with source address of the router
answered Nov 3, 2012 at 15:18
FWIW, I am running Ubuntu 14.04 on AWS. The issue was fixed by SSHing through their Java Web client, and running sudo service apache2 start. I just wanted my website to be back up, but it also fixed the SSH access. No idea why, but I am not complaining.
answered Apr 10, 2015 at 18:22
MazyodMazyod
1293 bronze badges
1
Check allowed.hosts on the server you are trying to connect to, also any iptables rules it’s running.
answered Nov 3, 2012 at 13:35
I faced similar issue today as suddenly the ssh access to a VM was denied with same message. ssh -v (at client) and sshd -d (at server) did not help much.
The problem in my case started due to changed in firewall/iptable settings which I did for some demo of LAMP stack usage.
I used system-config-firewall-tui to enable firewall and selected only httpd from there which blocked all other services except httpd.
So as a solution to this either add permissions to sshd by
- updating iptable conf settings OR
- Selecting sshd from system-config-firewall-tui OR
- Disabling firewall OR
- Stop iptable service (rhel6, also remove it from chkconfig)
service iptables stop
ssh works perfectly fine now !!!
answered Nov 30, 2016 at 0:48
RinkyRinky
111 bronze badge
The Issue has been resolved.
The Problem is on the Load balancers that we have on our network. The Issue is resolved on restarting the Load balancers.
Nakilon
1281 gold badge1 silver badge8 bronze badges
answered Nov 5, 2012 at 5:48
Senthil GSenthil G
2871 gold badge3 silver badges4 bronze badges
1
For me, I to allow sshd connections in /etc/hosts file.
vi /etc/hosts.allow
and add
sshd: ALL
answered Jun 30, 2017 at 7:35
David OkwiiDavid Okwii
3041 gold badge5 silver badges13 bronze badges
The way I solved the problem is, I went to the host machine and ran few commands
sudo mkdir /var/run/sshd
sudo chmod 755 -R /var/run/sshd
sudo service ssh restart
I got connected to the machine after that.
answered Jan 22, 2019 at 13:50
First purging openssh-* (openssh-server and openssh-client)
apt-get --purge remove openssh-*
removing /home/username/.ssh directory
rm -rf /home/username/.ssh
then install your openssh-server and openssh-client
apt-get install openssh-server openssh-client
answered Apr 10, 2014 at 6:10
2
The connection reset by peer is a TCP/IP error that occurs when the other end (peer) has unexpectedly closed the connection. It happens when you send a packet from your end, but the other end crashes and forcibly closes the connection with the RST packet instead of the TCP FIN, which is used to close a connection under normal circumstances. In Go, you can detect the connection reset by peer by checking if the error returned by the peer is equal to syscall.ECONNRESET.
Reproduce the connection reset by peer error
We can reproduce the error by creating a server and client that do the following:
- the server reads a single byte and then closes the connection
- the client sends more than one byte
If the server closes the connection with the remaining bytes in the socket’s receive buffer, then an RST packet is sent to the client. When the client tries to read from such a closed connection, it will get the connection reset by peer error.
See the following example, which simulates this behavior.
package main
import (
"errors"
"log"
"net"
"os"
"syscall"
"time"
)
func server() {
listener, err := net.Listen("tcp", ":8080")
if err != nil {
log.Fatal(err)
}
defer listener.Close()
conn, err := listener.Accept()
if err != nil {
log.Fatal("server", err)
os.Exit(1)
}
data := make([]byte, 1)
if _, err := conn.Read(data); err != nil {
log.Fatal("server", err)
}
conn.Close()
}
func client() {
conn, err := net.Dial("tcp", "localhost:8080")
if err != nil {
log.Fatal("client", err)
}
if _, err := conn.Write([]byte("ab")); err != nil {
log.Printf("client: %v", err)
}
time.Sleep(1 * time.Second) // wait for close on the server side
data := make([]byte, 1)
if _, err := conn.Read(data); err != nil {
log.Printf("client: %v", err)
if errors.Is(err, syscall.ECONNRESET) {
log.Print("This is connection reset by peer error")
}
}
}
func main() {
go server()
time.Sleep(3 * time.Second) // wait for server to run
client()
}
Output:
2021/10/20 19:01:58 client: read tcp [::1]:59897->[::1]:8080: read: connection reset by peer
2021/10/20 19:01:58 This is connection reset by peer error
Handle the connection reset by peer error
Typically, you can see the connection reset by peer error in response to a request being sent from the client to the server. It means that something bad has happened to the server: it has rebooted, the program has crashed, or other problems have occurred that cause the connection to be forcibly closed. Since TCP connections can be broken, there is no need to handle the connection reset by peer in any special way on the client side. You can log the error, ignore it or retry the connection when it occurs. In the example above, we detect the error using the errors.Is() function by checking if the returned error is an instance of syscall.ECONNRESET.
Difference between connection reset by peer and broken pipe
Both connection reset by peer and broken pipe errors occur when a peer (the other end) unexpectedly closes the underlying connection. However, there is a subtle difference between them. Usually, you get the connection reset by peer when you read from the connection after the server sends the RST packet, and when you write to the connection after the RST instead, you get the broken pipe error.
Check how to handle the
broken pipeerror in Go post, where will find another example of generating anRSTpacket and thebroken pipeerror.
Replace the client() function in the example above with the following code to reproduce the broken pipe error.
func client() {
conn, err := net.Dial("tcp", "localhost:8080")
if err != nil {
log.Fatal("client", err)
}
if _, err := conn.Write([]byte("ab")); err != nil {
log.Printf("client: %v", err)
}
time.Sleep(1 * time.Second) // wait for close on the server side
if _, err := conn.Write([]byte("b")); err != nil {
log.Printf("client: %v", err)
}
}
With the new client, you will see the output:
2021/10/20 19:55:40 client: write tcp [::1]:60399->[::1]:8080: write: broken pipe
Note that these simple examples do not cover all cases where connection reset by peer and broken pipe may occur. There are much more situations where you can see these errors, and what error you see in what situation requires a deep understanding of the TCP design.