Почему демон sshd не может установить соединение, которое запускается вручную /usr/sbin/sshd?

Цель состоит в том, чтобы настроить FreeNX. Следуя совету другого пользователя serverfault, я смог протестировать различные конфигурации ssh а также nxsetup подключения к серверу sshd в качестве демона или запускаемого вручную экземпляра /usr/sbin/sshd,

Версия демона не будет принимать соединение от nxsetup, но вручную /usr/sbin/sshd будут.

Шаги:

  1. Запустить ssh-agent eval $(ssh-agent) и добавить корневой ключ ssh-add

  2. Остановите демон sshd,

  3. Запустите ручной экземпляр с помощью:

    # /usr/sbin/sshd -d -p 22 -f /path/to/test/sshd_config_nx
    
  4. У меня проблемы с командой:

    # nxsetup --install --clean --purge
    
  5. Успех! Тем не менее, пропустить 2, 3 и соединение не удается

Настройка демона sshd и файлов конфигурации руководства /usr/sbin/sshd:

/etc/ssh/sshd_config конечно, каталог конфигурации демона по умолчанию. И этот файл, и мой тестовый конфиг, ~/sshd_config_nx, (стали) точно так же (diff).

Успешные тесты ssh включают в себя:

from client over LAN to:
    - sshd server daemon
    - manual sshd server
from ssh with loopback (127.0.0.1) to:
    - sshd server daemon
    - manual sshd server

права доступа

Я прочитал много сообщений о проблемах аутентификации ssh/sshd, связанных с разрешениями. Мой пользователь root имеет следующие разрешения: /root/.ssh это 700 и /root/.ssh/* это 600. Расположение nxserver по умолчанию для authorized_keys2: /var/lib/nxserver/home/.ssh/, Я применил те же разрешения здесь. Единственная разница между /root и /var заключается в том, что последний принадлежит nx:root. По этой причине я протестировал разрешения одинаково как для владельца, так и для группы, где мир все еще равен 0. Это не имело никакого значения, и это вызвало ошибку ssh-add. Поэтому я изменил их обратно на 700 и 600. Я не слышал, чтобы разрешения для конфигурации имели значение, но я сделал их одинаковыми, и, поскольку я выполняю эти команды от имени пользователя root, user:grooup также не изменился.

Почему демон sshd не может установить соединение, которое запускается вручную /usr/sbin/sshd?

// РЕДАКТИРОВАТЬ: Я попробовал еще несколько вещей, если я просто глуп:

  • добавьте ssh-agent по шагам.

  • Я удостоверился, что любые изменения, которые я сделал в ~/.ssh а также /var/lib/nxserver/home/.ssh за разрешениями последовал совет из другого поста с похожей проблемой с демоном и вручную запустил sshd: #restorecon -r -vv /root/.ssh

  • На сервере установлен openssh-5.3p1-84.1.el6.i686, поэтому файл author_key не соответствует вашим ожиданиям. FreeNX хочет, чтобы author_keys2 находился в каталоге /var. Здесь важно отметить, что ssh работает. Тест sshd_config_nx всегда использует это местоположение /var, и я переключаю строку в / etc / ssh/sshd_config, когда пытаюсь установить соединение nxsetup через демон (в соответствии с инструкциями nxsetup).

  • добавлена ​​вставка из / etc / ssh/sshd_config

  • Каталоги, упомянутые выше:

    [root@mrwizard ~]# ls ~/.ssh
    drwx------.  2 root root 4096 Oct  6 17:47 .
    dr-xr-x---. 47 root root 4096 Oct  7 18:58 ..
    -rw-------.  1 root root 2761 Oct  5 18:50 authorized_keys
    -rw-------.  1 root root 1865 Oct  6 15:54 authorized_keys2
    -rw-------.  1 root root 1679 Oct  6 15:52 authorized_keys2.new
    -rw-------.  1 root root 1743 Oct  5 18:38 id_rsa
    -rw-------.  1 root root  401 Oct  5 18:38 id_rsa.pub
    -rw-------.  1 root root  391 Oct  6 17:47 known_hosts 
    
    [root@mrwizard ~]# ls -al /var/lib/nxserver/home/.ssh/
    drwx------. 2 nx root 4096 Oct 7 18:38 . 
    drwx------. 5 nx root 4096 Oct  7 18:38 ..
    -rw-------. 1 nx root  669 Oct  7 18:38 authorized_keys2
    -rw-------. 1 nx root  668 Oct  7 18:38 client.id_dsa.key
    -rw-r--r--. 1 nx root  392 Oct  7 18:38 known_hosts 
    
    [root@mrwizard ~]# ls -al /etc/ssh/
    drwxr-xr-x.   2 root root   4096 Oct  6 18:47 . 
    drwxr-xr-x. 135 root root  12288 Oct  7 18:38 ..
    -rw-------.   1 root root 125811 Feb 21  2013 moduli
    -rw-r--r--.   1 root root   2061 Sep 22 14:32 ssh_config
    -rw-------.   1 root root   4492 Oct  6 18:47 sshd_config
    -rw-------.   1 root root    668 Oct  5 16:53 ssh_host_dsa_key
    -rw-r--r--.   1 root root    590 Oct  5 16:53 ssh_host_dsa_key.pub
    -rw-------.   1 root root    963 Oct  5 16:53 ssh_host_key
    -rw-r--r--.   1 root root    627 Oct  5 16:53 ssh_host_key.pub
    -rw-------.   1 root root   1671 Oct  5 16:53 ssh_host_rsa_key
    -rw-r--r--.   1 root root    382 Oct  5 16:53 ssh_host_rsa_key.pub
    

1 ответ

Решение

У тебя есть selinux включен. Для неудачных подключений вы должны увидеть записи в /var/log/audit/audit.log, У вас есть два варианта:

  • запрещать selinux, Давай, все твои друзья делают это.
  • Исправь свой selinux конфигурации. Это может быть так же просто, как бег fixfiles с соответствующими аргументами для перемаркировки вашей файловой системы, или это может потребовать явной установки selinux контекст файлов или каталогов.

Если вы выберете второе - возможно, более правильное, но более трудоемкое - решение, вы можете открыть второй вопрос, содержащий соответствующие записи из вашего audit.log,

Вы можете попробовать первое решение, запустив:

# setenforce 0

Это положит selinux в разрешающий режим, но не сохраняется после перезагрузки. Постоянно отключать selinux, редактировать /etc/selinux/config и установить:

SELINUX=disabled

Или же:

SELINUX=permissive

Последний параметр оставит selinux включен, но в разрешающем режиме, поэтому он будет регистрировать нарушения в audit.log но не буду

Другие вопросы по тегам