Github unable to access SSL connect error - ssl

I have been using git lots for the last few months. git push worked 12 hours ago now all attempts generate errors, with verbose it produces this:
GIT_CURL_VERBOSE=1 git push
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
* Trying 192.30.253.112... * Connected to github.com (192.30.253.112) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* NSS error -12190
* Expire cleared
* Closing connection #0
fatal: unable to access 'https://github.com/waveney/wmff/': SSL connect error
Any bright ideas? No changes to server from when it worked to now, restart made no difference

I was having the same problem on various CentOS 6 VM's and it turned out to be an issue with stale curl and nss libraries (thanks to this thread for pointing me in the right direction: cURL SSL connect error 35 with NSS error -5961).
The fix that worked for me is just:
yum update -y nss curl libcurl

yum update -y worked for me to fix a fatal error when running git clone.

Had the same experience as OP, occurring for same reasons (Github's crypto removal notice of TlsV1, along with using a machine with a very old linux + git).
FWIW, if you find yourself on a very old version of linux, but you're stubbornly adamant you don't want to upgrade to a newer version of linux (hence instantly get a newer Git and all its deps), you could try build a newer Git, along with its dependencies from the source.
It's a time-consuming and painful path, and probably upgrading your linux is easier than this, but oh well, I just wanted to stick with my old linux.
I jotted a few notes of my attempt, hopefully it will help anyone that braves this path:
Git depended on openssl and curl, so I had to build those too
I had to upgrade my version of cmake in order to build the newer curl (building cmake took about 2-3 hours)
The newer cmake required me to build a newer gcc (which took about 21 hours to build on my old machine!)
Once I had cmake, I could build curl, but it referenced an older version of openssl (which did not have the newer TlsV1.2)
So I had to build a newer openssl, then followed by building curl (doing my utmost to assure the build referenced this newer openssl)
Then I could build Git, again, doing my best to assure it referenced the newer openssl and curl
I found myself repeatedly using "ldd" to confirm the referenced libraries, as on many occasions, the build would reference the wrong one, and I'd have to figure out how to enforce my desired path.
Some examples of this were:
# ldd /opt/git-2.27.0/libexec/git-core/git-http-fetch | grep -E "libssl|libcrypto|libcurl"
libcurl.so => /usr/local/lib/libcurl.so (0x00aed000)
libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00e86000)
libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00893000)
This helped me confirm 'git-http-fetch" was making using of my newer curl (at /usr/local/lib, and not /usr/lib), and my newer openssl (at /usr/local/ssl/lib, and not /usr/lib)
$ ldd /usr/local/bin/curl | grep -E "libssl|libcrypto"
libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00110000)
libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x0016f000)
This helped me confirm that my new 'curl' was referencing newer openssl (at /usr/local/ssl/lib, and not /usr/lib)
To enforce these paths, Git let you set these env-vars prior to building:
OPENSSLDIR=/usr/local/ssl/
CURLDIR=/usr/local/
For curl, I had to pass the openssl path via cmake:
cmake -DOPENSSL_ROOT_DIR=/usr/local/ssl .
For cmake, it also referenced openssl, and I passed that path across on its 'bootstrap' step:
./bootstrap --prefix=/opt/cmake-3.17.3 -- -DOPENSSL_ROOT_DIR=/usr/local/ssl
Apologies for the answer being all over the place. I can flesh it out with more detail if there is a request for it, but given that its taken me about a week to sort this out, I think most people will prefer the sane path of just upgrading your linux.

Related

Error using Yum DNF on Centos 8.1 Failed to download metadata for repo 'AppStream'

Having great difficulty tracking down what is causing the below error when attempting to update any package from any repo. I have tested multiple repos by setting all others to disabled. I have cleaned all cache and removed any dnf yum cache files.
# dnf -v update
Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync
DNF version: 4.2.7
cachedir: /var/cache/dnf
repo: downloading from remote: AppStream
error: Curl error (28): Timeout was reached for http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock [Resolving timed out after 30000 milliseconds] (http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock).
CentOS-8 - AppStream 0.0 B/s | 0 B 00:30
Cannot download 'http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock': Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock [Resolving timed out after 30000 milliseconds].
Failed to download metadata for repo 'AppStream'
Error: Failed to download metadata for repo 'AppStream'
Each time I attempt a dnf update, load average on the server goes thru the roof, up to 40x
curl can access the mirror site.
curl 'http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock'
http://ftp.tc.edu.tw/Linux/CentOS/8.2.2004/AppStream/x86_64/os/
http://mirror.horizon.vn/centos/8.2.2004/AppStream/x86_64/os/
http://ftp.jaist.ac.jp/pub/Linux/CentOS/8.2.2004/AppStream/x86_64/os/
http://centosg9.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://packet01.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://mirror.s8.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://centoso7.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://centosh9.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://centosc8.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://centosg7.centos.org/centos/8.2.2004/AppStream/x86_64/os/
I have also tried using baserurl in .repo, same error
I have also replaced the baseurl with one of the url's returned by curl, same error
I have tried many suggestions such as yum/dnf error: Failed to download metadata for repo
and similar, none work for me.
Some articles point to bugs in the env vars for $releaseserver etc. I have also tried replacing with actual values. same error.
Internet connection obviously OK due to curl result.
No proxy used.
DNS OK
cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)
uname -a
Linux xxxx 4.18.0-147.5.1.el8_1.x86_64 #1 SMP Wed Feb 5 02:00:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Any suggestions would be greatly appreciated.
For some weird reasons, After setting the nameserver in /etc/resolv.conf to 8.8.8.8 and a reboot fixed the problem for me.
Also, I disabled the Dynamic memory for Hyper-V VM. DNF command is expecting a lot of memory.
Please give it a try.
Regards,
Arockiasamy
The only thing that worked for me was to disable and remove the offending repo.
sudo yum --disablerepo=epel\* remove epel-release.noarch

Manual install of curl can't find openssl

My system (Centos7) install of curl doesn't support https. So I followed this answer downloaded from source and installed myself, using the ./configure --with-ssl option.
I got the following warning while configuring:
checking OpenSSL linking with -ldl... no
checking OpenSSL linking with -ldl and -lpthread... no
checking for ssl_version in -laxtls... no
configure: WARNING: SSL disabled, you will not be able to use HTTPS, FTPS, NTLM and more.
configure: WARNING: Use --with-ssl, --with-gnutls, --with-polarssl, --with-cyassl, --with-nss, --with-axtls, --with-winssl, or --with-darwinssl to address this.
As a result, my curl build does not support https.
Open SSL is installed on my system:
[user#server curl-7.61.0]$ which openssl
/usr/bin/openssl
How can I get my curl install to find openssl and support HTTPS?
Try installing openssl-devel. Development (-devel) packages are usually needed when building from source.

SSL CA cert (path? access rights?)

I am using CentOs 6.6 64bit, and have a problem when using curl. The server primarily hosts several wordpress blogs using apache and mysql.
My simplest means to generate the error is with the following yum command which outputs the below
yum list "ca-certi*"
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64 error was
14: PYCURL ERROR 77 - "Problem with the SSL CA cert (path? access rights?)"
* base: cosmos.cites.illinois.edu
* epel: mirror.cogentco.com
* extras: mirrors.rit.edu
* updates: mirrors.rit.edu
Installed Packages
ca-certificates.noarch 2014.1.98-65.1.el6 #base
Soutions tried and failed so far based from googling around
1) I have tried restarting the VPS, no good
2) Executing curl http://curl.haxx.se/ca/cacert.pem -o /etc/pki/tls/certs/ca-bundle.crt without any luck
3) This solution was no good at all, as it relies on yum to solve the SSL problem that yum also suffers http://syslint.com/syslint/curl-77-problem-with-the-ssl-ca-cert-path-access-rights-solved/
Can I run these yum steps to install with wget?, would you think it would help?
# yum reinstall ca-certificates
# yum reinstall openssl
I think virtualmin had installed some updates in the last 24 hours, is there a log of updates it ran somewhere?
Can anyone please help get around this "Problem with the SSL CA cert (path? access rights?)" problem.
TIA
More easy solution for centos 6/7. Remove ca and reinstall certificate.
rm -f /etc/ssl/certs/ca-bundle.crt && yum reinstall -y ca-certificates
Problem that if you just only reinstall certs. This will dont replace ca-bundle. Leave it new with .rpmnew name.
this worked for me :
centos 6
mkdir /usr/src/ca-certificates && cd /usr/src/ca-certificates
wget
http://mirror.centos.org/centos/6/os/x86_64/Packages/ca-certificates-2015.2.6-65.0.1.el6_7.noarch.rpm
rpm2cpio ca-certificates-2015.2.6-65.0.1.el6_7.noarch.rpm | cpio -idmv
cp -pi ./etc/pki/tls/certs/ca-bundle.* /etc/pki/tls/certs/
do yes to override
to check :
curl -vvv https://www.unixy.net
Solution from here
https://www.virtualmin.com/node/35857
nss-softokn breaks yum/rpm in CentOS 6 In order to fix it do the following:
wget http://mirror.centos.org/centos/6/updates/x86_64/Packages/nss-softokn-fr...
rpm2cpio nss-softokn-freebl-3.14.3-19.el6_6.x86_64.rpm | cpio -idmv
cd lib64
cp libfreeblpriv3.* /lib64
yum update # sync new repo package

Printing Wrong version Number when i run ssh -V

I am upgrading the openssl & openssh versions for QNX platform, from openssl 1.0.0e to 1.0.1g & openssh-5.6p1 to openssh-6.6p1
So using my linux machine I am cross compiling to generate binaries for QNX.
After doing all the steps mentioned below when i run ./ssh -V i am getting this output
OpenSSH_6.6p1, OpenSSL 0.9.8g 19 Oct 2007
But I used openssl 1.0.1g to generate ssh binaries.
Can any one tell me from where i am getting the version wrong?
Steps:
Downloaded openssl-1.0.1g.tar.gz & openssh-6.6p1.tar.gz and then untar it.
2. cd openssl-1.0.1g & run this config command
CC=qcc CXX=qcc AR=nto${I_CPU}-ar LD=qcc RANLIB=nto${I_CPU}-ranlib CFLAGS+="-Vgcc_nto${I_CPU} -fPIC -DPIC" LDFLAGS+="-Vgcc_nto${I_CPU} -shared" ./Configure QNX6-i386 -shared --prefix=/home/vamsi/build_ppc --openssldir=/home/vamsi/build_ppc/openssl_dir
Make clean
Make
Make install
cd openssh-6.6p1 & run this config command
CC=qcc CFLAGS="-Vgcc_nto${I_CPUX} -L/home/vamsi/build_ppc/lib" AR=nto${I_CPUX}-ar LD=qcc LDFLAGS="-Vgcc_nto${I_CPUX} -L/home/vamsi/build_ppc/lib" CXX=qcc CPPFLAGS+="-DMISSING_HOWMANY -DMISSING_NFDBITS -DMISSING_NFDMASK" ./configure --disable-lastlog --host=ppcbe --with-ssl-dir=/home/vamsi/build_ppc/openssl_dir --prefix=/home/vamsi/build_ppc --disable-etc-default-login
make clean
make
After these steps i copied generated ssh binary file into target machine and tried to run ./ssh -V
Also when i copied openssl Binary to target QNX machine and tried to execute this command
./openssl
It is giving this error
./openssl[1]: syntax error: '(' unexpected
Note : I am not installing ssh in the target machine but i just want new version ssh binaries so i am running ./ssh -V instead of ssh -V
I am able to successfully connect to any address using this ssh (generated binary).
and in making this Binary i am getting this warning
skipping incompatible /home/vamsi/build_ppc/lib/libcrypto.a when searching for -lcrypto
Has this warning got anything to do with the problem i am facing ??
I tried using openssl version 1.0.0l but still the output of ssh -v is showing as
OpenSSH_6.6p1, OpenSSL 0.9.8g 19 Oct 2007
After these steps i copied generated ssh binary file into target
machine and tried to run ./ssh -V
Also when i copied openssl Binary to target QNX machine
This and the comments you've posted on your other question about the output of ldd: "It is taking the previous libraries instead of newly generated ones in creating the binaries." seem to suggest you have only copied these two executable files, but not the libraries you've compiled.
You don't need the openssl command to use ssh, but you'll need the OpenSSL libraries (libssl.something.so).
If you want to test this in a local directory instead of overwriting your system's libraries (which I'd recommend, since you don't seem quite sure how this all works), consider using LD_LIBRARY_PATH to point to the path where you've installed those libraries.
In general, it would be a good idea to read about LD_LIBRARY_PATH. On Linux, I'd also look at using ldconfig, but I'm not sure if there's an equivalent on QNX.

dotcloud push on cygwin fails with "rsync error: unexplained error (code 255)" (similar with git and hg)

Though I have followed the usual steps for using the dotCloud CLI under Cygwin, dotcloud push fails in all cases: --rsync, --hg, and --git.
I am on Windows 8 and Cygwin.
How can I push successfully?
Sample output:
me#host /cygdrive/d/project
$ dotcloud push --rsync
==> Pushing code with rsync from "./" to application myapp
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/io.c(605) [sender=3.0.9]
me#host /cygdrive/d/project
$ dotcloud push --git
Permission denied (publickey,password).r from "./" to application myapp
fatal: The remote end hung up unexpectedly
me#host /cygdrive/d/project
$ dotcloud push --hg
==> Pushing code with mercurial from "./" to application myapp
abort: no suitable response from remote hg!
Error: Mercurial returned a fatal error
You may be running into a bug in Cygwin's group permissions. Vineet Gupta gives a workaround in his blog. The problem comes from the very strict permissions expected by ssh around the keys, and the solution is to set the permission on the ssh key properly (to 600, rw by owner only). Cygwin seems to need the group to be added manually.
Updating the steps to get the dotCloud CLI installed, including setting the permissions, leads to:
Start the Cygwin Setup.
Select default choices until you reach the package selection dialog.
Enable the following packages:
net/openssh
net/rsync
devel/git
devel/mercurial
python/python (make sure it’s at least 2.6!)
web/wget
After the installation, you should have a Cygwin icon on your desktop. Start it: you will get a command-line shell.
Download easy_install
wget http://peak.telecommunity.com/dist/ez_setup.py
Install easy_install
python ez_setup.py
You now have easy_install; let’s use it to install pip:
easy_install pip
Now install dotcloud (the CLI)
pip install dotcloud
Set up the CLI with your credentials. This will also download the ssh key.
dotcloud setup
New Step Update the permissions on your dotCloud key:
chgrp Users ~/.dotcloud_cli/dotcloud.key
chmod 600 ~/.dotcloud_cli/dotcloud.key
Now you should be able to dotcloud push
If you have multiple dotCloud accounts, then you will need to repeat this process for each account, since each account has its own key. Also note that you shouldn't have to set these permissions manually, but it seems like the group ownership is sometimes the wrong default in Cygwin. Linux and OSX don't seem to show this problem, though the permissions must be 600 for all OSes, so it is worth checking.