Как включить sshd в Fedora 11?

Я совершал глупую ошибку.

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

Это причина, по которой локальное SSH-соединение работало, но не удаленно. Я должен был бежать ifconfig раньше, чтобы проверить IP-адрес.

Для этого должно быть всего 2 шага:

• Включите sshd в качестве доверенной службы, используя system-config-firewall
• Запустите sshd как службу, используя service sshd start

На втором этапе убедитесь, что ключи были сгенерированы. SELinux его вообще не нужно трогать.

1 Отключите брандмауэр для хоста (только на время, достаточное, чтобы убедиться, что это не брандмауэр).

2 Откройте терминал, su в корневого пользователя и введите /etc/init.d/sshd start Это по крайней мере даст вам любые ошибки, которые вы можете увидеть. Надеюсь, это подтвердит начало

3 Включить брандмауэр Убедитесь, что брандмауэр не проблема, подключившись с удаленного хоста

Любые ошибки из этого, если вы опубликуете, мы все сможем помочь.

На шаге 2 вы можете заметить, что компьютер генерирует ваши ключи, что, возможно, не было сделано раньше. Это объяснило бы, почему раньше это не работало. Если он не создал ключи, это означает, что они были ранее сгенерированы, и все в порядке.

Включите SSH с помощью этой команды systemctl enable sshd.service

su -
systemctl enable sshd.service
systemctl start sshd.service

SELinux - это не проблема здесь. Не отключайте SELinux и не устанавливайте его в разрешающий режим. Для этого нет абсолютно никаких причин. Мой ноутбук работает под управлением F11 с начала апреля с SELinux в принудительном режиме без каких-либо проблем.

SELinux становится проблемой только тогда, когда вы вручную создали ключи и поместили их, например, в / etc / ssh, но, поскольку это не проблема, оставьте SELinux в покое.

Fedora не имеет очень причудливых правил hosts.deny, как, например, Arch, и по умолчанию не блокирует ssh в iptables.

Пожалуйста, опубликуйте вывод / var / log / secure и / var / log / messages примерно в то время, когда вы пытаетесь запустить sshd, и я посмотрю, смогу ли я вам помочь.

У тебя, скорее всего, есть Selinux Бег; Последние установки Fedora включают это по умолчанию с довольно ограниченным набором политик.

Вы также можете проверить свои файлы hosts.deny и hosts.allow в / etc. В некоторых дистрибутивах они по умолчанию настроены на блокировку всех подключений из внешних источников, но разрешают любые подключения с локального компьютера. Возможно, поэтому вы можете подключиться локально, но не из удаленной системы.

Если в hosts.deny есть строка «ALL: *» или, возможно, «ALL: PARANOID» и раскомментированная, то это будет отклонять все подключения из внешних источников, явно не разрешенных в файле hosts.allow. Это состояние по умолчанию в некоторых дистрибутивах, поскольку оно помогает заблокировать систему от постороннего вмешательства с самого начала. Если в файле нет ничего, кроме комментариев, проблема не в этом.

Предположим, что строка «ALL: PARANOID» присутствует в hosts.deny, и вы оставите ее в покое, чтобы включить ssh-соединения из определенного источника, вам нужно будет добавить строку «sshd:» в ваш файл hosts.allow. может быть конкретным IP-адресом, полным доменным именем или версией с подстановочными знаками (например, sshd: 192.168.0. * или * .mydomain.net). В этом файле обычно есть строка «ALL: 127.0.0.1», разрешающая любой тип подключения с локальной машины, поэтому ssh может работать с локальной машины, но не с внешней машины.

Некоторые подходы к отладке:

Вы проверили, что sshd действительно запущен. например ps aux|grep sshd и netstat -nltp|grep 22 (как корень)

Предполагая sshd мы хотим видеть сетевой трафик и то, что происходит на сервере sshd процесс и клиент ssh обработать:

1. Можете ли вы подключиться к хосту по ssh с loclhost?

2. Включите вход по ssh в / etc / ssh / sshd_config и проверьте журналы.

3. tcpdump -i any tcp dst port 22 and src host <ssh_client_ip/host> на хосте сервера

4. tcpdump -i any tcp dst port 22 and dst host <ssh_server_ip/host> на клиентском хосте

5. Прикреплять strace -F -p <listening sshd process pid> к слушающему экземпляру sshd на сервере и посмотрите, что происходит.

6. ssh на сервер, запустив клиента из strace, т.е. strace ssh <user>@<host> и посмотреть, что происходит

Также остановите службу sshd на сервере и запустите демон sshd из командной строки в режиме отладки. например.:

service sshd stop;pkill sshd

sshd -d3

или

service sshd stop;pkill sshd

strace sshd -d3.

В -d3 запускает sshd с высоким уровнем отладки и останавливает его отсоединение / разветвление. Т.е. это будет единственный запущенный экземпляр, и вывод должен идти на ваш терминал

Вы также можете использовать -oLogLevel=DEBUG в командной строке клиента, чтобы сделать его более шумным.

Если вы используете ключи для аутентификации, проверьте каталог, в котором ваши ключи находятся в e, g, ~/.ssh есть достаточно частная завивка. например chown -R ${USERID}. .sshd; chmod -R 700 .sshd.

Чтобы убедиться, что он настроен и работает:

chkconfig --list sshd
service sshd status

Как только я узнал, что он запущен, я проверил, будет ли он запускаться во время загрузки. Затем, чтобы заставить его работать, я добавил следующее правило в / etc / sysconfig / iptables:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Затем я перезапустил iptables, используя:

service iptables restart

Я также отключил SELINUX, отредактировав /etc/selinux/config и установка:

SELINUX=disabled

Возможно, я перезагрузился, чтобы убедиться. Это шаги, предпринятые для получения удаленных входов по SSH.

ПРИМЕЧАНИЕ: я настроил sshd.conf НЕ разрешать вход в систему с правами root. Дважды проверьте свой текущий sshd.conf файл для этого параметра, если вы пытаетесь войти в систему как пользователь root. В целях безопасности не рекомендуется разрешать пользователю root удаленно входить в систему.