Espero que não seja um idiota, mas não consigo encontrar uma resposta para esta... Encontrei isto, que superficialmente parece ser o mesmo, mas é muito antigo e a única resposta nele não responde à pergunta real: Defina os usuários como chrooted para sftp, mas permita que o usuário faça login no SSH
Configurei com êxito um ambiente ChrootDirectory funcional via sftp para usuários do grupo 'sftp_users'. Funciona bem, com todas as permissões adequadas e tal, restringindo o acesso apenas ao sftp, e eles podem rw em seus subdiretórios dentro do ChrootDirectory. Isso é ótimo para usuários não privilegiados, proibindo o acesso ssh e permitindo apenas rw dentro de suas subpastas dentro do ChrootDirectory.
Gostaria de ter usuários um pouco mais privilegiados que ainda consigam usar o ssh normalmente, porém ao logar via sftp terá então o ambiente ChrootDirectory. Isso é menos um problema de segurança, pois eles são considerados privilegiados e obviamente podem navegar pelo sistema de arquivos em ssh com suas permissões normais de usuário. O problema é que não estou vendo uma maneira de fazer o Chroot deles quando eles fazem login no sftp sem impedir o login do ssh. Isso é mais para padronização e conveniência do que qualquer outra coisa, então, quando eles fazem o sftp, eles simplesmente chegam ao local do Chroot como os usuários somente do sftp.
Achei que isso funcionaria se eu deixasse o shell como padrão (não /bin/false ou nologin). Infelizmente, quando eles estão no grupo sftp_only, isso não permitirá que eles façam ssh, apenas sftp. Existe uma solução alternativa para isso, além de ter duas contas separadas - uma adicionada a 'sftp_users' e outra que não esteja nesse grupo? Até agora, tudo que consegui encontrar foi documentação sobre como restringir o sftp Chroot e, simultaneamente, proibir o ssh se eles estiverem nesse grupo.
O usuário de exemplo é 'teste'. 'test' está no grupo sftp_users e pode, portanto, fazer login via sftp e ser chrooted em sua pasta especificada ('/sftp/test') e ler ou gravar em sua pasta pessoal montada em '/sftp/test/home' . Tudo isso funciona. Mas mesmo que seu shell ainda esteja configurado em/etc/passwd para/bin/bash, 'test' não pode fazer login via ssh se adicionado ao grupo sftp_users. Remova a associação nesse grupo e ele poderá fazer as duas coisas, mas não o Chrooted no sftp.
Os usuários que não estão no grupo 'sftp_users' ainda podem fazer login via ssh ou sftp, mas não são chrooted em sftp.
Existe uma maneira de combinar qual protocolo é usado e/ou talvez definir uma correspondência adicional para um grupo diferente? Só estou procurando o chroot quando eles fazem login via sftp. O não-chroot via ssh é adequado para esses usuários.
A seguir está meu sshd_config:
Port XXXX
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
PubkeyAuthentication yes
IgnoreRhosts yes
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes
ClientAliveCountMax 10
ClientAliveInterval 3600
TCPKeepAlive no
#Banner /etc/issue.net
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server -u 0027
UsePAM yes
PasswordAuthentication yes
Match Group sftp_users
ChrootDirectory /sftp/%u
ForceCommand internal-sftp -u 0027
X11Forwarding no
AllowTcpForwarding no
PasswordAuthentication yes
Responder1
OpenSSH não oferece suporte à substituição de palavras-chave globais com base no comando enviado. Você deve diferenciar alguns critérios (combinação de) que o OpenSSH oferece para a Matchdeclaração.
Os critérios disponíveis são Usuário, Grupo, Host, LocalAddress, LocalPort, RDomain e Endereço (com RDomain representando o rdomain(4) no qual a conexão foi recebida)
-- man 5 sshd_config
Uma escolha comum é oferecer serviços intencionalmente restritos em IPs alternativos alcançados através de domínios alternativos, como snapshot.backup.examplee sftp.backup.example.
Os comentários sobrepergunta vinculadano entanto, esclareça o problema claramente.
Se você acha quequereracesso sftp chroot para usuários privilegiados, você provavelmente está confundindo diferentespapéisem idênticoUsuários, e isso é um convite a riscos de segurança.
Na maioria das vezes, as preocupações de auditoria e separação de privilégios são melhor atendidas porusando um usuário diferentepor tudo o que fez você considerar configurar configurações de chroot, mesmo para usuários que não estão limitados por isso. Se houver duas tarefas diferentes, mesmo que executadas pelo mesmopessoa, e isso é feito com mais segurança se for intencionalmente restrito, então configure um novo usuário do sistema (por exemplo, tenha um usuário persone person-taskcompartilhe a maioria das restrições e métodos de autenticação, e restrinja apenas um deles no ssh).
Responder2
Também fiquei confuso com esse problema, quando configurei o chroot sftp para usuários, eles não conseguem fazer login por ssh. Meu cenário é um pouco diferente, preciso fornecer um ambiente shell limitado para os usuários, enquanto os usuários ainda precisam de sftp & scp para acessar seu diretório inicial para RW, bem como um diretório público designado, por exemplo, /home/public para RDONLY.
Primeiramente desenvolvi um shell encarcerado, gostaria que esse shell pudesse cooperar com o openssh internal-sftp para atender às minhas necessidades. Então descobri que falhou porque o openssh não permitirá o login ssh dos usuários junto com o chroot internal-sftp ativado.
Então eu tive que modificar o shell preso para suportar o sftp e o scp presos em casa. É um pouco complicado usar syscalls ptrace para implementar o sftp preso. Se esta informação for útil para você, você pode consultar https://github.com/diggerwoo/jsh.