Использование пароля
Начнем с инструкции о том, как подключиться к удаленному серверу через SSH по логину и паролю. Это самый простой способ. Хостер предоставляет вам IP-адрес, логин и пароль. Этого достаточно для того, чтобы установить соединение с удаленным сервером.
Подключение на Windows
Моя основная система — Windows. Раньше для подключения к серверу через SSH я пользовался сторонней утилитой PuTTY, потому что в операционной системе не было встроенного компонента. В «десятке» он появился, так что теперь можно подключаться к SSH через командную строку (cmd).
Чтобы включить встроенный в систему OpenSSH:
- Откройте «Параметры» (Win + I) и перейдите в раздел «Приложения».
- Выберите опцию «Управление дополнительными компонентами».
- Нажмите «Добавить компонент».
- Выберите в списке OpenSSH Client и нажмите «Установить».
- После завершения установки перезагрузите систему.
Теперь разберемся, как подключиться к SSH через cmd. Запустите командную строку и выполните запрос вида ssh root@185.104.114.90.
Значение root — логин для подключения, вы получили его в письме при создании сервера. 185.104.114.90 — IP-адрес сервера. Его можно посмотреть в панели управления сервером или в том же письме, которое прислал хостер. У команды может быть также дополнительный параметр -p, после которого прописывается номер порта. По умолчанию используется порт 22. Если у вас настроен другой порт, нужно явно его указать, — например, полный адрес может выглядеть так: ssh root@185.104.114.90 -p 150.
После выполнения команды клиент SSH предложит добавить устройство в список известных. Введите в командной строке yes и нажмите на Enter. Затем укажите пароль для доступа к серверу. На этом подключение к серверу через SSH завершено — теперь все команды будут выполняться на удаленной машине, к которой вы подключились.
На версиях младше Windows 10 1809 нет встроенной поддержки протокола OpenSSH. В таком случае понадобится сторонняя утилита. Смотрим, как через PuTTY подключиться по SSH:
- Запустите PuTTY.
- На вкладке Session укажите Host Name (IP-адрес сервера), Port (по умолчанию 22, но если вы в конфигурации сервера указали другой порт, нужно задать его номер).
- Убедитесь, что тип соединения установлен SSH.
- Нажмите на кнопку Open, чтобы подключиться.
Если вы ввели правильные данные, появится окно консоли, в котором нужно указать логин и пароль для подключения к серверу. При первом запуске также отобразится запрос на добавление устройства в список известных.
Подключение на Linux и macOS
Теперь посмотрим, как подключиться по SSH через терминал на Linux. Для этого не требуется установка дополнительных компонентов, все работает «из коробки».
- Запустите терминал. Обычно для этого используется сочетание клавиш Ctrl+Alt+T. Найти терминал также можно по пути «Главное меню» — «Приложения» — «Система».
- Выполните команду для подключения. Синтаксис такой же, как на Windows, — ssh root@185.104.114.90. Если порт не стандартный, то нужно явно его указать: например, ssh root@185.104.114.90 -p 150. Вместо root вы указываете свое имя пользователя, а вместо 185.104.114.90 — IP-адрес своего сервера.
- Если хост и порт указаны верно, на следующем шаге появится запрос на ввод пароля. При первом подключении также будет предложение добавить новое устройство в список известных. Для этого введите yes и нажмите на клавишу Enter.
На этом подключение завершено. Теперь все команды, которые вы вводите в терминале, будут выполняться на удаленной машине.
Если IP-адрес или порт указаны неверно, то на экране появится сообщение об ошибке — Connection Refused. Это может также говорить о том, что доступ запрещен брандмауэром на удаленном сервере (если вы его не отключили). Чтобы разрешить подключение через SSH:
- на сервере с Ubuntu/Debian выполните команду $ sudo ufw allow 22/tcp;
- на сервере CentOS/Fedora выполните команду $ firewall-cmd —permanent —zone=public —add-port=22/tcp.
Цифра 22 в синтаксисе — номер порта. Если вы используете другой порт, то укажите его явно.
Если вы знаете как подключиться через SSH на Linux, то справитесь с этой задачей и на macOS. В операционной системе Apple тоже есть встроенный терминал. Синтаксис команды для подключения не меняется: ssh root@185.104.114.90, где root — ваш логин, а 185.104.114.90 — IP-адрес сервера, с которым вы устанавливаете соединение.
Старые версии Windows (без OpenSSH)
Создание SSH-ключей
Запустите программу, в открывшемся окне выберите «Type of key — SSH-2 RSA и нажмите «Generate».
Пока создается ключ, водите мышью в хаотичном порядке в пространстве под строкой загрузки для генерации случайных значений.
После того, как ключ будет создан, в окне программы вы сможете задать «Key passphrase» (кодовую фразу) для ключа. Это необязательно, вы можете оставить строку пустой
Если вы решите задать кодовую фразу, обратите внимание, что ее потребуется вводить при каждой авторизации по ключу.
Далее сохраните созданные ключи, нажав на кнопки «Save public key» и «Save private key», например, под именами id_rsa.pub и mykey.ppk. Также скопируйте и сохраните в любом текстовом файле содержимое окна «Public key for pasting…» — оно потребуется при копировании созданного ключа на сервер.
На этом процедура создания ключей завершена.
Копирование ключей на сервер
-
Подключитесь к серверу по SSH и выполните команду для создания на сервере директории и файла для хранения ключей:
mkdir ~/.ssh chmod 0700 ~/.ssh touch ~/.ssh/authorized_keys chmod 0644 ~/.ssh/authorized_keys
-
Откройте созданный файл с помощью текстового редактора:
nano ~/.ssh/authorized_keys
- Вставьте в него скопированный на предыдущем шаге текст public key из окна PuTTYgen и сохраните файл.
- Запустите pageant — его иконка появится в трее. Щелкните по ней правой кнопкой мыши и выберите Add Key.
- В открывшемся окне укажите путь к приватному ключу mykey.ppk, сохраненному ранее, и нажмите Open. Если при создании ключа вы указывали кодовую фразу, pageant запросит ее на данном этапе.
-
Для проверки работы авторизации по ключу снова запустите утилиту PuTTY, подключитесь к вашему серверу и введите свой логин. Если все настроено корректно, вы увидите подобный вывод в окне консоли:
Authenticating with public key "rsa-key-20151220" from agent
Вход на серверную машину с помощью SSH без пароля
Теперь открытый ключ существует как на клиентских, так и на серверных машинах. Когда клиентский компьютер отправляет запрос на соединение серверу с помощью команды ssh, сервер сопоставляет открытый ключ клиента с открытым ключом сервера. Если совпадения найдены, то соединение будет установлено от клиента к серверу. Вы можете подключиться к серверу или удаленному хосту, используя имя хоста или IP-адрес. Локальный сервер использовал это руководство, чтобы показать использование авторизованных ключей для установления SSH-соединения с клиентского компьютера на серверный. Одна учетная запись использовалась как серверная машина, на которой установлен сервер OpenSSH, а другая учетная запись использовалась здесь как клиентская машина. Выполните следующую команду на клиентском компьютере, чтобы установить соединение с сервером.
Следующий вывод появится после выполнения указанной выше команды. Выходные данные показывают, что имя пользователя клиентской машины — «yesmin». Имя пользователя серверной машины — fahmida. SSH-соединение установлено правильно, поскольку имя пользователя изменилось на «fahmida» с «yesmin». Теперь можно легко получить доступ к содержимому серверной машины. Если пользователь сейчас выполняет какую-либо команду, вывод будет сгенерирован на основе сервера.
7 ответов
Лучший ответ
Для записи обычное имя пользователя по умолчанию в EC2 для этих дистрибутивов Linux:
- Amazon Linux: пользователь ec2
- Ubuntu: убунту
- Debian: администратор
Чтобы получить доступ к экземпляру через браузер, убедитесь, что вы добавили правило в свой группа безопасности, чтобы разрешить входящий порт 80 и порт 443.
39
David Levesque
4 Фев 2014 в 06:13
У меня была аналогичная проблема, решенная с использованием правильного и правильной загрузки файла .
Имя пользователя в EC2 зависит от машины AMI. Используйте следующие логины для следующих AMI:
Если вы используете ОС:
Полную документацию можно найти здесь и
imlv
26 Фев 2020 в 14:16
У меня была такая же проблема, но причина, по которой я получал ошибку, заключается в том, что я дал другое имя kevaluepair при создании экземпляра того, что я использую.
Убедитесь, что имя пары «ключ-значение» одинаково во всех ситуациях.
Supreeth Meka
28 Окт 2014 в 05:57
Важно понимать, что если ваш экземпляр создан какой-либо другой службой (например, Elastic Beanstalk), а не напрямую из EC2, вы, вероятно, столкнетесь с аналогичными проблемами. Возможно, с вашим экземпляром еще нет пары ключей
Чтобы проверить это, перейдите к своему экземпляру из
Возможно, с вашим экземпляром еще нет пары ключей . Чтобы проверить это, перейдите к своему экземпляру из
Обратите внимание на » Название пары ключей «. Если там есть допустимое значение (это должно быть то же самое, что вы использовали для генерации ключа из Putty Key Generator), тогда это подозрение может быть отменено
В противном случае вам может потребоваться воссоздать экземпляр в худшем случае.
В моем случае экземпляр был создан Elastic Beanstalk, то есть EBS (другой сервис AWS), где я разместил веб-приложение, я подключил существующую пару ключей к среде EBS, и соединение через Putty прошло.
1
Sadique Khan
30 Янв 2018 в 19:12
У меня была такая же проблема даже с ec2-user , я использовал Public DNS вместо Public IP . Теперь это решено.
1
user3966432
26 Июн 2017 в 08:17
Используйте публичное DNS-имя вместо IP. В замазке выберите соединение> SSH> Auth. Вы увидите часть параметров аутентификации, в которой вы можете выбрать свой файл ppk.
И еще один очень важный момент. Нажмите «Разрешить попытки изменения имени пользователя в SSH-2», чтобы активировать его.
2
Fenix Lam
12 Июл 2017 в 06:59
У меня была точно такая же проблема на Amazon EC2, и я просто изменил свое имя пользователя на «ubuntu», и он установил соединение.
2
DubbyTT
3 Апр 2014 в 05:15
Шаг 1 — Создание пары ключей RSA
Сперва создадим пару ключей на клиентской машине (обычно, это ваш компьютер):
По умолчанию создаёт 2048-битную пару ключей RSA, которая достаточно безопасна для большинства сценариев использования (вы можете также добавить к этой команде флаг для получения 4096-битный ключей).
После ввода этой команды вы должны увидеть следующий вывод:
Нажмите Enter для сохранения пары ключей в директорию внутри вашей домашней директории или задайте другую директорию.
Если ранее вы уже генерировали пару SSH ключей, вы можете увидеть следующий вывод:
Если вы выберете перезаписать ключи на диск, вы не сможете использовать старые ключи для аутентификации. Будьте очень осторожны при выборе , это решение нельзя будет отменить.
Вы должны увидеть следующий вывод:
Здесь вы можете задать ключевую фразу (passphrase), что обычно рекомендуется сделать. Ключевая фраза добавляет дополнительный уровень безопасности для предотвращения входа на сервер неавторизованных пользователей.
Вы должны увидеть следующий вывод:
Теперь у вас есть пара из публичного и секретного ключей, которые вы можете использовать для аутентификации. Далее мы поместим публичный ключ на ваш сервер, для того, чтобы вы могли использовать аутентификацию по ключам SSH для входа.
5: Восстановление доступа к Google MFA (опционально)
Занимаясь настройкой защиты любой системы, вы берёте на себя ответственность за управление безопасностью этой системы. Под этим подразумевается, что вы должны сохранить в надежном свой SSH-ключ, секретный ключ TOTP или же доступ к TOTP-приложению. К сожалению, в некоторых ситуациях ключи или доступ к приложению всё же теряются, и тогда их необходимо восстановить.
Восстановление секретного ключа TOTP
Если вы потеряли свой ключ TOTP, рекомендуем вам такой процесс восстановления, его можно разделить на два этапа:
- Вход без кода подтверждения;
- Поиск старого или создание нового ключа для восстановления MFA.
Обычно доступ теряется, если у вас появился новый смартфон, на который вы не перенесли свои данные.
Чтобы попасть на сервер, когда секретный ключ утрачен, используйте консоль хостинг-провайдера (это работает, потому что, как правило, с помощью MFA провайдеры защищают только соединения SSH; соединения, не связанные с SSH, не используют модуль PAM Google Authenticator).
Если доступа к консоли нет, у вас есть два варианта восстановления доступа:
- Консольный (локальный, не SSH) доступ к системе (то есть физический доступ или через приложение типа iDrac)
- Пользователь с доступом к sudo, для которого не была активирована MFA.
Второй вариант является менее безопасным, поскольку цель MFA – усилить защиту всех SSH-соединений, но это один из самых надежных способов восстановить доступ к приложению.
Войдя в систему, вы можете получить секретный ключ:
- Восстановить утерянный ключ;
- Сгенерировать новый ключ.
В домашнем каталоге каждого пользователя есть файл ~/.google-authenticator, где хранятся секретный ключ и настройки Google Authenticator. Первая строка этого файла содержит необходимый нам ключ. Чтобы получить его, выполните следующую команду, она выведет первую строку файла google-authenticator. Полученный ключ можно ввести в TOTP-приложение.
Восстановив текущий ключ, вы можете либо вручную ввести его в приложение аутентификации, либо ввести соответствующие данные в приведенный ниже URL-адрес и попросить Google сгенерировать QR-код, который вы сможете просканировать. Вам нужно будет указать в адресе свое имя пользователя, имя хоста, секретный ключ из файла .google-Authenticator, а затем любое имя для ‘entry-name-in-auth-app’, чтобы легко отличить этот ключ от других токенов TOTP:
Если же по какой-либо причине вы не может воспользоваться текущим ключом (к примеру, если у вас нет возможности безопасно передать его), вы можете временно переместить файл ~/.google-authenticator в другое место. Это позволит вам получить доступ к серверу по одному фактору (если только вы не сделали многофакторную аутентификацию обязательной, удалив опцию nullok) и запустить google-authenticator, чтобы сгенерировать новый ключ.
Восстановление доступа к TOTP-приложению
Если вы утратили доступ к своему TOTP-приложению и не можете создать код подтверждения, используйте коды для восстановления, которые были выданы вам во время создания первого секретного ключа. Это последние пять строк файла .google-authenticator.
Важно! Эти коды восстановления одноразовые
Создание ключей SSH
Первый шаг для настройки аутентификации ключей SSH на сервере заключается в том, чтобы сгенерировать пару ключей SSH на локальном компьютере.
Для этого мы можем использовать специальную утилиту , которая входит в стандартный набор инструментов OpenSSH. По умолчанию она создает пару 2048-битных ключей RSA, что подходит для большинства сценариев использования.
Сгенерируйте на локальном компьютере пару ключей SSH, введя следующую команду:
Утилита предложит вам выбрать место размещения генерируемых ключей. По умолчанию ключи хранятся в каталоге внутри домашнего каталога вашего пользователя. Закрытый ключ будет иметь имя , а соответствующий открытый ключ будет иметь имя .
На этом этапе лучше всего использовать каталог по умолчанию. Это позволит вашему клиенту SSH автоматически находить ключи SSH при попытке аутентификации. Если вы хотите выбрать нестандартный каталог, введите его сейчас, а в ином случае нажмите ENTER, чтобы принять значения по умолчанию.
Если ранее вы сгенерировали пару ключей SSH, вы можете увидеть следующий диалог:
Если вы решите перезаписать ключ на диске, вы больше не сможете выполнять аутентификацию с помощью предыдущего ключа. Будьте осторожны при выборе варианта yes, поскольку этот процесс уничтожает ключи, и его нельзя отменить.
Далее вам будет предложено ввести парольную фразу для ключа. Это опциональная парольная фраза, которую можно использовать для шифрования файла закрытого ключа на диске.
Возможно вам будет интересно, в чем заключаются преимущества ключа SSH, если вам все равно нужна парольная фраза. Вот некоторые его преимущества:
- Закрытый ключ SSH (защищенная паролем часть) никогда не доступен через сеть. Парольная фраза используется только для расшифровки ключа на локальном компьютере. Это означает, что парольную фразу нельзя взломать через сеть методом прямого подбора.
- Закрытый ключ хранится в каталоге с ограниченным доступом. Клиент SSH не принимает закрытые ключи, хранящиеся в каталогах, доступ к которым не ограничен. У самого ключа могут быть ограниченные разрешения (чтение и запись доступны только владельцу). Это означает, что другие пользователи системы не смогут создать уязвимость.
- Для попытки взлома защищенного парольной фразой закрытого ключа SSH злоумышленнику уже необходим доступ к системе. Это означает, что у него уже должен быть доступ к учетной записи пользователя или учетной записи root. Если вы окажетесь в такой ситуации, парольная фраза может помешать злоумышленнику сразу же попасть на ваши другие серверы. Это может дать вам достаточно времени, чтобы создать и внедрить новую пару ключей SSH и запретить доступ с взломанным ключом.
Поскольку закрытый ключ недоступен через сеть и защищен системой разрешений, доступ к этому файлу будет только у вас (и у пользователя root). Парольная фраза служит дополнительным уровнем защиты на случай взлома одной из этих учетных записей.
Парольная фраза представляет собой необязательное дополнение. Если вы решите ее использовать, вам нужно будет вводить ее при каждом использовании соответствующего ключа (если вы не используете программный агент SSH, хранящий зашифрованный ключ). Мы рекомендуем использовать парольную фразу, но если вы не хотите ее задавать, вы можете просто нажать ENTER, чтобы пропустить этот диалог.
Теперь у вас есть открытый и закрытый ключи, которые вы можете использовать для аутентификации. Следующим шагом будет размещение открытого ключа на сервере, что позволит использовать аутентификацию SSH для входа в систему.
Ошибка копирования контейнера
Но тут есть важный нюанс. Если во время создания закрытого ключа он не был помечен как экспортируемый, скопировать его не получится. У вас будет ошибка:
Ошибка копирования контейнера. У вас нет разрешений на экспорт ключа, потому что при создании ключа не был установлен соответствующий флаг. Ошибка 0x8009000B (-2146893813) Ключ не может быть использован в указанном состоянии. Либо вы просто не сможете его выбрать для копирования, если у вас последняя версия CryptoPro. Он будет неактивен:
Если получили такую ошибку, то для вас этот способ переноса не подходит. Можно сразу переходить к следующему. Отдельно расскажу, как скопировать сертификат и закрытый ключ к нему в файл, чтобы перенести на другой компьютер без использования токена. Делаем это там же на вкладке Сервис в оснастке CryptoPro. Нажимаем Посмотреть сертификаты в контейнере.
Выбираем необходимый сертификат и нажимаем Посмотреть свойства сертификата.
Далее переходим на вкладку Состав в информации о сертификате и нажимаем Копировать в файл.
Если у вас после слов «Экспортировать закрытый ключ вместе с сертификатом» нет возможности выбрать ответ «Да, экспортировать закрытый ключ», значит он не помечен как экспортируемый и перенести его таким способом не получится. Можно сразу переходить к другому способу, который описан ниже.
Если же такая возможность есть, то выбирайте именно этот пункт и жмите Далее. В следующем меню ставьте все галочки, кроме удаления. Так вам будет удобнее и проще в будущем, если вдруг опять понадобится копировать ключи уже из нового места.
Укажите какой-нибудь пароль и запомните его! Без пароля продолжить нельзя. В завершении укажите имя файла, куда вы хотите сохранить закрытый ключ. Теперь вам нужно скопировать сам сертификат. Только что мы копировали закрытый ключ для него. Не путайте эти понятия, это разные вещи. Опять выбираете этот же сертификат в списке из оснастки Crypto Pro, жмёте Копировать в файл, экспортировать БЕЗ закрытого ключа. И выбираете файл формата .CER.
Сохраните сертификат для удобства в ту же папку, куда сохранили закрытый ключ от него. В итоге у вас должны получиться 2 файла с расширениями:
- .pfx
- .cer
Вам достаточно перенести эти 2 файла на другой компьютер и кликнуть по каждому 2 раза мышкой. Откроется мастер по установке сертификатов. Вам нужно будет выбрать все параметры по умолчанию и понажимать Далее. Сертификат и контейнер закрытого ключа к нему будут перенесены на другой компьютер. Я описал первый способ переноса в ручном режиме. Им можно воспользоваться, если у вас немного сертификатов и ключей. Если их много и руками по одному переносить долго, то переходим ко второму способу.
Массовый перенос ключей и сертификатов CryptoPro с компьютера на компьютер
В интернете достаточно легко находится способ переноса контейнеров закрытых ключей КриптоПро через копирование нужной ветки реестра, где это все хранится. Я воспользуюсь именно этим способом. А вот с массовым переносом самих сертификатов у меня возникли затруднения и я не сразу нашел рабочий способ. Расскажу о нем тоже. Для дальнейшей работы нам надо узнать SID текущего пользователя, у которого мы будем копировать или переносить сертификаты с ключами. Для этого в командной строке выполните команду:
В данном случай user — имя учетной записи, для которой узнаем SID. Далее скопируем контейнеры закрытых ключей в файл. Для этого на компьютере открываем редактор реестра (regedit.exe) и переходим в ветку:
где S-1-5-21-4126888996-1677807805-1843639151-1000 — SID пользователя, у которого копируем сертификаты. Выбираем папку Keys и экспортируем ее. Этот путь актуален для 64-х битных систем — Windows 7, 8, 10. В 32-х битных путь может быть немного другой. Я специально не проверял, но поиском по реестру вы при желании найдете его.
Сохраняем ветку реестра в файл. В ней хранятся закрытые ключи. Теперь нам нужно скопировать сразу все сертификаты. В Windows 7, 8 и 10 они живут в директории — C:\Users\user\AppData\Roaming\Microsoft\SystemCertificates\My. Сохраняйте эту директорию. Для переноса ключей и сертификатов нам надо скопировать на другой компьютер сохраненную ветку реестра и директорию с сертификатами My.
После того, как перенесли файлы со старого компьютера на новый, открываем файл с веткой реестра в текстовом редакторе и меняем там SID пользователя со старого компьютера на SID пользователя нового компьютера. Можно прям в блокноте это сделать поиском с заменой.
После этого запускаем .reg файл и вносим данные из файла в реестр. Теперь скопируйте папку My с сертификатами в то же место в профиле нового пользователя. На этом перенос сертификатов и контейнеров закрытых ключей КриптоПро завершен. Можно проверять работу. Я не раз пользовался этим методом, на текущий момент он 100% рабочий. Написал статью, чтобы помочь остальным, так как сам не видел в интернете подробной и понятной с первого раза статьи на эту тему. Надеюсь, моя таковой получилась.