Debian Question posted in
The oficial documentation can be found here.

fatal: unable to access "…..": gnutls_handshake() failed: Handshake failed – Debian

I’ve been using Git for the past few months. Recently when I try to clone or to push, I keep on getting this error. I’ve researched on the internet but so far no solution has worked for me. Does anyone have an idea?

External note : Now I moved to different country, it was working perfectly where I was before.
Git Version : 2.11.0 , OS : Debian GNU/Linux 9.11 (stretch)

Error :

git push
fatal: unable to access 'https://**************/': gnutls_handshake() failed: Handshake failed
Tags:

7

Answers


  1. 0

    This error means that Git cannot establish a secure connection to the server you’re trying to use. Your version of Git uses the GnuTLS library to set up TLS (encrypted) connections, and for some reason that setup process is failing.

    This could be for a couple of reasons. One is that your server (which one you haven’t mentioned) is using an incompatible set of cipher suites or TLS versions, and there’s no encryption algorithms in common that can be chosen. It’s also possible that you have someone tampering with the connection via a MITM device.

    The version of Git and GnuTLS you’re using should work just fine with most standard servers. Re-installing it won’t help. You can try upgrading to a newer version of Debian, or you can try building Git yourself against a version of libcurl using OpenSSL. You can also just switch to SSH-based remotes, which will avoid this incompatibility altogether.

    Login or Signup to reply.
  2. 0

    I got the same error.

    You could try to compile git with OpenSSL instead of gnutls using Paul N. Baker’s shell script.

    1. Create file.sh
    2. Put the code of the link into this file
    3. Give permission to this file: chmod a+x file.sh
    4. Run: sudo ./file.sh

    This shell script works for me.

    Login or Signup to reply.
  3. 0

    I also incurred this problem with Ubuntu 14.04 LTS.
    Quickest solution is to use ssh instead of https.
    Following are steps to replace https from ssh:

    1. Generate ssh key using ssh-keygen on the server.

    2. Copy public key from generated id_rsa.pub file from step 1 and add it at following links depending on repository host –

      Bitbucket – https://bitbucket.org/account/settings/ssh-keys/

      Github – https://github.com/settings/ssh/new

      Gitlab – https://gitlab.com/profile/keys

    3. Now run following command to test authentication from server command line terminal

      Bitbucket

      ssh -T [email protected]

      Github

      ssh -T [email protected]

      Gitlab

      ssh -T [email protected]

    4. Go to repo directory and open .git/config file using emac or vi

    5. Replace remote "origin" url (which starts with https) with following –

      For Bitbucket – [email protected]:<username>/<repo>.git

      For Github – [email protected]:<username>/<repo>.git

      For Gitlab – [email protected]:<username>/<repo>.git

    Login or Signup to reply.
  4. 0

    This is solution fix this issue on ubuntu server 14.04.x

    1, Edit file:

    sudo nano  /etc/apt/sources.list

    2, Add to file sources.list

    deb http://security.ubuntu.com/ubuntu xenial-security main
deb http://cz.archive.ubuntu.com/ubuntu xenial main universe

    3, Run command update and update CURL to new version

    apt-get update && apt-get install curl

    4, Check version (Optional):

    curl -V
Response :

curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

    5, Test connect with bitbucket (Optional)

    GIT_CURL_VERBOSE=1 git ls-remote https://bitbucket.org/
Response:


* Closing connection 0
fatal: repository 'https://bitbucket.org/' not found

    This done.

    Login or Signup to reply.
  5. 0

    If you are using Ubuntu 20.04 as mine, using personal computer (with no proxy configured), then just update your gnutls-bin to the latest version

    sudo apt-get install gnutls-bin
    Login or Signup to reply.
  6. 0

    I figure it by

    git config --global --unset https.proxy
git config --global --unset http.proxy

    even though I try

    git config --global --get https.proxy
git config --global --get http.proxy

    don’t show any results, but unset https.proxy still work.

    Login or Signup to reply.
  7. 0

    It might be only a part of the problem.
    How about other https sites?
    How are you connected to the internet?
    Is your git counterpart is reachable through VPN?

    Why am I asking? I faced the same problem:
    Git is used in Ubuntu 22.04 VM hosted in Windows 10 Hyper-X. VM is connected to the Internet trough Default Switch (NAT) and shares OpenConnect VPN connection of the host.

    One day git failed to fetch from remote repo that was located in private network that is reachable through VPN. Symptoms were like yours:

    gnutls_handshake() failed

    After some investigation I found next facts:

    1. All https resources that were reachable through VPN were ping-able with default presets from guest, but Https connection to them could not be established
    2. Other https resources that were not under VPN were reachable and were working normally
    3. While connection attempts to https resources with firefox browser I found some bad packets report in OpenConnect-GUI VPN Client Log:
      OpenConnect Log window

    After that I tried to trace path to remote git repo:
    tracepath-screenshot

    developer@Ubuntu-VM:~$ tracepath **.**.167.240 -n
 1?: [LOCALHOST]                      pmtu 1500
 1:  172.18.224.1                                          0.485ms 
 1:  172.18.224.1                                          0.386ms 
 2:  172.18.224.1                                          0.227ms pmtu 1290
 2:  **.**.254.9                                          38.242ms 
 3:  **.**.30.14                                          32.438ms 
 4:  **.**.167.240                                        32.136ms reached
     Resume: pmtu 1290 hops 4 back 4

    Where I’ve noticed some pmtu strings in the right side of the screen and a final Resume note.

    So, I decided to check MTU preset for my network interface:
    ifconfig-screenshot

    developer@Ubuntu-VM:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.227.200  netmask 255.255.240.0  broadcast 172.18.239.255
        inet6 fe80::d1b:9e02:3919:d75b  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:19:76:00  txqueuelen 1000  (Ethernet)
        RX packets 56234  bytes 311928403 (311.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13927  bytes 1148583 (1.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    as you can see, interface eth0 had MTU 1500 (… that was too much for current VPN tunnel).

    When I’ve changed eth0 MTU to 1290, as suggested tracepath utility:

    sudo ifconfig eth0 mtu 1290

    my problem was solved. (MTU has to be also changed in Ubuntu network setup settings page to take permanent effect)

    Profit!

    Read also: Windows WSL: Git and gnutls_handshake() failed

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search