ssh не разрешает вход без пароля

Не ответ, а попытка сузить проблему:

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

+-----------+                             +----------+
|        o--|--o                  o--ptya |  ptyb--o |
|   veth0b  |  veth0a          ppp0       |     ppp0 |
| 10.0.0.1  |  10.0.0.254  10.0.3.1       | 10.0.3.2 |
|           |                             |          |
|   ns0     |                             |   ns1    |
+-----------+                             +----------+

где соединение ppp -было выполнено следующим образом (второй pppd в пространстве имен ns1, разумеется):

socat PTY,link=/tmp/ptya PTY,link=/tmp/ptyb
sudo pppd `readlink /tmp/ptya` noauth nocrtscts xonxoff local maxfail 0 10.0.3.1:10.0.3.2 persist
sudo pppd `readlink /tmp/ptyb` noauth nocrtscts xonxoff local maxfail 0 10.0.3.2:10.0.3.1 persist

Маскарад:

sudo iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Из ns0 ping 10.0.3.2появляется на tcpdump -i ppp0в основном пространстве имен как

IP 10.0.3.1 > 10.0.3.2: ICMP echo request, id 23836, seq 1, length 64
IP 10.0.3.2 > 10.0.3.1: ICMP echo reply, id 23836, seq 1, length 64

так что маскировка явно работает, и это не интерфейс ppp -как-то капризничает.

Что я хотел бы попробовать дальше:

  • Воспроизведите настройку socat/ppp на своем сервере и посмотрите, работает ли она.или если есть что-то, что мешает ему работать.

  • Первоначально я пытался установить соединение PPPoE -с пользовательским пространством pppoe, но это было достаточно запутанно, поэтому pppd, порожденный pppoe-server, продолжал умирать, и я еще не понял, почему. Так что, если вы можете уменьшить свою конфигурацию PPPoE до аналогичной настройки (и, возможно, рассказать мне, что вы сделали ), можно выяснить, не является ли PPPoE каким-то образом испорченным.

  • Пытаясь это сделать, я заметил, что скрипты делают много вещей за кулисами, если вы не будете осторожны :маршруты по умолчанию, назначения IP-адресов, запись в iptables и еще много чего. Так что я бы дважды проверил, нет ли в вашей настройке забавных правил iptables, маршрутов или чего-то еще, даже если вы их туда не поместили.

1
11.10.2019, 20:58
3 ответа

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

Пожалуйста, взгляните на эту ссылку.https://askubuntu.com/questions/1019999/key-based-ssh-login-that-requires-both-key-and-password

0
27.01.2020, 23:30

Итак, это не является ответом на вашу конкретную проблему, а просто рецептом, который я использую всякий раз, когда сталкиваюсь с непонятными проблемами, как у вас. Это копия из ответа, который я написал на AskUbuntu .

Чтобы подчеркнуть здесь преимущества:

  1. более быстрый "обход"... вы можете передавать параметры конфигурации(-o OptionName=OptionValue)на -лету -, не прибегая к редактированию файла sshd_config.
  2. вы можете использовать альтернативную копиюsshd_config(-f...).
  3. Используя альтернативный порт, вы меньше рискуете заблокировать себя, если удаленный сервер доступен только через SSH.

Поиск и устранение неисправностейsshd

Что я считаю очень полезным в таких случаях, так это запускать sshd, не позволяя ему демонизироваться. Проблема в моем случае заключалась в том, что ни syslog, ни auth.logне показали ничего значимого.

Когда я запустил его из терминала, я получил:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Гораздо лучше! Это сообщение об ошибке позволило мне увидеть, что не так, и исправить это. Ни один из файлов журнала не содержал этого вывода.

NB:по крайней мере, в Ubuntu $(which sshd)— лучший способ удовлетворить sshdтребование абсолютного пути.В противном случае вы получите следующую ошибку :sshd re-exec requires execution with an absolute path. -p 10222заставляет sshdпрослушивать этот альтернативный порт, переопределяя файл конфигурации -, чтобы он не конфликтовал с потенциально работающими экземплярами sshd. Обязательно выберите здесь свободный порт.

Этот метод много раз помогал мне в поиске проблем, будь то проблемы с аутентификацией или другие типы. Чтобы получить действительно подробный вывод в stdout, используйте$(which sshd) -Ddddp 10222(обратите внимание на добавленный ddдля увеличения детализации ). Для получения дополнительных сведений об отладке проверьте man sshd.

0
27.01.2020, 23:30

Сервер предлагает открытый ключ:

debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
debug3: send packet: type 51 [preauth]

но клиент отказывается:

debug3: receive packet: type 51
debug1: Authentications that can continue: password

Проверьте/etc/ssh/ssh_config(клиентскую сторону глобальную конфигурацию ), чтобы убедиться, что

PubkeyAuthentication = yes

Кроме того, поскольку это, похоже, -проблема на стороне клиента, вы можете настроить права доступа для.ssh и всех файлов внутри правильно.

2
27.01.2020, 23:30

Теги

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