Який найкращий спосіб зберігати зашифрований пароль svn на Ubuntu Server?


8

Привіт,

У мене на сервері Ubuntu працює сервер підривної роботи. Я запускаю клієнта на одній машині через SSH, і я хотів би, щоб клієнт svn пам’ятав мій пароль, але не зберігав його як відкритий текст. Дивлячись тут, я бачу два методи: gnome-keyring та kwallet. Оскільки я не використовую настільний менеджер, я трохи насторожено намагаюся використовувати один із них. Будь-які пропозиції? Було б нормально (чи навіть працювати) використовувати одне з двох згаданих мною додатків?

ТІА

Відповіді:


9
  1. Ви можете запустити Gnome-keyring або Kwallet на віддаленій машині. Кожен постачається у двох компонентах, демон і графічний інтерфейс.

    • Ви можете запустити додаток GUI на віддаленій машині, якщо ви запускаєте ssh з переадресацією X. Тільки тому, що це "серверна" машина не означає, що ви не можете встановити на неї програми GUI. Незалежно від того, використовуєте ви відповідне середовище робочого столу чи ні, програмам не потрібно певного середовища для роботи на робочому столі.

    • Ви можете керувати Kwallet в командному рядку через qdbus, хоча це не дуже добре в цьому конкретному випадку, оскільки вам доведеться писати свій пароль у чіткому тексті в командному рядку, і це можуть бути відхилені іншими користувачами. Дивіться також цю відповідь SU .

    • Існує зв'язок пітона як для Gnome-keyring, так і для Kwallet (пакунки python-keyring-gnomeта python-keyring-kwallet); ви можете написати крихітний сценарій пітона для управління ними. Насправді є вже один для Gnome-keyring: gkeyring .

    • Якщо ваш пароль libpam-keyringвведення ключа такий, як ваш пароль для входу, ви можете встановити його, і ваш брелок буде розблокований автоматично при вході в систему. Однак для цього потрібен вхід із паролем, а не паролем ключів.

  2. Якщо ви локально використовуєте Gnome-keyring або Kwallet, ви можете переслати їх через ssh, доклавши трохи роботи. Вони використовують розетки Unix, які ssh не може переслати. Але ви можете використовувати socatретрансляційні розетки Unix для сокетів TCP локально і навпаки на віддаленій машині:

    while true; do socat TCP-LISTEN:22007 UNIX-CONNECT:"$GNOME_KEYRING_SOCKET"; done &
    ssh -R22007:localhost:22007 remote.example.com
    export GNOME_KEYRING_SOCKET="$HOME/.gnome-keyring-socket"
    while true; do socat UNIX-LISTEN:"$GNOME_KEYRING_SOCKET" TCP4:localhost:22007; done &
    

    Це може бути автоматизовано за допомогою невеликих скриптів оболонок з кожної сторони та RemoteForwardрядка в ~/.ssh/config. Теоретично вам слід мати доступ до віддаленої машини gnome keyring. Однак я намагався отримати доступ до нього з морським конем, і він навіть не намагався підключитися до нього $GNOME_KEYRING_SOCKET; Я не знаю, чому, і не знаю, чи змогли б svn отримати доступ до брелоку.

  3. Ви можете зберігати свій svn пароль у зашифрованій файловій системі. Є кілька варіантів ; Я думаю, що найпростіший спосіб піти - це encfs. Початкові налаштування:

    sudo aptitude install encfs
    encfs ~/.passwords.encrypted ~/.passwords
    mv ~/.subversion/auth ~/.passwords/svn-auth
    ln -s ../.passwords/svn-auth ~/.subversion/auth
    

    Нормальний робочий процес:

    encfs ~/.passwords.encrypted ~/.passwords
    ... work ...
    fusermount -u ~/.passwords
    

    Цей спосіб має перевагу з кількох причин:

    • І початкова установка, і нормальний робочий процес дуже прості.
    • Не має значення, звідки ви входите, зокрема вам не потрібно мати локальний X-сервер і використовувати переадресацію X через ssh.
    • Зашифрована файлова система є більш універсальною, ніж брелока (хоча вона менш зручна для використання брелоків, але у випадку svn це не має значення).
    • Єдиний не всюдисущий інструмент, який вам потрібен, - це encfs (для якого потрібен FUSE), і він упакований для Ubuntu.

Спасибі більше, ніж я міг сподіватися на відповідь! Я спробую 3-й підхід і звіту.
Енді

Дуже повна відповідь.
this.josh

Чи можливо змусити знизити підрив, якщо ~ / .subversion / auth порожній / не існує? В іншому випадку 3-й підхід є трохи небезпечним, якщо ви забудете спочатку запустити encfs.
unhammer

@unhammer При такому підході, якщо файлова система encfs не змонтована, то ~/.subversion/authце звисаюче символічне посилання. У такому випадку субверсія повідомляє вам, що він буде зберігати ваш пароль (якщо ви не вимкнули це повідомлення), але насправді не зберігає його ніде (перевірено svn 1.6.6). Тож немає ризику при третьому підході.
Жил "ТАК - перестань бути злим"

ага, я спершу спробував без символьного посилання, але тепер я бачу симпосилання на папку в зашифрованій папці, і це працює, дякую, що
очистили

0

gpg зашифруйте файл із паролем у, - але тоді для цього вам знадобиться парольна фраза (і не втрачайте приватний ключ!).

Я думаю, ви можете перевірити svn приватний ключ, а також вам все одно потрібна парольна фраза, щоб використовувати його, але вся ця настройка здається трохи дивною.

навіщо вам це потрібно?


Я шукаю не спосіб загального призначення для шифрування, а спосіб, який підключається до SVN. Коли я використовував SVN на Ubuntu dekstop, проблеми не виникло, тому я припускаю, що він використовує gnome-keyring. Я знову припускаю, що gnome-keyring не встановлений на сервері Ubuntu, і тому в цьому проблема. Наразі я можу перевірити речі, але отримую попередження, що зберігати пароль можна лише в незашифрованому вигляді. Дивіться посилання, яке я дав для більш детальної інформації. Дякую.
Енді

Я пояснив пояснення вище, чт.
Енді

Я люблю , щоб використовувати ~ / .authinfo.gpg зі стандартним форматом Netrc для SVN, і маю GPG обробляти шифрування, але , до жаль , це те , що здається , що це було б вимагати трохи більше налаштувань , ніж рішення EncFS. Схоже, svn дозволяє довільно зберігати паролі.
unhammer
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.