É possível conceder aos usuários acesso sftp sem acesso ao shell? Se sim, como é implementado?

29

Eu tenho uma variedade de usuários que precisam apenas fazer upload de arquivos para seus homedirs definidos. Acho que o sftp seria suficiente, mas não quero que eles façam login via shell. Então é possível? Minha plataforma é centos 7, as homedirs do usuário são armazenadas digamos / personal / $ user

Eu criei um usuário com essas configurações

useradd -m -d /personal/user1 -s /sbin/nologin

atribuiu ao usuário uma senha, quando uso o sftp para efetuar login na máquina, ele diz que não pode se conectar.

sftp nologin Sollosa
fonte
scponly github.com/scponly/scponly/wiki chroot opcional
user2497
1
duplicado de serverfault.com/questions/354615/allow-sftp-but-disallow-ssh
Tom

Respostas:

11

Edite seu /etc/ssh/sshd_configpara conter:

Match User [SFTP user]
ForceCommand internal-sftp

Reinicie sshd. Se você tiver vários usuários, coloque todos na linha de usuário correspondente, separados por vírgulas, como segue:

Match User User1,User2,User3

A chave para configurar sftppara não permitir acesso ao shell é limitar os usuários por meio da ForceCommand opção

kemotep
fonte
Ok, eu segui todas as etapas, mas ela não
entrou.
2
@Sollosa Experimente Match User [SFTP user] ForceCommand internal-sftpapenas, sem fazer chroot.
Martin Prikryl 27/02
@MartinPrikryl funcionou Martin, obrigado, acabei de remover o parâmetro chrootdirectory & viola
Sollosa 27/02
1
Além disso, você pode chrootos usuários para que eles não possam navegar para cima e para fora da sua "prisão" definida
ivanivan
37

Gosto da seguinte configuração para gerenciar o acesso SSH, usado no trabalho para gerenciar um grupo de usuários em uma pequena frota de servidores. Segurança e facilidade de gerenciamento estão no topo da lista de minhas prioridades.

Seus principais recursos são o gerenciamento fácil dos direitos SSH por meio da associação ao grupo Unix, com permissões bem definidas e segurança por padrão.

Configurando

Instale o software (opcional, mas útil):

yum install members   # or apt install members

Adicione grupos:

addgroup --system allowssh
addgroup --system sftponly

Em /etc/ssh/sshd_config, verifique se as configurações a seguir são No:

PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no

E no final de /etc/ssh/sshd_config, adicione estas duas estrofes:

Match Group allowssh
    PubkeyAuthentication yes

Match Group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

(não esqueça de reiniciar o SSH depois de editar o arquivo)

Explicação

Então, o que tudo isso faz?

  • Desativa sempre logins raiz, como uma medida de segurança extra.
  • Desativa sempre logins baseados em senha (senhas fracas são um grande risco para servidores executando o sshd).
  • Permite apenas o login (pubkey) para usuários do allowsshgrupo.
  • Os usuários do sftponlygrupo não podem obter um shell sobre SSH, apenas SFTP.

O gerenciamento de quem tem acesso é feito simplesmente gerenciando a associação ao grupo (essas alterações entram em vigor imediatamente, não é necessário reiniciar o SSH):

# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#

Observe que os usuários do sftp precisam ser membros de ambos sftponly(para garantir que não recebam um shell) e de allowssh(para permitir o login em primeiro lugar).

Outras informações

  1. Observe que essa configuração não permite logins de senhas ; todas as contas precisam usar autenticação de chave pública. Esta é provavelmente a maior vitória em segurança que você pode obter com o SSH, então eu argumento que vale a pena o esforço, mesmo que você tenha que começar agora.

    Se você realmente não quer isso, adicione também PasswordAuthentication yesà Match Group allowsshestrofe. Isso permitirá autenticação de pubkey e senha para os allowsshusuários.

  2. Essa configuração limita qualquer sftponlyusuário ao diretório inicial. Se você não quiser isso, remova a ChrootDirectory %hdiretiva.

    Se você não quer que o chrooting ao trabalho, é importante que o diretório home do usuário (e qualquer diretório acima dela) é de propriedade root:roote não gravável por grupo / outros. Não há problema em subdiretórios do diretório inicial serem de propriedade do usuário e / ou graváveis.

    Sim, o diretório inicial do usuário deve pertencer à raiz e ser gravável para o usuário. Infelizmente, existem boas razões para essa limitação. Dependendo da sua situação, ChrootDirectory /homepode ser uma boa alternativa.

  3. Definir o shell dos sftponlyusuários como /sbin/nologinnão é necessário nem prejudicial para esta solução, porque o SSH ForceCommand internal-sftpsubstitui o shell do usuário.

    O uso /sbin/nologinpode ser útil para impedir o logon de outras maneiras (console físico, samba etc.).

  4. Essa configuração não permite rootlogins diretos pelo SSH; isso forma uma camada extra de segurança. Se você realmente não precisa logins raiz diretos, alterar a PermitRootLogindirectiva. Considere configurá-lo para forced-commands-only, prohibit-passworde (como último recurso) yes.

  5. Para obter pontos de bônus, verifique quem pode sutorcer; adicionar um grupo sistema chamado wheel, e adicionar / ativar auth required pam_wheel.sono /etc/pam.d/su.

marcelm
fonte
2
Essa deve ser a resposta aceita. Ele fornece a solução e detalha o raciocínio por trás de cada etapa.
kemotep 27/02
1
Essa é uma ótima resposta, com ótimos conselhos adicionais de segurança, mas eu me preocupo com os usuários cujos sistemas dependem de logins de senha, root, etc. Claro que isso não é bom, mas talvez leve as alterações relacionadas à melhoria geral de segurança para seus própria seção para que uma resposta à pergunta com o mínimo de alterações esteja disponível?
Josh Rumbut 27/02
1
@JoshRumbut Eu não queria reescrever a resposta para suas observações (muito corretas), em parte porque realmente está apenas mostrando o My Way ™, e em parte na esperança de que possa ser uma espécie de configuração canônica de SSH segura por padrão exemplo que muitas pessoas acham útil. Como compromisso, tentei torná-lo muito mais claro que logins raiz e auth senha não vai funcionar, e eu incluído instruções sobre como reativá-los :)
marcelm
1
Boa resposta, no entanto, as maiores deficiências das outras respostas não estavam levando em consideração os aspectos de segurança, principalmente o chroot. +1
Rui F Ribeiro
1
Chroot não funcionará para um% h genérico. Surpreendentemente, você é obrigado a chown root:rootechmod og-w
kubanczyk 27/02
1

basta alterar o shell padrão para / sbin / nologin. Assumindo a maioria das variedades de Linux:

# usermod -s /sbin/nologin username
Kefka
fonte
Eu tentei, mas o usuário não pode fazer login via sftp, não sei por quê. Estou usando centos btw.
Sollosa 27/02
@Sollosa Provavelmente, um problema de permissão no seu sftp chroot ou sshd_config tem um problema. Você deve atualizar sua pergunta para incluir as permissões do diretório chroot e do seu sshd_config com qualquer informação sensível redigida.
Kefka 27/02
Acredito (embora não possa testá-lo agora) que isso permite o SFTP apenas se houver também Subsystem sftp internal-sftp) (ou talvez ForceCommand internal-sftp). Se houver algo comum Subsystem sftp /path/to/sftp-server, nologinimpedirá até o SFTP.
Martin Prikryl 27/02
@MartinPrikryl Entendi mal a pergunta original não editada de como desabilitar o acesso ao shell para usuários em um servidor sftp funcional. Eu estava acordado por cerca de dez minutos na época, então não estava tão lúcido quanto poderia ter me sentido. Embora eu não soubesse que o servidor sftp exige que um usuário tenha um shell válido para funcionar - isso parece potencialmente perigoso. Eu só uso o internal-sftp apenas por hábito, porque é assim que sempre faço.
Kefka 4/03
Veja minha resposta ao OpenSSH: Diferença entre o sftp interno e o sftp-server (particularmente a seção no final)
Martin Prikryl
0

você pode usar o tftp. qualquer coisa sobre ssh exigirá alguma autenticação (chave | passe).

Embora o tftp possa ser protegido, pode valer a pena revisitar a decisão de fornecer acesso a qualquer coisa sem autenticação.

http://manpages.ubuntu.com/manpages/bionic/man1/tftp.1.html

Justin
fonte
2
Eu acho que o OP queria que os usuários (que provavelmente possuem nomes de usuário e senhas) não pudessem usar um cliente SSH comum para se conectar ao servidor e executar comandos arbitrários, mas esses mesmos usuários possam fazer upload de arquivos via SFTP.
John_ReinstateMonica