o usuário chrooting causa a mensagem “conexão fechada” ao usar o sftp

3

Primeiro, sou um novato no Linux, por isso, não assuma muito conhecimento. Estou usando o CentOS 5.8 (final) e usando o OpenSSH versão 5.8p1.

Eu fiz um usuário playwithbits e estou tentando chroot deles para o diretório home/nginx/domains/playwithbits/public

Estou usando a seguinte instrução match no meu arquivo sshd_config :

Match group web-root-locked
         ChrootDirectory /home/nginx/domains/%u/public
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand /usr/libexec/openssh/sftp-server

# id playwithbits retorna: uid=504(playwithbits) gid=504(playwithbits) groups=504(playwithbits),507(web-root-locked)

Alterei o diretório pessoal do usuário para: home/nginx/domains/playwithbits/public

Agora, quando tento entrar com esse usuário, recebo instantaneamente a mensagem: connection closed

Alguém sabe o que estou fazendo errado?

Editar: Seguindo o conselho de @Dennis Williamson, conectei-me no modo de depuração (acho que ... corrija-me se estiver errado).

Eu fiz um pouco de progresso usando chmod para definir permissões recursivamente de todos os arquivos no diretamente para 700. Agora recebo as seguintes mensagens quando tento fazer logon (ainda a conexão recusada):

Connection from [My ip address] port 38737
debug1: Client protocol version 2.0; client software version OpenSSH_5.6
debug1: match: OpenSSH_5.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user playwithbits service ssh-connection method none
debug1: attempt 0 failures 0
debug1: user playwithbits matched group list web-root-locked at line 91
debug1: PAM: initializing for "playwithbits"
debug1: PAM: setting PAM_RHOST to [My host info]
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user playwithbits service ssh-connection method password
debug1: attempt 1 failures 0
debug1: PAM: password authentication accepted for playwithbits
debug1: do_pam_account: called
Accepted password for playwithbits from [My ip address] port 38737 ssh2
debug1: monitor_child_preauth: playwithbits has been authenticated by privileged process
debug1: SELinux support disabled
debug1: PAM: establishing credentials
User child is on pid 3942
debug1: PAM: establishing credentials
Changed root directory to "/home/nginx/domains/playwithbits/public"
debug1: permanently_set_uid: 504/504
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype [email protected] want_reply 0
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request subsystem reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req subsystem
subsystem request for sftp by user playwithbits
debug1: subsystem: cannot stat /usr/libexec/openssh/sftp-server: Permission denied
debug1: subsystem: exec() /usr/libexec/openssh/sftp-server
debug1: Forced command (config) '/usr/libexec/openssh/sftp-server'
debug1: session_new: session 0
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 3943
debug1: session_exit_message: session 0 channel 0 pid 3943
debug1: session_exit_message: release channel 0
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
debug1: session_close: session 0 pid 0
debug1: channel 0: free: server-session, nchannels 1
Received disconnect from [My ip address]: 11: disconnected by user
debug1: do_cleanup
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials
    
por George Reith 04.06.2012 / 16:09

2 respostas

7

Estes problemas são sempre mais fáceis quando depurados do lado do servidor. Eu recomendo iniciar um segundo servidor no modo de depuração com algo como /usr/sbin/sshd -p 2222 -d . Em seguida, você pode se conectar a partir de seu cliente com sftp -P 2222 user@remotehost e esperar que o servidor informe por que está desconectando. O mais provável é que exista um problema de permissões, o meu palpite é que você não está atendendo ao requisito de que o diretório pessoal seja de propriedade do root.

    
por 04.06.2012 / 16:17
0

Se os arquivos de inicialização gerarem algum texto, isso poderá causar problemas com ssh conexões e, presumivelmente, com sftp . Verifique se os arquivos profile ou bashrc em /etc ou $HOME não estão gerando nenhum texto.

    
por 04.06.2012 / 16:26