Подключение по ssh linux без пароля

Обновлено: 03.07.2024

Небольшой мануал как сделать доступ к серверу по ssh по ключам
если ssh не установлен то выполняем следующую команду на сервере:

sudo apt-get install openssh-server

Ssh установлен и запущен на 22-м порту и мы можем подключиться к нему по обычной схеме логин/пароль. Но у нас задача сделать доступ по ключам. Рассмотрим оба случая.

Если подключаемся к ssh с помошью другой linux системы

Сначала на пользовательском компьютере создадим ключи. Для этого выполним

ssh-keygen -t rsa

Он спросит куда их сохранять. соглашаемся на предложенный путь(по умолчанию

/.ssh)
потом он спросит пароль. т.к. он нам не нужен просто нажимает два раза enter.
Теперь заходим на сервер и создаем папку .ssh в директории нужного пользователя,
а в этой папке создаем файл

и добавляем в него строчку из нашего созданного файла ключей:

Если подключаемся к ssh с помощью windows и putty

Для начала идем по адресу

и качаем putty.exe и puttygen.exe
Теперь запускам putty.exe и переходим в категорию Session.
В поле host name пишем IP нашего сервера, а в поле Saved Sessions пишем название профиля.
Затем идем в категорию Connection -> Data и указываем в Auto-login username имя пользователя, под которым будем подключаться к SSH серверу.

Снова идем в категорию Session и нажимаем кнопку save.

Теперь нам надо сделать ключи.
Для этого мы запустим

puttygen.exe

и там выберем SSH-2 RSA в Type of key to generate: и введем 4096 в Number of bits in a generated key.

Кликнем на Generate.
Нас попросят подвигать мышкой и выдадут нам ключ.

После того как нам выдали ключ, мы его должны сохранить. Для этого сначала нажимаем Save public key и сохраняем открытый ключь, а потом нажимаем Save private key и сохраняем закрытый ключ.
Затем скопируем открытый ключ из окна PuTTYgen и, подключившись к нашему серверу по ssh скопируем его в файл

/.ssh/authorized_keys (если ключ уже не первый, то просто добавим его второй или n-ной строчкой)

Сохраняем файл и закрываем соединение с серрвером.

Теперь нам надо добавить новый ключ в putty. Для этого заново откроем putty.exe и, перейдя в категорию Session выделим наш профиль, созданный в начале, и нажмем Load.
Затем перейдем в категорию SSH, далее Auth и кликнем Browse. Теперь найдем ранее сохраненный закрытый ключ.
И снова перейдем в категорию Session и кликнем на Save.

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Теперь можно подключаться без пароля.

Заказать создание и поддержку безопасной IT-инфраструктуры любой сложности

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

Настройка SSH входа без пароля

Чтобы настроить SSH-вход без пароля в Linux, все, что вам нужно сделать, это сгенерировать открытый ключ аутентификации и добавить его в файл

/.ssh/authorized_keys удаленных хостов.

Следующие шаги описывают процесс настройки входа по SSH без пароля:

Проверьте существующую пару ключей SSH.

Перед созданием новой пары ключей SSH сначала проверьте, есть ли у вас уже ключ SSH на вашем клиентском компьютере, потому что вы не хотите перезаписывать существующие ключи.

Выполните следующую команду ls, чтобы проверить наличие существующих ключей SSH:

Если есть существующие ключи, вы можете использовать их и пропустить следующий шаг или создать резервную копию старых ключей и сгенерировать новый.

Если вы видите No such file or directory или no matches found это означает, что у вас нет ключа SSH, и вы можете перейти к следующему шагу и сгенерировать новый.

Создайте новую пару ключей SSH.

Следующая команда сгенерирует новую пару ключей SSH 4096 бит с вашим адресом электронной почты в качестве комментария:

Нажмите Enter чтобы принять расположение и имя файла по умолчанию:

Затем инструмент ssh-keygen попросит вас ввести безопасную парольную фразу. Независимо от того, хотите ли вы использовать кодовую фразу, решать вам, если вы решите использовать кодовую фразу, вы получите дополнительный уровень безопасности. В большинстве случаев разработчики и системные администраторы используют SSH без парольной фразы, поскольку они полезны для полностью автоматизированных процессов. Если вы не хотите использовать кодовую фразу, просто нажмите Enter .

В целом взаимодействие выглядит так:

Чтобы убедиться, что ключи SSH сгенерированы, вы можете указать свои новые закрытые и открытые ключи с помощью:

Скопируйте открытый ключ

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

Вам будет предложено ввести пароль remote_username :

После аутентификации пользователя открытый ключ будет добавлен в файл authorized_keys удаленного пользователя, и соединение будет закрыто.

Если по какой-либо причине ssh-copy-id недоступна на вашем локальном компьютере, вы можете использовать следующую команду для копирования открытого ключа:

Войдите на свой сервер с помощью ключей SSH

После выполнения описанных выше действий вы сможете войти на удаленный сервер без запроса пароля.

Чтобы проверить это, просто попробуйте войти на свой сервер через SSH:

Если все прошло успешно, вы сразу же войдете в систему.

Отключение аутентификации по паролю SSH

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

Перед отключением парольной аутентификации SSH убедитесь, что вы можете войти на свой сервер без пароля, а пользователь, с которым вы входите, имеет права sudo.

В следующих руководствах описывается, как настроить доступ sudo:

Войдите на удаленный сервер с помощью ключей SSH, либо как пользователь с привилегиями sudo, либо как пользователь root:

Откройте файл конфигурации SSH /etc/ssh/sshd_config , найдите следующие директивы и измените их следующим образом:

Как только вы закончите, сохраните файл и перезапустите службу SSH.

На серверах Ubuntu или Debian выполните следующую команду:

На серверах CentOS или Fedora выполните следующую команду:

Выводы

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

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

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

SSH или Secure Shell - это зашифрованный протокол, который часто используется для взаимодействия и удаленного управления серверами. Если вы захотите что-либо сделать на удаленном сервере, скорее всего, вам придется воспользоваться SSH и работать через терминал.

В SSH существует несколько способов авторизации. Вы можете каждый раз вводить пароль пользователя или использовать более безопасный и надежный способ - ключи SSH. Что самое интересное, он более удобен для применения, вам даже не нужно будет вводить пароль. В этой статье мы рассмотрим как настраивается авторизация по ключу SSH.

Как работают ключи SSH?

SSH сервер может выполнять аутентификацию пользователей с помощью различных алгоритмов. Самый популярный - это аутентификация по паролю. Он достаточно прост, но не очень безопасный. Пароли передаются по безопасному каналу, но они недостаточно сложны для противостояния попыткам перебора. Вычислительная мощность современных систем в сочетании со специальными скриптами делают перебор очень простым. Конечно, существуют другие способы дополнительной безопасности, например, fail2ban, но аутентификация по ключу SSH более надежна.

Каждая пара ключей состоит из открытого и закрытого ключа. Секретный ключ сохраняется на стороне клиента и не должен быть доступен кому-либо еще. Утечка ключа позволит злоумышленнику войти на сервер, если не была настроена дополнительная аутентификация по паролю.

Как создать ключи SSH?

Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.

И так, генерация ключей ssh выполняется командой:

Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке

/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.

Затем утилита предложит ввести пароль для дополнительного шифрования ключа на диске. Его можно не указывать, если не хотите. Использование дополнительного шифрования имеет только один минус - необходимость вводить пароль, и несколько преимуществ:

Пароль никогда не попадет в сеть, он используется только на локальной машине для расшифровки ключа. Это значит что перебор по паролю больше невозможен.
Секретный ключ хранится в закрытом каталоге и у клиента ssh нет к нему доступа пока вы не введете пароль;
Если злоумышленник хочет взломать аутентификацию по ключу SSH, ему понадобится доступ к вашей системе. И даже тогда ключевая фраза может стать серьезной помехой на его пути.

Но все же, это необязательное дополнение и если не хотите, то вы можете просто нажать Enter. Тогда доступ по ключу ssh будет выполняться автоматически и вам не нужно будет что-либо вводить.

Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.

Загрузка ключа на сервер

Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.

Самый простой способ скопировать ключ на удаленный сервер - это использовать утилиту ssh-copy-id. Она тоже входит в пакет программ OpenSSH. Но для работы этого метода вам нужно иметь пароль доступа к серверу по SSH. Синтаксис команды:

При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл

/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.

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

/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:

/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p

Здесь вам тоже нужно набрать yes, если вы подключаетесь к новому серверу, а затем ввести пароль. Теперь вы можете использовать созданный ключ для аутентификации на сервере:

Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.

Отключение проверки пароля

sudo vi /etc/ssh/sshd_config

Теперь сохраните файл и перезапустите службу ssh:

sudo service ssh restart

Дальше будет возможно только подключение по ключу ssh, пароль не будет приниматься.

Выводы

В этой статье мы рассмотрели как выполняется авторизация по ключу ssh, настройка ключей ssh и добавить ssh ключ. Теперь вы можете войти на сервер без ввода пароля. Если у вас остались вопросы, спрашивайте в комментариях!

Рассматриваются вопросы настройки клиента и сервера для обеспечения аутентификации по ключу при установке SSH соединения.

Евгений Боздаганян

SSH • Компьютерные истории • Криптография • Linux • Конфигурирование • Истории

Сегодня я хочу обсудить тему, которая, собственно, и вынесена в заголовок. На самом деле, по ней довольно много информации и то, как все правильно сделать - давно известно. Зачем же тогда затрагивать ее еще раз? Все очень просто: если вы такой же новичок в Linux , как и я, то вы много чего еще не знаете. Как следствие, вам (как и мне), вероятнее всего, приходится многие вещи делать впервые и, как водится, не всегда правильно. Когда же вы обращаетесь за помощью, не важно, будь то к живому человеку, или к какому-то другому источнику информации, например, в интернете, довольно часто возникает вопрос: а на каком языке они с вами общаются? Оно и понятно, ведь уровни владения предметом слишком разные. Поговорите-ка с физиком или биологом на профессиональные для них темы - уверяю вас, ощущения будут примерно такими же.

Но вернемся к проблеме. В чем, собственно, она заключается и проявляется? Мне, например, каждый раз при подключении к удаленному хосту с помощью протокола SSH приходилось вводить пароль того пользователя, от имени которого я собирался работать на том самом хосте. И ладно, если подключаться надо было пару раз за месяц - можно потерпеть! А если чаще? А если значительно чаще? Про какие-то другие возможности (кроме ввода пароля) мне в то время вообще ничего не было известно и, следовательно, правильно задать вопрос (а, народная мудрость утверждает, что в правильно заданном вопросе уже содержится 80% ответа) я, увы, не мог. И я думаю, что в таком же положении оказывается множество начинающих пользователей, если, конечно, они случайно не наткнулись на какую-нибудь нужную и понятную им информацию в интернете или же целенаправленно не изучали интересующий их предмет (в нашем случае, Linux , SSH или еще что-нибудь). Но, к сожалению, целенаправленно и обстоятельно в современном мире мало кто что-либо делает 😞. А по поводу "наткнулись", то тут действует довольно простое правило: чем больше будет информации по теме, тем быстрее она вам попадется на глаза. Так что, не обессудьте.

Итак, мне приходилось вводить пароли при подключении с использованием протокола SSH по много раз за день, особенно тогда, когда надо было что-нибудь скопировать на мои сетевые накопители MyBookLive и MyBookLiveDuo . И не важно, как я копировал - с помощью ли команды scp или в MidnightCommander -е, используя Shell -соединение, реализованное с на основе специализированного протокола Fish - и тот и другой метод опираются все на тот же SSH .

Если честно, я терпел очень долго, но, рано или поздно, любому терпению приходит конец. И когда такой момент наступил, я с головой окунулся в интернет в поисках решения (или решений). И надо сказать, что я нашел довольно много информации и разнообразных примеров. Многие из них мне даже удалось опробовать, а некоторые - прочно закрепились в моем арсенале приемов и методов работы в Linux , правда, немного для других целей. Но то - отдельные истории и когда-нибудь я их тоже расскажу.

Сейчас же относительно того, как можно избежать постоянного ввода пароля при подключении к удаленному хосту по протоколу SSH . Как это не удивительно, но к тому решению, которое мною используется сейчас, я пришел не сразу. Хотя Google выводит его в топе. А все потому, что основано оно на использовании криптографии, с которой мне (в то время) было, если честно, страшновато работать. И я, просто с каким-то маниакальным упорством, пытался найти и применить другие подходы, которые, в принципе, и можно было бы принять в качестве решения озвученной задачи, но, по большому счету, предназначались они все-таки для чего-то другого. Тем не менее, я этому своему иррациональному страху использования криптографии в какой-то мере даже признателен, так как благодаря ему узнал довольно много интересных и полезных вещей (хорошим примером может служить использование файловой системы SSHFS ).

В общем, в какой-то момент мне удалось побороть страх и неуверенность и попробовать-таки использовать ключи при работе по SSH . Но прежде, чем последовать моему примеру, следует убедиться, что выполняется ряд предварительных требований, без которых предлагаемое решение работать просто не будет. На самом деле, на результате может сказаться не только то, какая компания (или автор) является производителем используемого вами ПО (стандарт - стандартом, но свои маленькие скелетики в шкафах есть практически у любого разработчика), но даже версия этого самого программного обеспечения - решение, работающее в одних условиях, может оказаться нежизнеспособным при других. В любом случае, я хотя бы попробую задать направление, в котором можно будет копать, если что-то пойдет не так. И для начала - предварительные требования:

на удаленном хосте должен быть установлен сервер SSH . Про то, что на вашем компьютере должно быть установлено клиентское ПО SSH , напоминать, наверное, не надо 😉?
вы должны иметь доступ к удаленному хосту. Не важно, что это будет: физический ли доступ с возможностью локального входа; удаленный доступ, опять же, с возможностью подконнектиться под нужным пользователем; бородатый администратор, который сможет выполнить за вас все необходимые действия - главное, чтобы был доступ.

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

Что надо знать про генерацию ключей? А вот что: не важно, к какому количеству хостов вы будете подключаться с помощью SSH - к одному или к десятку - вам нужен только один ключ, вернее, только одна пара ключей. Поэтому генерировать ее надо только один (первый) раз, все остальное время вы просто пользуетесь ранее сгенерированной парой ключей.

Предположим, что сейчас и есть тот самый первый раз (в противном случае, просто переходите к следующему шагу). Итак, при выполнении команды, приведенной выше, программа запросит у вас имя для файлов, в которых будут сохранены сгенерированные ключи - да, одно имя для двух файлов: имена будут одинаковыми, расширения - разными. И хотя соблазн задать имя, не совпадающее с используемым по умолчанию, может быть довольно силен, я рекомендую так не делать: впоследствии, вы сможете использовать при работе меньше дополнительных опций командной строки и/или настроек каких-либо сервисов. Если вы прислушаетесь ко мне, и оставите название, предлагаемое по умолчанию (просто нажмете Enter или Return ), то в подкаталоге

/.ssh для приватного ключа будет создан файл id_rsa (без расширения), а для публичного ключа - файл id_rsa.pub (то, что надо генерировать именно rsa ключи, было указано при помощь опции командной строки -t rsa , которую довольно часто можно просто опустить).

Второй вопрос, который задаст вам программа - указать пароль для защиты генерируемого приватного ключа. Если вы решите задать пароль, то следует помнить, что он должен содержать как минимум пять символов. Если же вы не захотите использовать пароль - просто нажмите Enter или Return .

Считается, что задание пароля позволит повысить безопасность: при установке соединения с удаленным хостом, прежде, чем использовать защищенный ключ, у вас попросят ввести пароль. Будет или нет установлено соединение зависит от того, введете ли вы правильный пароль в ответ на этот вопрос. Если же при генерации ключей вы откажетесь от определения пароля, то при установке соединения никаких вопросов задано не будет, вы просто тихо-мирно подключитесь к нужному удаленному хосту. Этот вариант удобен и именно из-за него я и затеял весь этот сыр-бор. Но он небезопасен: если кто-то получит доступ к вашей учетке на локальном компьютере, то он сможет также без проблем подключиться к любому удаленному хосту, с которым у вас настроено использование ключей для SSH соединения. Если честно, я выбрал удобство. Но это решение довольно серьезное и каждый должен принять его самостоятельно - только после оценки возможных рисков.

Итак, ключи сгенерены. Теперь требуется установить на удаленный хост публичный ключ. Я делаю это при помощи следующей команды:

В этом случае я указываю файл публичного ключа, при помощи опции командной строки -i id_rsa.pub , имя пользователя ( user-name ), под которым должно быть произведено соединение и имя или IP адрес удаленного хоста ( server_name_or_ip ). Вообще, id-rsa.pub это имя файла публичного ключа, используемое по умолчанию, поэтому, в принципе, его можно опустить, в частности, если вы прислушались к моему совету не оригинальничать при генерации ключей и оставить значение имени, предлагаемое по умолчанию. Тогда команда будет выглядеть так:

Я не стал разбираться, почему (пишут, что это может зависеть от установленной версии SSH ), и просто стал всегда явно указывать имя файла публичного ключа.

Еще хочу отметить, что, в некоторых случаях, команда ssh-copy-id работать не будет. Такая незадача может быть связана с особенностями сервера, вернее, с особенностями учетной записи пользователя на удаленном хосте. Например, если в качестве оболочки "по умолчанию" для удаленного пользователя установлено ПО, основанное не на bash или sh , то проблемы весьма и весьма вероятны. В таких случаях можно сделать все тоже самое, только вручную:

копируем файл публичного ключа на удаленный сервер в домашний каталог пользователя, под которым собираемся работать на этом сервере:

вместо user_name надо подставить имя нужного пользователя (на удаленном сервере), а вместо server_name_or_ip - имя сервера или его IP адрес (символ ':' это не опечaтка, он там должен быть). У вас, конечно, спросят пароль, но тут проблем быть не должно, не правда ли? 😉

соедиеяемся с сервером:

вместо user_name надо подставить имя нужного пользователя (опять же, на удаленном сервере), а вместо server_name_or_ip - имя сервера или его IP адрес, и да, от запроса и ввода пароля мы пока еще не избавились.

создаем подкаталог .ssh и файл authorized_keys :

Если нужные объекты уже существуют, приведенные команды им не навредят. И еще. Если вы решите создать эти объекты каким-то другим способом - пожалуйста, нет никаких проблем. Важно лишь помнить, что владельцем этих объектов должен быть пользователь, под которым вы собираетесь работать на удаленном хосте, и этот пользователь должен иметь права на чтение/запись в этот файл (речь про authorized_keys ).

записываем публичный ключ в файл authorized_keys :

Чтобы проверить, что все прошло нормально, и файл authorized_keys теперь содержит нужный ключ, можно воспользоваться командой:

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

можно удалить на сервере публичный ключ:

или же переместить его в подкаталог .ssh :

еще можно попробовать защитить файл authorized_keys :

Эта команда изменяет права доступа для файла authorized_keys таким образом, чтобы чтение/запись мог производить только владелец, то есть, мы. На самом деле, можно и дальше пытаться защитить этот файл (и каталог), например:

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

В заключении, хочу все-таки посвятить пару абзацев некоторому подобию теории и своему отношению ко всей этой истории (хотя, кого это интересует? 🤔). Например, почему считается, что соединение с использованием ключей является более безопасным? Ответ прост и кроется он в механизме аутентификации (проверке того, что вы - это вы). При соединении с использованием пароля, введенный вами пароль отсылается на удаленный хост и там проверяется. Это первое потенциально слабое место - теоретически, пересылаемый пароль можно перехватить; он, конечно, зашифрован и все такое, но. Второе слабое место - это возможность осуществить подбор пароля - попробовали один - не подошел, попробовали другой, и так далее. Конечно, это тоже та еще задачка, но, тем не менее.

При аутентификации с использованием ключей таких опасностей нет. Во-первых, никакой пароль никуда не пересылается. Сама схема аутентификации немного другая. Получив запрос на соединение, сервер, при помощи установленного на нем публичного ключа пользователя, запросившего соединение, зашифровывает некое послание (так называемый вызов) и отправляет его на хост, запросивший соединение. Это послание можно расшифровать только используя приватный ключ, который хранится в файле (например,

/.ssh/id_rsa ) у вызывающего пользователя. Если расшифровка произошла успешно, то вызывающий хост отправляет специальный ответ, получив который сервер понимает, что все в порядке и можно разрешить соединение. Все это происходит совершенно незаметно для пользователя, запросившего соединение.

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

И уж совсем под занавес: если хочется узнать чуть подробней про то, как работает аутентификация при использовании SSH , можно почитать материал по этой ссылке. На этом, пожалуй, все.

Читайте также: