install.packages не работает с прокси при использовании R, установленной с conda
Я работаю на сервере Linux RHEL6 и я установил анаконду. У меня есть следующие настройки
conda-env version : 4.3.13
conda-build version : 2.1.4
python version : 2.7.13.final.0
rpy2 : 2.8.5
Я установил rpy2, чтобы использовать R в Python
> R.home()
[1] "/anaconda2/envs/py27CCA/lib/R"
> R.version
version.string R version 3.3.2 (2016-10-31)
Я настроил свой прокси следующим образом:
> Sys.getenv("https_proxy")
[1] "https://login:pwd@xxx.net:8080/"
Но загрузка пакетов R не работает
> options(internet.info = 0)
> install.packages("httr")
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
....
Warning: unable to access index for repository https://stat.ethz.ch/CRAN/src/contrib:
cannot download all files
Warning message:
package 'httr' is not available (for R version 3.3.2)
Но если я установил ту же автономную версию R с точно такой же настройкой прокси, она работает без проблем
> R.version
version.string R version 3.3.2 (2016-10-31)
> install.packages("httr")
...
** testing if installed package can be loaded
* DONE (httr)
Making 'packages.html' ... done
...
Что создает эту проблему? Я проверяю версию openssl, и у меня та же версия в 2 средах! Эта ссылка объясняет возможную причину такого обсуждения проблем с переполнением потока ссылок.
У меня те же проблемы и сообщения об ошибках, если я делаю это внутри Python
>>> from rpy2.robjects.packages import importr
>>> utils = importr('utils')
>>> utils.install_packages('httr')
1 ответ
TL;DR:
Вместо настройки https_proxy
для...:
https://login:pwd@xxx.net:8080/
... попробуйте установить его на:
http://login:pwd@xxx.net:8080/
Кроме того, если кто-то прослушивает пакеты начального соединения, которое вы установили с прокси-сервером, вы будете пропускать свои учетные данные. Читайте дальше, чтобы узнать больше.
ИМО, этот вопрос не имеет никакого отношения к Конде. Это очень распространенная ошибка, которая часто встречается в Интернете.
Причина, по которой это происходит, заключается в путанице, лежащей вокруг термина "HTTPS Proxy".
IIUC, вот что означают две переменные среды:
http_proxy | HTTP_PROXY: прокси-сервер, который вы хотите использовать для всех ваших HTTP-запросов к внешнему миру.
https_proxy | HTTPS_PROXY: прокси-сервер, который вы хотите использовать для всех ваших запросов HTTPS к внешнему миру.
http(s?)://proxy.mydomain.com:3128
^^^^^ ^^^^^ ^^^^
| | |
scheme proxy domain/IP proxy port
Теперь в идеале схема, указанная в значении этих переменных среды, определяет протокол, по которому клиент должен подключаться к прокси-серверу.
Давайте посмотрим на определение HTTPS-прокси. Кража со страницы руководства для curl >= v7.53
:
An HTTPS proxy receives all transactions over an SSL/TLS connection.
Once a secure connection with the proxy is established, the user agent
uses the proxy as usual, including sending CONNECT requests to instruct
the proxy to establish a [usually secure] TCP tunnel with an origin
server. HTTPS proxies protect nearly all aspects of user-proxy
communications as opposed to HTTP proxies that receive all requests
(including CONNECT requests) in vulnerable clear text.
With HTTPS proxies, it is possible to have two concurrent _nested_
SSL/TLS sessions: the "outer" one between the user agent and the proxy
and the "inner" one between the user agent and the origin server
(through the proxy). This change adds supports for such nested sessions
as well.
Давайте попробуем и посмотрим на примерах (curl >= v7.53)
:
Здесь я буду использовать прокси, который не поддерживает соединение клиент-прокси через SSL/TLS.
Убедитесь, что переменные окружения прокси не установлены заранее:
((curl-7_53_1))$ env | grep -i proxy
((curl-7_53_1))$
env: http_proxy, external_scheme: http, inner_scheme: http
((curl-7_53_1))$ http_proxy="http://proxy.mydomain.com:3128" ./src/curl -s -vvv http://stackru.com -o /dev/null
* Rebuilt URL to: http://stackru.com/
* Trying 10.1.1.7...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (10.1.1.7) port 3128 (#0)
> GET http://stackru.com/ HTTP/1.1
> Host: stackru.com
> User-Agent: curl/7.53.1-DEV
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< X-Frame-Options: SAMEORIGIN
< X-Request-Guid: 539728ee-a91d-4964-bc7e-1d21d91a6f1d
< Content-Length: 228257
< Accept-Ranges: bytes
< Date: Thu, 16 Mar 2017 05:19:31 GMT
< X-Served-By: cache-jfk8137-JFK
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1489641571.098286,VS0,VE7
< Vary: Fastly-SSL
< X-DNS-Prefetch-Control: off
< Set-Cookie: prov=b2e2dcb8-c5ff-21d9-5712-a0e012573aa6; domain=.stackru.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly
< X-Cache: MISS from proxy.mydomain.com
< X-Cache-Lookup: MISS from proxy.mydomain.com:3128
< Via: 1.1 varnish, 1.0 proxy.mydomain.com (squid)
* HTTP/1.0 connection set to keep alive!
< Connection: keep-alive
<
{ [2816 bytes data]
* Connection #0 to host proxy.mydomain.com left intact
env: http_proxy, external_scheme: https, inner_scheme: http
((curl-7_53_1))$ http_proxy="https://proxy.mydomain.com:3128" ./src/curl -s -vvv http://stackru.com -o /dev/null
* Rebuilt URL to: http://stackru.com/
* Trying 10.1.1.7...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (10.1.1.7) port 3128 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
env: https_proxy, external_scheme: http, inner_scheme: https
((curl-7_53_1))$ https_proxy="http://proxy.mydomain.com:3128" ./src/curl -s -vvv https://stackru.com -o /dev/null
* Rebuilt URL to: https://stackru.com/
* Trying 10.1.1.7...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (10.1.1.7) port 3128 (#0)
* Establish HTTP proxy tunnel to stackru.com:443
> CONNECT stackru.com:443 HTTP/1.1
> Host: stackru.com:443
> User-Agent: curl/7.53.1-DEV
> Proxy-Connection: Keep-Alive
>
< HTTP/1.0 200 Connection established
<
* Proxy replied OK to CONNECT request
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3044 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=US; ST=NY; L=New York; O=Stack Exchange, Inc.; CN=*.stackexchange.com
* start date: May 21 00:00:00 2016 GMT
* expire date: Aug 14 12:00:00 2019 GMT
* subjectAltName: host "stackru.com" matched cert's "stackru.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
} [5 bytes data]
> GET / HTTP/1.1
> Host: stackru.com
> User-Agent: curl/7.53.1-DEV
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< X-Frame-Options: SAMEORIGIN
< X-Request-Guid: 96f8fe3c-058b-479e-8ef2-db6d09f485d3
< Content-Length: 226580
< Accept-Ranges: bytes
< Date: Thu, 16 Mar 2017 05:20:39 GMT
< Via: 1.1 varnish
< Connection: keep-alive
< X-Served-By: cache-jfk8135-JFK
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1489641639.425108,VS0,VE9
< Vary: Fastly-SSL
< X-DNS-Prefetch-Control: off
< Set-Cookie: prov=f1a401f1-f1a0-5f09-66ca-9a792543ee82; domain=.stackru.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly
<
{ [2181 bytes data]
* Connection #0 to host proxy.mydomain.com left intact
env: https_proxy, external_scheme: https, inner_scheme: https
((curl-7_53_1))$ https_proxy="https://proxy.mydomain.com:3128" ./src/curl -s -vvv https://stackru.com -o /dev/null
* Rebuilt URL to: https://stackru.com/
* Trying 10.1.1.7...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (10.1.1.7) port 3128 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
Теперь я покажу те же выходные данные для прокси, который поддерживает соединение через SSL/TLS. Для запуска локального https прокси я установил squid версии 4.0.17. Я указал proxy.mydomain.com на localhost, переопределив его в /etc/hosts
, И соответствующая строка конфигурации squid:
https_port 3127 cert=/etc/squid/ssl_cert/myCA.pem
Обратите внимание, что сейчас я не использую какие-либо явно определенные (сложные?) Режимы (sslbump/intercept/accel/tproxy)
Я также добавил сертификат в доверенное хранилище:
sudo cp /etc/squid/ssl_cert/myCA.pem /etc/pki/ca-trust/source/anchors/mySquidCA.pem
sudo update-ca-trust
Теперь для реального теста:
env: http_proxy, external_scheme: https, inner_scheme: http
/t/curl-curl-7_53_1 ❯❯❯ http_proxy=https://proxy.mydomain.com:3127 ./src/curl -s -vvv http://google.com -o /dev/null
* Rebuilt URL to: http://google.com/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (127.0.0.1) port 3127 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [86 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1027 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [262 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* Proxy certificate:
* subject: C=IN; ST=SomeState; L=SomeLocation; O=Default Company Ltd; CN=proxy.mydomain.com; emailAddress=no-reply@gmail.com
* start date: Mar 16 06:43:35 2017 GMT
* expire date: Mar 16 06:43:35 2018 GMT
* common name: proxy.mydomain.com (matched)
* issuer: C=IN; ST=SomeState; L=SomeLocation; O=Default Company Ltd; CN=proxy.mydomain.com; emailAddress=no-reply@gmail.com
* SSL certificate verify ok.
} [5 bytes data]
> GET http://google.com/ HTTP/1.1
> Host: google.com
> User-Agent: curl/7.53.1-DEV
> Accept: */*
> Proxy-Connection: Keep-Alive
>
{ [5 bytes data]
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Location: http://www.google.co.in/?gfe_rd=cr&ei=ejTKWLGzM-Ts8AepwJyQCg
< Content-Length: 261
< Date: Thu, 16 Mar 2017 06:45:14 GMT
< X-Cache: MISS from lenovo
< X-Cache-Lookup: MISS from lenovo:3128
< Via: 1.1 lenovo (squid/4.0.17)
< Connection: keep-alive
<
{ [5 bytes data]
* Connection #0 to host proxy.mydomain.com left intact
env: https_proxy, external_scheme: https, inner_scheme: https
/t/curl-curl-7_53_1 ❯❯❯ https_proxy=https://proxy.mydomain.com:3127 ./src/curl -s -vvv https://google.com -o /dev/null
* Rebuilt URL to: https://google.com/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to proxy.mydomain.com (127.0.0.1) port 3127 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [86 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1027 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [262 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Proxy certificate:
* subject: C=IN; ST=SomeState; L=SomeLocation; O=Default Company Ltd; CN=proxy.mydomain.com; emailAddress=no-reply@gmail.com
* start date: Mar 16 06:43:35 2017 GMT
* expire date: Mar 16 06:43:35 2018 GMT
* common name: proxy.mydomain.com (matched)
* issuer: C=IN; ST=SomeState; L=SomeLocation; O=Default Company Ltd; CN=proxy.mydomain.com; emailAddress=no-reply@gmail.com
* SSL certificate verify ok.
* Establish HTTP proxy tunnel to google.com:443
} [5 bytes data]
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.53.1-DEV
> Proxy-Connection: Keep-Alive
>
{ [5 bytes data]
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
} [5 bytes data]
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3757 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [148 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.google.com
* start date: Mar 9 02:43:31 2017 GMT
* expire date: Jun 1 02:20:00 2017 GMT
* subjectAltName: host "google.com" matched cert's "google.com"
* issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
* SSL certificate verify ok.
} [5 bytes data]
> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/7.53.1-DEV
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Location: https://www.google.co.in/?gfe_rd=cr&ei=hDTKWJXlMubs8Aek-6WQAg
< Content-Length: 262
< Date: Thu, 16 Mar 2017 06:45:24 GMT
< Alt-Svc: quic=":443"; ma=2592000; v="36,35,34"
<
{ [262 bytes data]
* Connection #0 to host proxy.mydomain.com left intact
Как видно из результатов, в обоих случаях сначала происходит рукопожатие SSL с прокси-сервером.
Теперь я буду разглагольствовать немного.
Многие клиенты (например, curl = 7.51.0) не поддерживают соединение SSL / TLS с самим прокси и выдают ошибку такого рода:
$ https_proxy=https://proxy.mydomain.com:3128 curl -vvvv https://google.com
* Rebuilt URL to: https://google.com/
* Unsupported proxy scheme for 'https://proxy.mydomain.com:3128'
* Closing connection -1
curl: (7) Unsupported proxy scheme for 'https://proxy.mydomain.com:3128'
Кроме того, есть клиенты (например, curl=7.47.0), которые просто игнорировали бы неподдерживаемые схемы в URL-адресе прокси-сервера и могли бы ввести людей в заблуждение о том, что они сделали. Как правило, они никогда не будут подключаться к прокси-серверу по протоколу SSL/TLS, даже если переменная явно указывает схему как "https" и отступает от использования незашифрованного соединения с прокси-сервером.
Тогда есть другие клиенты (например, wget v1.18), которые еще больше запутали бы нас:
В следующем случае сообщение об ошибке вводит в заблуждение, поскольку схема может содержать значение https:// даже для HTTP-запроса к внешнему миру (как показано в примере выше с использованием squid), так как мы хотим, чтобы соединение с Прокси-сервер должен быть через SSL/TLS.
http_proxy=https://proxy.mydomain.com:3128 wget http://google.com Error in proxy URL https://proxy.mydomain.com:3128: Must be HTTP.
Не только это, но и растущая путаница, когда она отступает, заставляет нас думать, что она, вероятно, подключается к прокси-серверу по протоколу SSL/TLS, а на самом деле это не так, а также заставляет нас думать, что https:// в схеме должен работать только тогда, когда внутренний протокол также https://
https_proxy=https://proxy.mydomain-research.com:3128 wget https://google.com --2017-03-16 11:21:06-- https://google.com/ Resolving proxy.mydomain-research.com (proxy.mydomain-research.com)... 10.1.1.7 Connecting to proxy.mydomain-research.com (proxy.mydomain-research.com)|10.1.1.7|:3128... connected. Proxy request sent, awaiting response... 301 Moved Permanently Location: https://www.google.com/ [following] --2017-03-16 11:21:07-- https://www.google.com/ Connecting to proxy.mydomain-research.com (proxy.mydomain-research.com)|10.1.1.7|:3128... connected. Proxy request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘index.html’
Чтобы узнать больше об аспектах безопасности соединения (и не соединения) с прокси-сервером через TLS/SSL, посетите: /questions/22448607/snachala-izuchite-silverlight-ili-wpf/22448615#22448615