Быстрая регистрация в системе с помощью ключей SSH-клиента

Используйте SSH-ключи вместо парольной идентификации для ускорения автоматической регистрации в системе. Если вы являетесь администратором нескольких машин, возможность быстрого перехода к другому ядру на любом сервере является очень важной. Необходимость ввода ssh my. server. сот (после чего вводится пароль) не только утомительна, но и мешает сконцентрироваться. Необходимость внезапно переключаться с во- проса «В чем проблема?» на «Как войти?», а затем на «Что же дальше?» вызвала преждевременное старение уже не одного администратора. Это является цифровым эквивалентом маразматической фразы: «А зачем я пришел в эту комнату?» Во всяком случае, чем больше усилий затрачивается на регистрацию в системе, тем меньше сил останется на решение проблемы.

На заметку: Если Вас интересует полиграфия и широкоформатная печать в Москве, тогда рекомендуем посетить сайт http://www.abatprestige.ru/.

Последние версии SSH предлагают безопасную альтернативу многократному вводу пароля: обмен открытым ключом. В рассматриваемых далее примерах предполагается использование OpenSSHv3.4pl или более свежих версий. Для применения открытого ключа с SSH-сервером сначала необходимо сгенерировать пару ключей, открытый и закрытый (секретный): $ ssh-keygen -t rsa Для создания DSA-ключей можно воспользоваться ключом -t dsa либо -t rsal, если вы используете RSA Protocol vl. (Как вам не стыдно использовать первую версию! При первой же возможности переходите на вторую!) Желательно использовать RSA-ключи, поскольку с DSA-ключами бывают проблемы, хотя они используются очень редко.

Если это не работает, проверьте разрешения файла для ~/.ssh/* и sewer.-/.ssh/\ Секретный ключ (id_rsa) должен быть в режиме 0600 (и находиться только на локальной машине), а все остальное должно быть в режиме 0655 или лучше. Кроме того, требуется, чтобы домашний каталог на сервере был в режиме 755 или лучше. Если группа имеет разрешение writable, любой член группы, владеющей домашним каталогом, может удалить ~/.ssh, даже если группа не имеет разрешения writable в отношении ~/.ssh. На первый взгляд это незаметно, но если они смогут сделать это, то смогут создать собственный ~/.ssh и файл authorlzed_keys2, который может содержать любые ключи. К счастью, SSH-демон перехватит этот запрос и откажет в идентификации по открытому ключу, пока разрешения не будут исправлены.

источник: Локхарт Э. Антихакинг в сети. Трюки.


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *