Вопросы Теги

Отказ в SSH-подключении :Еще один для кучи! Пожалуйста, ознакомьтесь с процессом устранения неполадок

Я называю этот скрипт mouse-reset. Он удаляет, а затем modprobeсписок модулей, связанных с мышью -:

#!/bin/bash

modules=(psmouse hid_multitouch elan_i2c)

for mod in "${modules[@]}"; do
    sudo rmmod "$mod" 2> /dev/null
    sudo modprobe -v "$mod" 2> /dev/null
done
2
07.12.2020, 09:22
2 ответа

Сначала :поймите основы того, что должно произойти.

Предполагается, что клиентский процесс SSH на рабочем столе Windows подключается к TCP-порту 22 виртуальной машины DigitalOcean. Как только соединение установлено, оно должно аутентифицироваться как пользователь rootс использованием ключа SSH.

Это означает, что вам не нужныsshd(или «службы ssh» )на рабочем столе :, они понадобятся только в том случае, если вы хотите разрешить входящие подключения SSH к вашему рабочему столу.

Вы получаете сообщение об отказе в соединении. Это означает одно из следующих:

  • у вас может быть неправильный IP-адрес для облачной виртуальной машины (с облачными виртуальными машинами локальный IP-адрес, который видит внутри виртуальная машина, может не совпадать с адресом, представленным в Интернете облачной инфраструктурой)
  • в вашей локальной сети может потребоваться использование прокси-сервера для доступа к службам за пределами локальной сети (распространено в сетях на рабочем месте)
  • виртуальная машина Digital Ocean может вообще не работать
  • Брандмауэр виртуальной машины в облаке может не разрешать входящие SSH-соединения, пока вы не укажете разрешенные исходные IP-адреса
  • возможно, вам придется использовать веб-интерфейс/API Digital Ocean, чтобы включить службу SSH на облачной виртуальной машине.

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

Разрешить вход в систему с аутентификацией по паролю -на облачной виртуальной машине — очень плохая идея если доступ к SSH-порту не ограничен только известными IP-адресами :существуют взломанные серверы и автоматизированные вредоносные программы, которые будут тратить все свое время на сканирование Интернета в поисках хостов с поддержкой SSH -и попытки взлома любых хорошо -известных учетных записей пользователей, включая root.

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

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

Часто поставщик облачных услуг предоставляет предварительно -сгенерированный закрытый ключ SSH для начального доступа SSH к виртуальной машине. Существует несколько возможных форматов файлов ключей :файл *.ppkпредназначен для PuTTY, распространенного бесплатного клиента SSH для Windows (, в настоящее время также доступного для Linux ), а файл id_*без определенного суффикса предназначен для OpenSSH. Обычно ключи можно преобразовать из одного формата в другой с помощью соответствующих инструментов генератора ключей (, таких как PuTTYgen keyfile.ppk -O private-openssh -o id_opensshдля преобразования *.ppkфайлов в формат OpenSSH ).

Если вы используете клиент SSH с командной строкой -WSL, это форма OpenSSH. Обычно OpenSSH ищет закрытые ключи по умолчанию в каталоге .sshsub -домашнего каталога локального пользователя (с именем id_rsa, id_dsa, id_ecdsa, id_ed25519и т. д. в соответствии с используемым алгоритмом ). Если какой-либо из этих файлов закрытого ключа существует, клиент автоматически предложит их удаленному серверу, если он разрешает аутентификацию на основе ключа -.

В WSL расположение домашнего каталога в стиле Unix -может быть не столь очевидным, поэтому вы можете использовать параметр -i, чтобы явно указать используемый файл закрытого ключа.

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

ssh -i /some/where/id_digitalocean_privatekey root@123.456.78.911
1
18.03.2021, 22:45

Ну, во-первых. НЕ ИСПОЛЬЗУЙТЕ эту настройку. На самом деле вы вообще не хотите использовать эти MAC-адреса!

Вы пытались включить аутентификацию по паролю? Просто посмотреть, работает ли это? Также вы проверяли /var/log/auth.log? Вы увеличили детализацию ведения журнала sshd в конфигурации /etc/sshd/sshd _?

Мне кажется, что демон sshd неправильно прослушивает порт 22. Вот почему вы получаете отказ в подключении. вы можете проверить с помощью nmap, действительно ли этот порт открыт. 

sudo nmap -sSV -O -p 22 -v9 destination_IP
-2
18.03.2021, 22:45

Теги

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