Ssl syscall error software caused connection abort

5 Ways to Fix SSL_ERROR_SYSCALL

SSL_ERROR_SYSCALL typically occurs when the server side is using an SSL certificate to authenticate. This article covers how to fix SSL_ERROR_SYSCALL error in 5 ways.

SSL_ERROR_SYSCALL Error

$ git clone https://github.com/xxx/xxx.git
fatal: unable to access ‘https://github.com/xxx/xxx.git/’: LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443

Understanding SSL_ERROR_SYSCALL Error

This error typically occurs when the TCP three-way handshake between client and server completes but then a TCP reset packet (often written as “RST”) is received by the client, terminating the connection during the SSL phase.

This error is not produced when a client receives a RST packet during the three-way handshake, or after completion of the SSL/TLS negotiation (SSL phase).

Restart the computer

As we all know, restarting solves 90% of problems, and sometimes restarting the computer can directly solve the problem.

Modify Git network configuration

We can directly modify the global Git configuration file and delete the relevant configuration of HTTP / HTTPS in the file.

It can also be modified using the command:

• $ git config –global –unset http.proxy
• $ git config –global –unset https.proxy

Change HTTP/HTTPS encryption library

Since the problem is that the LibreSSL library reports an error, we can modify Git to use the OpenSSL library for HTTPS communication.

$ git config –global http.sslBackend “openssl”

Use HTTPS proxy for git connection

When using HTTPS to connect to GitHub for push/pull, we need to change the local git configuration and use a proxy to initiate a request to GitHub.

Execute the following command: $ git config –global -e

This will bring us into git’s configuration file editing interface (which will open with the default editor specified by git). Add the following to this file:

[http]
proxy = socks5://127.0.0.1:7891
[https]
proxy = socks5://127.0.0.1:7891

“7891” is the designated entry and exit port of our proxy software, please modify it according to the actual situation.

Use SSH for git connection

It is well known that HTTPS or SSH can be used to clone the GitHub repository, but SSH does not have the network connection problem of HTTPS, so the connection method of push/pull can be changed from HTTPS to SSH.

Requirements: we need to generate an SSH public/private key pair in advance and add the public key to our GitHub account. See Connecting to GitHub with SSH for details on this part .

Enter the corresponding directory of the warehouse and execute the following command: $ git remote set-url origin git@github.com:xxx/xxx.git

After the change is complete, we can use the following command to view the current origin address:

Источник

PuTTY Network Error: Software caused connection abort

I have a strange problem: When I’m using PuTTY with SSH connecting to a Linux server hosted in VMware on my local Windows 7, I often get the error saying «Network error: Software caused connection abort» and then the PuTTY SSH window is inactive. Usually I can login in the server with PuTTY and do something, but after a random time (about one or two minutes) I get that error. And sometimes I even can’t login, getting an error saying timeout.

I guess there’s something wrong with my VMware Player, because I have another Ubuntu desktop hosted in VMware as a code repository server, and it more often than not has a timeout error when I do an SVN update/commit. However, I also guess Windows 7 has some quirk because the same Ubuntu server hosted in VMware as a code repository works very well when on Windows Vista! It seems all the bad things happen after I moved from Windows XP to Windows Vista and then Windows 7!

What could be the reason for this problem and how can it be fixed?

Supplement:

I did a Google search and applied all methods to help, including:

1. Enable sshd TCPKeepAlive
2. Set sshd ClientAliveInterval to 900 and ClientAliveCountMax to 3
3. Set the PuTTY connection setting ‘seconds between keepalives’ to 5 .

But these all don’t work! And the SSH session in PuTTY still breaks after sometime!

I turned off both the Linux server firewall and Windows 7 client firewall, but login still times out! It is really annoying!

It seems sometimes I can log in, but sometimes login times out! I really don’t know why. It drives me crazy!

One thing I have to mention is that when I’m using PuTTY SSH connecting to a remote server, and it’s all OK!

When I failed to log in, ping failed too! But, how can that happen? I use VMware player to host the Linux server on my local machine!

12 Answers 12

Windows XP or prior Operating system only:

I wrote this answer 9 years ago for Windows XP, Putty software is 21 years old and so this answer is useful for historical purposes. Window’s current smartphone-based Zune-OS for Desktop has broken Putty at the network level, in pursuit of irritating away all points of entry or exit that are not part of the pay-for-play Azure Vendor tool stack.

Putty has a feature which attempts to fix this problem:

1. Start Putty
2. Load your connection settings if you have them saved
3. Click on “Connection”
4. On the section that says «Sending of null packets to keep session active», Changed it to 5 seconds. 300 seconds may be better if network outages are your problem, read below for details.

How keepalives to prevent disconnection with Putty:

Some network routers and firewalls need to keep track of all connections through them. Usually, these firewalls will assume a connection is dead if no data is transferred in either direction after a certain time interval. This can cause PuTTY sessions to be unexpectedly closed by the firewall if no traffic is seen in the session for some time.

The keepalive option (‘Seconds between keepalives’) allows you to configure PuTTY to send data through the session at regular intervals, in a way that does not disrupt the actual terminal session. If you find your firewall is cutting idle connections off, you can try entering a non-zero value in this field. The value is measured in seconds; so, for example, if your firewall cuts connections off after ten minutes then you might want to enter 300 seconds (5 minutes) in the box.

Reduce the problem using putty autologin and «screen» tool

Putty cannot handle a crappy wifi that loses connectivity for minutes at a time. A work around is to use autologin and screen.

It is a non trivial problem for putty to re synchronize your terminal after a minute long loss in internet connection. You run risks of man in the middle attacks during an outage. You would have to re-authenticate yourself anyway to make sure. Putty doesn’t impose that on you, it just drops you.

So use autologin so putty can auto login on your behalf.

1. Generate a private key with the puttygen tool on the computer you are putty with.
2. Paste the public key in your /home/youruser/.ssh/authorized_keys on the server side, on the server that you are using putty go login to.
3. Make the private key accessible to putty in the putty settings Connection->SSH->Auth
4. Add the private key by specifying the private key file under: «Private key file for authentication».
5. Save the putty connection settings.

Then you would be able to double click your connection through putty, and it should take you right in to the terminal without typing username/password.

So now you can hook a login to putty on that connection with a keyboard combination like F6 . So when the wifi goes bad and you get dropped. You mash down F6 and you’re back logged in.

BUT you still lose the state of your terminal! How to fix that? Use the «screen» program. Make a new screen by typing ‘screen’. A new screen is created.

When you get kicked out and auto login, you can reattach to your screen. Here is a tutorial on how to do that: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

It’s a hassle to type in screen and reconnect every time you get dropped. So you can write a script that will «auto bring you back to the last available screen» to make it transparent.

So then when the putty terminal freezes. It looks like this: You make a snort of contempt, mash down Alt+F4 to close putty, Mash down F6. And in 6 seconds you are back right where you left off.

Even better solution, in theory

In theory you could script out this entire above process, so the terminal detects when it has been dropped, and does all the above steps for you on restoration of the internet connection. If anyone knows a program that does this automatically let me know. It would be neat.

Troubleshooting the PuTTY Network Error

Read what PuTTY has to say about the error

This is a generic error produced by the Windows network code when it kills an established connection for some reason. For example, it might happen if you pull the network cable out of the back of an Ethernet-connected computer, or if Windows has any other similar reason to believe the entire network has become unreachable.

Windows also generates this error if it has given up on the machine at the other end of the connection responding to it. If the network between your client and server goes down and your client then tries to send some data, Windows will make several attempts to send the data and will then give up and kill the connection. In particular, this can occur even if you didn’t type anything, if you are using SSH-2 and PuTTY attempts a key re-exchange.

(It can also occur if you are using keepalives in your connection. Other people have reported that keepalives fix this error for them. (There are pros and cons of keepalives.))

We are not aware of any reason why this error might occur that would represent a bug in PuTTY. The problem is between you, your Windows system, your network and the remote system.

Try a different SSH client

Most likely the problem exists somewhere between PuTTY and the target SSH server. To provide evidence for this, use a different SSH client like (http://kitty.9bis.net) and see if the problem happens on that as well. It probably will which will isolate the problem away from PuTTY.

Suspect spotty Internet connection

The problem may be the spotty Internet connection. Internet Connectivity Monitoring the uptime of an Internet connection is a good way of determining if your ISP are losing packets and is to blame for PuTTY going down. Get some software that tests the uptime of an Internet connection. For example, http://code.google.com/p/internetconnectivitymonitor/. Frequent and long disconnections from the Internet is a breach of ISP service requirements. If this is the case, it will be difficult to prove it’s the ISP’s fault, as tech support automatically blames these sorts of issues on your computer, OS, router, and wiring to your home. If you are using cable Internet and living out in the boonies, it could be possible that defective hardware in your neighbor’s homes could be sending static on the line for a few seconds/minutes when they first turn it on. Finally, it’s possible that there is defective hardware in the ISP’s network to your home. The cost to ISPs to replace their hardware is so high, that often times they won’t do it unless there are enough subscribers in an area to warrent the cost.

Suspect the wired/wireless router

Are you connecting through a wired/wireless router? How old is it? Your router might be the problem. Old wireless and wired technology can get old and drop connections sporadically and restart them, causing PuTTY to die. Remove these components from the equation and see if that solves the problem. Try a wired connection and/or different router to see if that fixes the problem. I had a Linksys wireless router suffer this slow death and drop connections and restart them.

Suspect the operating system providing the SSH connection

The computer you are connecting to with SSH has a policy for number of seconds to keep SSH connections alive. This number is set low for security reasons, and you could increase it. Where this setting is depends on what operating system you are using that provides SSH.

If you are using PuTTY through a virtual machine

If you are using PuTTY passing through a virtual machine, there may be a policy on the virtual machine which is breaking your SSH connection to the server when it thinks it is inactive. Increasing these values depends on which virtual machine software and operating system you are using.

If the Internet connection is bad, SSH client connection workarounds:

If your ISP provides an unstable connection then you could make the disconnections less painful with «ssh autologin». What you do is generate a public and private key. And you tell your foreign server to automatically let in anyone who provides an accurate private key. It doesn’t solve your problem completely, but when the Internet outage happens, all you do is close the window, double click an icon, and you are immediately taken back to your home folder command line without entering a username/password.

Источник

Software caused connection abort: socket write error

I’m trying to use the SSL-components in the JDK1.4, but with little success. When the client tries to make the handshake to the server, an exception is thrown: java.net.SocketException: Software caused connection abort: socket write error. Here’s the complete debug trace:

trigger seeding of SecureRandom
done seeding SecureRandom
%% No cached client session
*** ClientHello, v3.1
RandomCookie: GMT: 1026897800 bytes = < 182, 7, 194, 35, 208, 95, 250, 130, 196, 106, 225, 203, 69, 171, 210, 152,
158, 46, 209, 92, 145, 65, 234, 4, 68, 118, 162, 16 >
Session ID: <>
Cipher Suites: < 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 >
Compression Methods: < 0 >
***
[write] MD5 and SHA1 hashes: len = 59
0000: 01 00 00 37 03 01 3D 35 38 88 B6 07 C2 23 D0 5F . 7..=58. #._
0010: FA 82 C4 6A E1 CB 45 AB D2 98 9E 2E D1 5C 91 41 . j..E. \.A
0020: EA 04 44 76 A2 10 00 00 10 00 05 00 04 00 09 00 ..Dv.
0030: 0A 00 12 00 13 00 03 00 11 01 00 .
main, WRITE: SSL v3.1 Handshake, length = 59
[write] MD5 and SHA1 hashes: len = 77
0000: 01 03 01 00 24 00 00 00 20 00 00 05 00 00 04 01 . $. .
0010: 00 80 00 00 09 06 00 40 00 00 0A 07 00 C0 00 00 [email protected]
0020: 12 00 00 13 00 00 03 02 00 80 00 00 11 3D 35 38 . =58
0030: 88 B6 07 C2 23 D0 5F FA 82 C4 6A E1 CB 45 AB D2 . #._. j..E..
0040: 98 9E 2E D1 5C 91 41 EA 04 44 76 A2 10 . \.A..Dv..
main, WRITE: SSL v2, contentType = 22, translated length = 16310
main, SEND SSL v3.1 ALERT: fatal, description = close_notify
main, WRITE: SSL v3.1 Alert, length = 2
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at com.sun.net.ssl.internal.ssl.OutputRecord.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
at java.io.OutputStream.write(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275)
at trinta.mail.imap.IMAPOverSSL.connect(IMAPOverSSL.java:39)
at trinta.mail.imap.IMAPOverSSL.connect(IMAPOverSSL.java:25)
at trinta.mojo.MoJo.connectToServers(MoJo.java:129)
at trinta.mojo.MoJo. (MoJo.java:95)

I’m initing the SSLContext manually and then creating the socket. Here’s some code: In the code the variable manager is an instance of a class that implementes the X509TrustManager interface.

Any help appreciated.

Comments

I had the exact same problem. I was able to connect to some SSL sites but not one specific server I have desperately been trying to connect to. (That server only supports SSL V3)

What I discovered was that the server did not support a SSLv2 handshake which seems to be the default.
So, I tried the following:
sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket(name,port);
sslSocket.setEnabledProtocols(new String[] <"SSLv3">);

This seems to tell the client socket not to use the «SSLv2Hello» handshake protocol.

This got me to a ServerHello. thrilled about meeting the next obstacle

Источник