SVN через HTTPS и SSL рукопожатие терпит неудачу

23853
themaestro

Я пытаюсь оформить заказ с svn-сервера моей команды. Требуется проверка подлинности на стороне клиента. Я использую Ubuntu 10.04.

Вот что я получаю:

$ svn checkout https://myproject.myserver.org/svn/project/ svn: OPTIONS of 'https://myproject.myserver.org/svn/project/': Could not read status line: SSL alert received: Handshake failed (https://myproject.myserver.org)

Кто-нибудь еще видел подобную проблему?

4
Я считаю, что вы должны предоставить SVN соответствующий аргумент для сертификата клиента. Не могу найти информацию об этом ... usr-local-ΕΨΗΕΛΩΝ 13 лет назад 0
Может быть, это помогает: http://sgi.posterous.com/sslv3-alert-handshake-failure-with-svn-client marcog 13 лет назад 0
не повезло с ссылкой, уже настроена так :( 13 лет назад 0
У меня такая же проблема. Оказалось, я не добавил ServerName в определение виртуального хоста в Apache. После того, как я добавил ServerName myproject.myserver.org для конфигурации vhost subversion, проблема была решена. kokeksibir 11 лет назад 0
Постера больше нет. Возможно, эта ссылка была заархивирована на машине окупаемости: http://web.archive.org Mike Crawford 6 лет назад 0

3 ответа на вопрос

3
SilverbackNet

Это все еще не работает? Время разбить большие пушки. Во-первых, попробуйте перейти к нему с того же сервера, посмотреть, получите ли вы ожидаемый список папок. Если это не удастся, у вас может быть более веская причина, а если нет, запустите OpenSSL:

openssl s_client -connect myproject.myserver.org:443

даст вам журнал информации о каждом шаге рукопожатия, а опция --debug покажет еще больше деталей. Он будет жаловаться на недействительный сертификат, плохое время или только устаревшие алгоритмы.

Конечно, убедитесь, что вы даже можете пропинговать его и что https по какой-то причине не отключен.

Только один дефис в опции -connect. Mojo 13 лет назад 4
2
Flávio Botelho

Возможно, проблема в том, что вы используете новую версию клиента Collabnet, как в http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=364471 ?

0
Martin Zeitler

Check the user's path spec PATH environment variable in ~/.bashrc (for that user).

If this one is messed up, quite some commands cannot be called by their common name.

Most likely, it just cannot find one binary executable - or the private key in ~/.ssh

... for a quick check (logged in as the user, which is not working):

echo $PATH

Похожие вопросы