Вопросы Теги

вопросы о ключе ssh

У меня было то же всплывающее окно кода ошибки только на одной станции, я заметил в сети, что это, вероятно, имеет некоторое отношение к .oab файлам, таким образом, я стер все .oab файлы из папки "C:\Documents and Settings\USER ACCOUNT\Local Settings\Application Data\Microsoft\Outlook" и сделал новый send\recieve, который восстановил их, и теперь все хорошо.

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

Всегда, теперь ошибки не стало.Надеюсь, это поможет.

2
задан 26 February 2010 в 03:14
3 ответа

  1. Да, дело обстоит так. Машина с частной половиной ключа может пройти проверку подлинности против тех, которые имеют общедоступную половину. У Вас мог, конечно, быть тот же закрытый ключ на двух или больше машинах, но если у Вас нет строкового пароля на ключе, Вы не должны делать этого для серверов, Вы не делаете 100%-го доверия, такого как внешний общий сервер (с другой стороны, ключи без пароля не рекомендуются так или иначе).

  2. Распространено использовать тот же открытый ключ на многих серверах, точно так же, как при использовании public+private ключей для подписания электронной почты (все обычно используют тот же открытый ключ для проверки подписей от одного закрытого ключа) - не выше о не withstading. Например, мой ключ для me@homemachine может зарегистрировать меня в мой домашний сервер, мой удаленный сервер и несколько VMs. У меня есть differet pait ключей для me@homeserver, хотя (из-за примечания 1 выше), но это может также использоваться для аутентификации меня с выбором учетных записей в другом месте. Тем не менее нет ничего для остановки Вас имеющий много закрытых ключей для каждой учетной записи пользователя, которую Вы держите, если Вы требуете.

  3. Все авторизованные ключи для сделанного целевого отчета существуют в одном authorized_keys файле.

  4. Это зависит. Ваш корневой каталог, или действительно все, на общем (NFS) ресурс?

http://novosial.org/openssh/publickey-auth/ является ресурсом, который подошел после быстрого поиска при ответе на связанный вопрос ранее, и это кажется релевантным здесь также, хотя он не мог бы ответить последний вопрос. Демонстрационные команды будут относиться к Linux, принимающему Вас, используют OpenSSH (который Вы не, скорее всего).

3
ответ дан 3 December 2019 в 09:00
  • 1
    Спасибо David! О вопросе 3, как поместить все в файл aurthorized-ключей, например? Я также видел, что иногда люди используют несколько файлов aurthorized-ключей: aurthorized-ключи, aurthorized-keys2, aurthorized-keys3 и так далее.В чем дело? –  Tim 26 February 2010 в 04:39
  • 2
    О вопросе 4, это - просто мой корневой каталог. Таким образом, я могу просто скопировать сгенерированный файл с открытым ключом в файл aurthorized-ключей в соответствии с тем же каталогом ~/.ssh? Это будет работать на какой-либо сервер, получающий доступ к другим серверам, которые совместно используют ту же файловую систему? –  Tim 26 February 2010 в 04:42
  • 3
    authorized_keys2 удерживался от использования в течение некоторого времени - просто используют авторизованные ключи. Можно добавить ключ к файлу с > > оператор перенаправления в ударе. Я обычно передаю ключи от исходной машины сразу с cat ~/.ssh/id_rsa.pub | ssh remoteuser@remote.host.com "cat - `mkdir -p ~/.ssh` >> ~/.ssh/authorized_keys" - который работает, если это - первый ключ или еще один. –  David Spillett 26 February 2010 в 12:52
  • 4
    И да, поскольку машины совместно используют тот же /home, Ваша учетная запись будет иметь те же ключи по умолчанию (можно использовать несколько и указать, чтобы использовать на команде), таким образом, однократный въезд в authorized_keys позволит Вам ssh между ними использующий основанного на ключах автора. –  David Spillett 26 February 2010 в 12:53
  • 5
    Закрытые ключи почти всегда хранятся на диске наряду с их общедоступными частями. (По крайней мере, который имеет место с GnuPG и SSH/SSL.), Если Вы имеете всего id_rsa, это содержит обе части, таким образом, аргумент в № 1 является неправильным. –  grawity 26 February 2010 в 15:18

(1) Предполагаемый существует два компьютера, работающие ssh серверная служба, и я генерировал пару файлов ключей на компьютере A и копирую общедоступный файл в компьютер B. Это верный, что это - только односторонний ключ: Мы только дали компьютеру разрешение получить доступ к компьютеру B, не дал компьютер B разрешение получить доступ к компьютеру A?

Да.

Если я теперь хочу к ssh от компьютера B к компьютеру A, я должен генерировать другую пару файлов ключей на компьютере B и скопировать общедоступный файл в компьютер A?

Да (хотя Вы могли использовать те же файлы ключей как выше, если A и B полностью доверительный друг друга).

(2) Если я хотел бы подключить единственный локальный компьютер к нескольким удаленным серверам, он должен генерировать общую пару файлов ключей только однажды на локальном и скопировать тот же общедоступный файл в удаленные серверы, или генерировать другую пару файлов ключей на локальном для различных удаленных серверов?

В то время как оба будут работать, нет никакой причины использовать больше чем один файл ключей; так Ваша вторая опция.

(3)

Да, Вы комбинируете все ключи в один authorized_keys файл.

(4) Если существует несколько серверов, совместно использовал ту же файловую систему, например, NFS, как генерировать ключи и расположить файлы ключей для доступа от одного сервера до другого? Также, как все еще генерировать ключи и расположить файлы ключей для локального компьютера для доступа к кому-либо из серверов?

NFS не имеет значения для SSH; файлы должны просто быть в правильных местоположениях. То же для генерации ключей.

3
ответ дан 3 December 2019 в 09:00
  1. Одна пара ключей сгенерирована от Компьютера 'A'может использоваться для входа в систему в несколько других Компьютеров.
    Однако можно скопировать пару ключей с A '.ssh' каталог к другому компьютеру 'B' и затем используйте его оттуда также (для входа в систему во все компьютеры, от которых Вы предоставили доступ'A' с этими учетными данными).
    Это делает доступ менее безопасным, так как Вы теперь совместно использовали частные данные через два компьютера. Но, это может работать, если это не ответственность.
  2. Как я описал выше, единственная пара ключей на 'A' может привыкнуть к доступу как много удаленных машин, поскольку Вам нужно путем авторизации доступа с открытым ключом на каждом из них.
  3. 'authorized_keys' файл может иметь несколько строк авторизации (открытые ключи), один на строку.
  4. Когда Вы совместно использовали 'home' пространство через несколько компьютеров (и '.ssh' сам каталог поэтому совместно используется через них, поскольку Вы входите в систему), Вам нужна всего одна пара ключей для совместного использования доступа через этот пул компьютеров. Поместите открытый ключ в authorized_keys файл этого '.ssh'.

Некоторые ссылки,

  1. Аутентификация открытого ключа OpenSSH
  2. SSH без пароля
  3. Идентификационные данные пользователя SSH (SecurityFocus)

Обновление:

  • Эта страница справки Кембриджского университета имеет образец authorized_keys список.
  • Я думаю, что различные файлы использовались для хранения различных ключевых типов.
    Как 'authorized_keys'файл был бы для ключей RSA и
    'authorized_keys2'файл для ключей DSA, возможно.
    Существует статья SecurityFocus, которая описывает эти файлы наряду с другими вещами.
2
ответ дан 3 December 2019 в 09:00
  • 1
    Спасибо nik! О вопросе 3, можно ли дать пример помещения всех в файл aurthorized-ключей? Я также видел, что иногда люди используют несколько файлов aurthorized-ключей: aurthorized-ключи, aurthorized-keys2, aurthorized-keys3 и так далее.В чем дело? –  Tim 26 February 2010 в 04:38
  • 2
    Дополнительные авторизованные файлы ключей обычно для вариаций на протокол. Я рекомендовал бы Вам don' t используют их, просто придерживаются очень простой установки, пока Вы не более довольны SSH. –  Chris S 26 February 2010 в 05:05

Теги

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