sshd не закрывает с “Никакими поддерживаемыми ключевыми обменными алгоритмами” ошибку

Это будет немного хитрым, если Вы предназначаете к соглашению это как одну большую подсеть, потому что 192.168.1.0 to 192.168.2.255 не правильно выровненный на правильной границе для/23 подсети, таким образом, Вы не можете рассматривать ее как 192.168.1.0/23.

Если бы Вы полностью установлены при использовании конкретно 192.168.1, и 192.168.2 затем необходимо было бы использовать подсеть 192.168.0/22, который является на самом деле диапазоном от 192.168.0.0 to 192.168.3.255. Главным образом это просто означает изменять маску подсети в Вашей целой сети к 255.255.252.0

Однако, после того как Вы сделали тот свой сервер DHCP, должен быть совершенно счастливый дюйм/с обслуживания от непрерывного диапазона 192.168.1.100 to 192.168.2.254.

8
задан 7 July 2010 в 14:08
10 ответов

Я просто поразил ту же проблему, решил его путем превращения моего относительного пути HostKey к абсолютному, т.е. вместо

HostKey ./ssh_host_key

поместите:

HostKey /home/dmitry/ssh_host_key

или везде, где это.

Та ошибка не очень полезна, это?

6
ответ дан 2 December 2019 в 22:41

FWIW, я столкнулся с тем же сообщением об ошибке, но с другой причиной. В моем случае проблема заключалась в том, что файлы закрытых ключей моего хоста были в режиме 640 вместо 600. Быстрый перезапуск chmod и sshd решил проблему. Я предполагаю, что общая тема здесь - sshd не загружает ключи хоста по той или иной причине.

4
ответ дан 2 December 2019 в 22:41

Я только что столкнулся с этой проблемой при помощи cloud-init . В моем случае причина заключалась в том, что ключи хоста не были сгенерированы, и dpkg-reconfigure openssh-server (специально для Debian / Ubuntu) исправил это.

2
ответ дан 2 December 2019 в 22:41

Я столкнулся с этим сообщением об ошибке и решил его, установив:

UsePAM yes

Это произошло только с учетными записями без пароля (например, root).

1
ответ дан 2 December 2019 в 22:41

Я действительно столкнулся с этой проблемой ... и это был наш старый добрый друг SELinux.

Запуск setenforce 0 доказывает, что это сработало, но это не хорошее решение. Однако, как только это помогло прояснить окончательное решение.

$ cd /etc/ssh
$ restorecon -Rv *

Повторное включение SELinux ( setenforce 1 ) ... и все хорошо.

2
ответ дан 2 December 2019 в 22:41

Я столкнулся с этой проблемой на Федоре. В конце концов я заметил:

root@wisdom:/etc/ssh# ll
total 268K
drwxr-xr-x.   2 root root     4.0K Jun 30 06:06 ./
drwxr-xr-x. 128 root root      12K Jun 30 05:15 ../
-rw-r--r--.   1 root root     237K Jun  8 23:30 moduli
-rw-r--r--.   1 root root     2.2K Jun  8 23:30 ssh_config
-rw-------.   1 root root     4.3K Jun 30 06:03 sshd_config
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_ecdsa_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_ecdsa_key.pub
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_ed25519_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_ed25519_key.pub
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_rsa_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_rsa_key.pub

Ключевые файлы нулевой длины! Я сгенерировал новые пары ключей и проблема была исправлена:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
16
ответ дан 2 December 2019 в 22:41

Для меня исправлено добавление этих строк do / etc / ssh / sshd_config:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192
-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exch
ange-sha1,diffie-hellman-group1-sha1

HostkeyAlgorithms +ssh-dss
0
ответ дан 2 December 2019 в 22:41

В моем случае это был чрезмерно-энтузиастический профиль аппармора.

В моем файле /var/log/auth.log я также получил следующее сообщение:

fatal: linux_audit_write_entry failed: Permission denied

Решилось запуском:

aa-complain /etc/apparmor.d/usr.sbin.sshd
0
ответ дан 2 December 2019 в 22:41

Я потратил на это 6 часов! Я перепробовал все решения, а также многие другие! но безрезультатно! затем очистил openssh-server и переустановил его, и он отлично работал, и я перенастроил все, что заняло около 15 минут! И я усвоил отличный урок!

Никогда не тратьте время на отладку чего-то, что вы можете вернуть к работе, просто сбросив его!

Нет никакой выгоды в том, чтобы иметь дело с каждым битом каждого файла конфигурации и отладочной информацией каждого приложения !

0
ответ дан 2 December 2019 в 22:41

Në skenarin tim ishin lejet e gabuara për çelësat privatë:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0444 for '/etc/ssh/ssh_host_rsa_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
key_load_private: bad permissions
Could not load host key: /etc/ssh/ssh_host_rsa_key
0
ответ дан 2 December 2019 в 22:41

Теги

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