Несколько закрытых ключей SSH, возможных?

$HOME в управлении версиями

  • Периодически фиксируйте все в / корневом каталоге в репозитории управления версиями. (Кроме всегда "делают суперчистыми" прежде, чем фиксировать каталог $HOME программиста, таким образом, он никогда не фиксирует двоичные исполняемые файлы или другие easily-machine-generated файлы).
  • Для каждого пользователя, который "владеет" уникальными данными по моему рабочему компьютеру, удостоверьтесь, что существует своего рода репозиторий управления версиями на моем файловом сервере, который содержит весь каталог $HOME того пользователя (" $HOME в подверсии"). Даже при том, что я - практически единственный человек, который касается этой клавиатуры, у меня есть отдельный пользователь для: недоверяемый веб-браузер, кому нравится устанавливать много потенциально зараженных вредоносным программным обеспечением игр; программист C, который часто пишет программное обеспечение с ужасающими ошибками и таким образом, мы хотим сохранить его изолированным в sandpile, где он не может случайно удалить мои любимые веб-закладки; пользователь робота, который выполняет Wiki; пользователь root; и т.д.
  • сохраните все "мои" файлы в моем каталоге $HOME, который является управлением версиями рабочий каталог.
    • текстовые файлы, фотографии, файл закладки веб-браузера, и т.д. - все в корневом каталоге.
    • если я пишу сценарий пакетной обработки, который "должен" войти в некоторый другой подкаталог, сохранить основную копию где-нибудь в моем каталоге $HOME и сделать гибкую ссылку от того другого подкаталога до основной копии.
    • Если я пишу скомпилированное программное обеспечение, которое "должно" войти в некоторый другой подкаталог, сохранить основной исходный код и Make-файл в некотором подкаталоге моего каталога $HOME, и настроить Make-файл, таким образом, "делают установку", автоволшебно устанавливает двоичный исполняемый файл в том другом каталоге.
    • Если я исправляю ошибки в некотором программном обеспечении, передаю исправления ошибок в восходящем направлении.
    • сохраните список в некотором текстовом файле в моем каталоге $HOME "приложений, которые я люблю, и не был установлен по умолчанию" и "приложения, которые обычно устанавливаются по умолчанию, но мне не нравится". Посмотрите, Как Вы отслеживаете, какие пакеты были установлены на Ubuntu (Linux)? или Как Вы отслеживаете, какие пакеты были установлены на Fedora (Linux)?
  • если я покупаю программное обеспечение на CD или DVD, создаю резервную копию ISO-образа на моем файловом сервере и установки из того изображения на мой рабочий компьютер. (Поскольку мой рабочий компьютер не имеет оптического диска).

Позже, когда машина A потеряна,

  • установка последняя версия любого дистрибутива является моим фаворитом на этой неделе, включая все программное обеспечение по умолчанию, на машине C.
  • Для каждого пользователя сделайте контроль управления версиями последней версии (ГОЛОВА), кроме так или иначе(?) перескакивания через все двоичные исполняемые файлы. Это блокирует некоторые виды вирусов и троянцев от распространения до C.
  • установите другой материал вне моего корневого каталога:
    • проверьте мой список приложений, удалите материал, который я не хочу.
    • проверьте мой список приложений, установите последнюю версию материала, который я хочу. Надо надеяться, последняя версия включает исправления ошибок, которые я пасовал назад. (См. ссылки выше для способов автоматизировать этот процесс),
    • действительно "сделайте суперчистыми", и "делают установку" с каждой из скомпилированных программ, которые я записал.
    • так или иначе(?) помните, куда сценарии пакетной обработки "должны" пойти, и создавать гибкую ссылку от того местоположения до основного источника в моем/home/каталоге. (Есть ли способ автоматизировать это?)
    • так или иначе(?) помните весь материал, я имею выполнение как крон и anacron задания, и ввожу их, въезжают задним ходом снова.
    • программное обеспечение установки, которое было куплено на CD у ISO-образа на файловом сервере.
  • ... есть ли что-либо еще, что я пропускаю?

11
03.03.2012, 00:47
2 ответа

Вы можете иметь различные закрытые ключи в различных файлах и указать всех их в ~/.ssh/config отдельное использование IdentityFile значения (или использование -i опция при выполнении ssh). Их судили бы в последовательности (контроль man 5 ssh_config).

Если Вы используете ssh-agent хотя, Вам, возможно, придется сказать агенту о нескольких ключах, что у Вас есть использование ssh-add.

16
27.01.2020, 19:57
  • 1
    Обратите внимание что, если одна учетная запись имеет несколько допустимых ключей (например, потому что Вы используете authorized_keys выполнять определенные команды вместо оболочки), Вам, вероятно, придется использовать IdentitiesOnly yes опция удостовериться ssh-agent не использует неправильный. См. также unix.stackexchange.com/q/52092/863 –  Tobias Kienzler 18.10.2012, 09:13

Да:

-i identity_file

Выбирает файл, из которого читаются идентификационные данные (закрытый ключ) для аутентификации с открытым ключом. Значение по умолчанию ~/.ssh/identity для версии протокола 1, и ~/.ssh/id_dsa, ~/.ssh/id_ecdsa и ~/.ssh/id_rsa для версии протокола 2. Файлы идентификационных данных могут также быть указаны на основе на хост в конфигурационном файле. Возможно иметь несколько -i опции (и несколько идентификационных данных, указанных в конфигурационных файлах). ssh также попытается загрузить информацию о сертификате из имени файла, полученного путем добавления -cert.pub к именам файлов идентификационных данных.

Просто добавьте -i для каждых идентификационных данных или использования несколько IdentityFile строки в Вас .ssh/config.

10
27.01.2020, 19:57

Теги

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