Вопросы Теги

Сохранение пароля SSL для SVN в Ubuntu

Эй все... это - я, Dan. Я - парень, который предъявил эту претензию, и я здесь для разговора больше об этом. Вот долгая, затянувшаяся версия того, что произошло.

Я управлял NOC для беспроводной компании фиксированных данных во Флориде в то время сплав (gofuzion.com - я мог записать книгу о том месте). У меня было несколько парней, работающих со мной, которые были относительно в новинку для сетевого мира. Heck, в то время, я тоже, только имея несколько лет кожи в игре.

Из-за пущенных в ход навыков уровня новичка у меня были парни, которые не могли поднять веб-сайт на их собственную рабочую станцию и будут волновать это, 'Интернет снизился'. Честно, это довольно вызывало жалость. Одна реакция коленного рефлекса, которую все имели, состояла в том, чтобы проверить с помощью ping-запросов yahoo.com. Это хорошо, но включает разрешение DNS, таким образом, это подвержено отказу. Они, конечно, не могли помнить IP-адрес к Yahoo, и Google не был (ни до какого реального градуса) в той точке, поэтому каков был простой IP-адрес, что все могли помнить, что это произойдет и работать надежно и последовательно? Помните, это много лет назад, когда устойчивость поставщика услуг была точкой продаж, не заключением, от которого воздерживаются.

Я, в то время, недавно соединил наш WUG (версия 3, я думаю, yay!) отображаются вместе и требуемый некоторые внешние хосты к проверке. Я хотел чистый IP-адрес, который было легко распознать также. Я putzed вокруг и проверенные с помощью ping-запросов простые адреса... 1.1.1.1, 2.2.2.2, и так далее. Я думал о разговоре, который я имел со своим боссом ранее в день (действительно одаренный человек по имени Robert Campbell), кто связал назад упругость PSTN. Это поразило меня... услуга телефонной связи имела 411 для получения информации. 4.1.1.1... просто еще одна цифра и бум идут динамит..., и это ПРОВЕРЯЕТ С ПОМОЩЬЮ PING-ЗАПРОСОВ!. Я поместил его в свою карту WUG и забыл о нем в течение недели или два.

Я возвращаюсь для рассмотрения моей карты, и этот хост никогда не понижался. Я был слишком ленив ранее для наблюдения, кому это принадлежало, но теперь мое любопытство было задето. Как глупый я чувствовал? Это был сервер DNS для GTE. Конечно, это было обязано произойти большую часть времени. Назад на этаже NOC, парни все еще были немыми (это, для некоторых, никогда изменяемых. Я уверен, что все здесь могут иметь отношение. У нас был термин для них вытянутый из Денверского офиса... "сиськи на быке". Но я отступаю.) Они волновались бы, когда у них или клиента будут проблемы возможности соединения..., и оттуда я сказал им, "Ping 4.1.1.1. Это будет всегда работать, если Ваше соединение с общим Интернетом будет работать. Это похоже 411 для Интернета". Я знаю, супердрянной. Но я узнал, что суперсыр работал в напряженных ситуациях, не только с начо.

Это работало. Парни прекратили пытаться проверить с помощью ping-запросов имена DNS или помнить их дом cable/dsl адрес, который, вероятно, изменится так или иначе. Они могли просто помнить этот простой адрес.

Однажды, я предполагаю, что они выключили ICMP - он прекратил работать. Парни в NOC не кричали, но у них определенно были свои трусики в скручивании. "4.2.2.2" был дан в разочаровании moi, который также по совпадению был вторичным устройством к 4.1.1.1 (я думаю, мог быть неправым), и отвечал на ICMP. Это придерживалось. Это распространилось. Это - то, как это иногда идет.

По телефону я слышал, что эти парни говорили клиентам проверять с помощью ping-запросов 4.2.2.2 для тестирования возможности соединения. Я слышал их по телефону с поставщиками, тестирующими с адресом. Что заставило меня улыбнуться однажды, пара несколько лет спустя была безумной линией фронта технология телефона DSL, обойдя меня через мое домашнее отключение электричества возможности соединения. "Проверьте с помощью ping-запросов 4.2.2.2", она язвительно заметила. Я чувствовал себя немного теплым внутри? Вы betcha.

Так вот именно. Я изобретал его? Для меня в моем небольшом мире, да. Кто-то еще уже мог иметь (или несколько одновременно) сделанный это, как радио или полет или какая-либо другая на самом деле важная вещь, которая оказывает некоторое фактическое влияние в наших жизнях? Я надеюсь, что это положило конец слухам. (повторно отправленный на mywebsite)

0
задан 1 April 2014 в 15:19
2 ответа

Please make changes as below and check.

In ~/.subversion/config file :- (Changed as)

### Section for authentication and authorization customizations.
[auth]
### Set password stores used by Subversion. They should be
### delimited by spaces or commas. The order of values determines
### the order in which password stores are used.
### Valid password stores:
### gnome-keyring (Unix-like systems)
### kwallet (Unix-like systems)
### gpg-agent (Unix-like systems)
### keychain (Mac OS X)
### windows-cryptoapi (Windows)
password-stores = gpg-agent,gnome-keyring,kwallet
### To disable all password stores, use an empty list:
password-stores = yes
###
### Set ssl-client-cert-file-prompt to 'yes' to cause the client
### to prompt for a path to a client cert file when the server
### requests a client cert but no client cert file is found in the
### expected place (see the 'ssl-client-cert-file' option in the
### 'servers' configuration file). Defaults to 'no'.
ssl-client-cert-file-prompt = yes
###
### The rest of the [auth] section in this file has been deprecated.
### Both 'store-passwords' and 'store-auth-creds' can now be
### specified in the 'servers' file in your config directory
### and are documented there. Anything specified in this section
### is overridden by settings specified in the 'servers' file.
store-passwords = yes
store-auth-creds = yes

### Section for configuring external helper applications.

In ~/.subversion/servers file :- (Changed as)

[global]
# http-proxy-exceptions = *.exception.com, www.internal-site.org
# http-proxy-host = defaultproxy.whatever.com
# http-proxy-port = 7000
# http-proxy-username = defaultusername
# http-proxy-password = defaultpassword
# http-compression = no
# No http-timeout, so just use the builtin default.
# No neon-debug-mask, so neon debugging is disabled.
# ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem
#
# Password / passphrase caching parameters:
store-passwords = yes
store-ssl-client-cert-pp = yes
# store-plaintext-passwords = no
# store-ssl-client-cert-pp-plaintext = no
-1
ответ дан 4 December 2019 в 14:01

Похоже, в Subversion 1.8+ произошла ошибка/регрессия, в которой не хранится парольная фраза сертификата. Я отвечаю здесь в надежде, что кто-нибудь найдет это полезным и сэкономит время.

Одним из решений является использование кошелька в качестве хранилища паролей. Есть очень хороший способ: http://mail-archives.apache.org/mod_mbox/subversion-users/201406.mbox/%3C5391B93F.1030101@ntlworld.com%3E. Повторяя здесь все шаги, все приписывается оригинальному автору - Саймону.

Учитывая то, что вы мне сказали, я смог найти обходной путь и руководство. создать хранилище паролей:

  1. .subversion/config: [auth] раздел установлен на "password-stores = kwallet"
  2. Запустите "kwalletmanager", откройте кошелек через "system tray"
  3. Откройте кошелек по умолчанию и создайте новую папку верхнего уровня "Subversion". (наряду с данными формы, паролями)
  4. Выберите "Пароли" в папке Subversion и создайте новую с помощью ключ "@" + путь_к_p12, например "@/home/nc/nc.p12"
  5. Введите пароль в кошелек для этого ключа

Смотрите, где svn пытается получить данные от "strace -e". trace=lstat svn ls http://...." e.g. reveals /home/nc/.subversion/auth/svn.ssl.client-passphrase/345983d745d98273c095e872a09"

Заполните этот файл "345983d745d98273c095e872a09", например:

K 15. svn:realmstring V 45 /дома/nc/nc.p12 КОНЕЦ Это может кому-нибудь помочь. Обратите внимание, что мое имя пользователя полученных из общего имени сертификата, в противном случае, я думаю, что вам необходимо "Username@" в качестве ключа пароля.

Вдохновившись вышеприведенным решением, мне удалось заставить его работать с gnome-keyring. Большая часть шагов одинакова:

содержимое .subversion/servers:

store-auth-creds = yes 
ssl-client-cert-file = /mnt/data/myuser/certificate.pk12
ssl-authority-files = /some/path/to/CA_if_needed.pem
store-passwords = yes 
store-plaintext-passwords = no
store-ssl-client-cert-pp = yes 
store-ssl-client-cert-pp-plaintext = no

Найти, какой файл svn пытается прочитать. Запустите strace на какой-нибудь команде svn, например strace svn up и вы должны увидеть что-то вроде "/home/user/.subversion/auth/svn.ssl.client-passphrase/b97ec2acbc64a5c8634a2307cd100b13". Создайте этот файл с этим содержимым: K 15 svn:realmstring V 33 /mnt/data/myuser/certificate.pk12 КОНЕЦ Путь в вашем случае может быть другим. Также не забудьте заменить V 33 на длину строки пути.

Теперь хитрая часть - ручное сохранение ключевой фразы в gnome-keyring. Так как Seahorse был не в состоянии создать для меня сетевой пароль, я использовал крошечный питоновый скрипт. Пользователям Debian/Ubuntu для этого нужен пакет "python-gnomekeyring"

#!/usr/bin/env python
import pygtk
pygtk.require('2.0')
import gtk
import gnomekeyring

def hack():
    gnomekeyring.item_create_sync(None, gnomekeyring.ITEM_NETWORK_PASSWORD, "svn cert pwd", {"domain" : "/mnt/data/myuser/certificate.pk12"}, "Secret_Passphrase_Goes_Here", True)

if __name__ == '__main__':
    hack()

Он создаст сетевой пароль в связке ключей по умолчанию. "domain" должен совпадать с путём к сертификату в только что созданном svn config.

Вы можете использовать seahorse, чтобы проверить, всё ли прошло успешно. Теперь Subversion должна уметь читать из gnome-keyring, и вам больше не нужно будет каждый раз вводить пароль!

.
3
ответ дан 4 December 2019 в 14:01

Теги

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