Назад | Перейти на главную страницу

Подозрительный пароль для входа в sshd log

У меня есть сервер Linux, работающий под виртуальным ящиком Windows. я использую ssh с участием публичный ключ для входа в систему и использовать функцию sftp lftp для передачи файлов, которая также использует публичный ключ.

Сегодня, когда я проверяю лог-файл, меня что-то очень смущает:

28 ноября 21:39:06 soft-server sshd [11933]: принят публичный ключ для myusername из порта 10.0.2.2 50590 ssh2 28 ноября 21:39:06 soft-server sshd [11933]: pam_unix_session (sshd: session): сеанс открыт для пользователя myusername пользователем (uid = 0)

28 ноября 21:39:25 soft-server sshd [11946]: принят пароль для myusername из порта 10.0.2.2 13494 ssh2

28 ноября 21:39:25 soft-server sshd [11946]: pam_unix_session (sshd: session): сеанс открыт для пользователя myusername пользователем (uid = 0)

28 ноября 21:39:25 soft-server sshd [11948]: запрос подсистемы для sftp пользователем myusername

28 ноября 21:40:16 soft-server sshd [11935]: Получено отключение от 10.0.2.2: 11: отключено пользователем

28 ноября 21:40:16 soft-server sshd [11933]: pam_unix_session (sshd: session): сеанс закрыт для пользователя myusername

Как мне вдруг использовать пароль для входа? Есть ли вероятность, что моя собственная операция вызывает такое поведение?

Что ж, это законное соединение sftp-via-ssh с вашего IP-адреса. Либо у вас был кейлоггинг, либо (что более вероятно, на мой взгляд) вы забыли, что вы настроили sftp на основе пароля для некоторого приложения, такого как DreamWeaver, которое автоматически входит на ваш виртуальный хост, чтобы поддерживать его репозиторий файлов в актуальном состоянии.

Это настоящий логин. И отвечу на ваш вопрос «как можно вдруг использовать пароль для входа в систему», это потому, что вы просто не отключили аутентификацию по паролю.

Если вам не требуется аутентификация по паролю ни для одного из ваших пользователей, вы должен установить PasswordAuthentication флаг в вашем sshd_config к no, поскольку пароль может быть введен с помощью кейлоггера или перебора.

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

Если у вас ДЕЙСТВИТЕЛЬНО есть пользователи, которым требуется аутентификация по паролю, вы можете использовать Match User или Match Group вот так:

PasswordAuthentication no
Match User passwordauthuser
    PasswordAuthentication yes

или

PasswordAuthentication no
Match Group passwordauth
    PasswordAuthentication yes

Другой вариант, который у вас есть, если вам ДЕЙСТВИТЕЛЬНО нужна аутентификация по паролю, - это то, что я делал в прошлом, nl создал очень длинное имя пользователя, которое почти невозможно угадать, чтобы уменьшить вероятность того, что кто-то угадывает этого пользователя.

Например echo "mysupersecretuser" | sha256sum | sha256sum. Это по-прежнему подвержено кейлоггерам или захвату буфера обмена. Но, очевидно, снижает вероятность того, что кто-то угадывает вашего пользователя, до нигиллума.

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

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

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

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

Вам следует

  1. Как можно скорее измените свой пароль / имя пользователя на что-то вроде mynEwp@$$_2011foobar
  2. также проверьте свой пароль root
  3. просмотрите историю оболочки / системные журналы и проверьте, какие команды были выполнены взломанной учетной записью
  4. переплетать sshd на порт не по умолчанию, например 41022

последнее действие дает вам некоторый уровень защиты от автоматических «червей» и «ботов». Обычно они пытаются подключиться только к портам по умолчанию.

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