Por que o daemon sshd falharia com uma conexão que o / usr / sbin / sshd permitia manualmente?

Question

O objetivo é configurar o FreeNX. Seguindo o conselho de outro serverfault user Eu pude testar várias configurações de ssh e nxsetup conexões para o servidor sshd como daemon ou instância inicializada manualmente de /usr/sbin/sshd .

A versão do daemon não aceitará a conexão do nxsetup, mas a instância manual /usr/sbin/sshd será.

Os passos:

1. Inicie o ssh-agent eval $(ssh-agent) e adicione a chave raiz ssh-add

2. Pare o daemon sshd,

3. Inicie a instância manual com:

   # /usr/sbin/sshd -d -p 22 -f /path/to/test/sshd_config_nx
   

4. O comando com o qual estou tendo problemas é:

   # nxsetup --install --clean --purge
   

5. Sucesso! No entanto, pule 2, 3 e a conexão falhe

A configuração do daemon sshd e dos arquivos de configuração / usr / sbin / sshd:

/etc/ssh/sshd_config é, obviamente, o diretório de configuração padrão do daemon. Este arquivo e minha configuração de teste, ~/sshd_config_nx , (tornaram-se) são exatamente os mesmos (diff).

Os testes bem-sucedidos de ssh incluem:

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

Permissões

Eu li um monte de posts sobre problemas de autenticação ssh / sshd envolvendo permissões. Meu usuário root tem estas permissões: /root/.ssh é 700 e /root/.ssh/* é 600. O local padrão do nxserver para authorized_keys2 é /var/lib/nxserver/home/.ssh/ . Eu apliquei as mesmas permissões aqui. A única diferença entre / root e / var é que o último é de propriedade nx: root. Por esta razão eu testei as permissões do mesmo para o proprietário e o grupo com o mundo ainda 0. Isso não fez nenhuma diferença, e isso causou um erro no ssh-add. Então eu os troquei de volta para 700 e 600. Eu não ouvi que as permissões de configuração são importantes, mas eu fiz as duas do mesmo jeito e como estou executando esses comandos como root, o usuário: grooup também é o mesmo.

Por que o daemon sshd falharia em uma conexão que o comando / usr / sbin / sshd permitia manualmente?

// EDIT : Eu tentei mais algumas coisas no caso de ser apenas idiota:

• adicione ssh-agent em etapas.

• Certifiquei-me de que as alterações feitas em ~/.ssh e /var/lib/nxserver/home/.ssh permissões foram seguidas pelo aviso de outro post com um problema semelhante com daemon e manualmente sshd iniciado : #restorecon -r -vv /root/.ssh

• O servidor possui o openssh-5.3p1-84.1.el6.i686, por esse motivo o authorized_key arquivo não é o que você poderia esperar. O FreeNX quer o authorized_keys2 localizado no diretório / var. É importante notar aqui que o ssh está funcionando. O teste sshd_config_nx usa este local / var sempre, e eu alternar a linha no / etc / ssh / sshd_config quando eu tento a conexão nxsetup através do daemon (para se adequar às instruções do nxsetup).

• adicionou pastebin de / etc / ssh / sshd_config

• Os diretórios mencionados acima:

  [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
  

Answer 1

Você tem selinux ativado. Para conexões com falha, você deve ver as entradas em /var/log/audit/audit.log . Você tem duas opções:

• Desativar selinux . Vá em frente, todos os seus amigos estão fazendo isso.
• Corrija sua configuração de selinux . Isso pode ser tão simples quanto executar fixfiles com os argumentos apropriados para reetiquetar seu sistema de arquivos ou pode exigir explicitamente a configuração do contexto selinux de arquivos ou diretórios.

Se você optar pela segunda solução - possivelmente mais correta, mas mais trabalhosa -, talvez queira abrir uma segunda pergunta contendo as entradas relevantes de seu audit.log .

Você pode experimentar a primeira solução executando:

# setenforce 0

Isso colocará selinux no modo permissivo, mas não será persistente durante a reinicialização. Desativar persistentemente selinux , editar /etc/selinux/config e definir:

SELINUX=disabled

Ou:

SELINUX=permissive

A última configuração deixará selinux ativado, mas no modo permissivo, por isso, registrará violações em audit.log , mas não