Ativar acesso ao shell SSH, mas desativar o acesso SFTP

21

Procurei uma resposta viável para essa pergunta e a maioria das respostas inclui conselhos sobre por que não fazê-lo. No entanto, aqui está o cenário e o que é necessário:

Eu tenho um aplicativo de console e, no perfil de cada usuário, existe um comando de inicialização para o aplicativo e, diretamente após o comando que o inicia, existe um comando "exit", que os desconecta do sistema. Eu só quero que eles possam acessar este aplicativo de console através da interface fornecida por ele. Na inicialização, o aplicativo apresenta ao usuário uma lista de clientes que podem ser acessados pelo aplicativo, com cada cliente tendo seu próprio diretório de dados. Os usuários têm acesso concedido apenas aos clientes aos quais precisam acessar.

Agora, aqui está o problema: se eu der aos usuários acesso SSH, eles também poderão fazer login usando um cliente SFTP, que lhes dará acesso direto aos diretórios de dados do aplicativo, o que é MUITO indesejável, pois isso também fornecerá eles acessam os diretórios de dados aos quais eles não devem ter acesso.

Isso era uma coisa tão simples de se fazer ao usar uma combinação de telnet / FTP, mas agora que desejo dar aos usuários acesso de qualquer lugar da Internet, não consegui encontrar uma maneira de excluí-los do SFTP, enquanto ainda permitindo que eles acessem o shell onde eles podem executar o aplicativo.

— sosaisapunk
fonte

8

Esqueço os detalhes, mas acho que o SSH permite restringir os usuários a executar um único comando quando eles efetuam login. Eles não obtêm acesso completo ao shell se você configurar isso. Pode ser útil para o seu caso de uso. (Afinal, é possível emular o acesso SFTP usando SSHFS Apenas desativação SFTP não vai parar um usuário moderadamente determinado de chegar a qualquer arquivo para que a sua conta de usuário tem acesso..)

— David Z

3

Além disso, você pode considerar "fazer um chroot" de seus usuários. e para acesso a dados de reposição, ele se parece com um problema de design

— Dennis Nolte

2

Usar .profilepara isso soa como a solução errada. Acredito que configurar o usuário com um shell alternativo faria muito mais sentido.

— kasperd

3

Não tente usar o .profiletruque para restringir o acesso, pois é trivial ignorar. (veja minha resposta para detalhes) #

— Aleksi Torhamo

22

Editar:

Caso isso não seja óbvio, a resposta a seguir não pretende ser um método seguro de impedir que o SFTP seja usado por qualquer pessoa com acesso ao servidor. É apenas uma resposta que explica como desativá-lo da visibilidade externa. Para uma discussão sobre segurança no nível do usuário, consulte as respostas de @cpast e @Aleksi Torhamo. Se a segurança é seu foco, esta resposta não é a correta. Se o seu foco é a simples visibilidade do serviço, então esta é sua resposta.

Agora continuamos com a resposta original:

Comente o suporte ao sftp no sshd_config (e, é claro, reinicie sshd):

#Subsystem sftp /usr/lib/openssh/sftp-server

— Wesley
fonte

1

Às vezes a linha pode serSubsystem sftp internal-sftp

— Kondybas

1

Eu tenho Subsystem sftp /usr/libexec/sftp-server Mas isso fez o truque. Muito obrigado

— sosaisapunk

16

Isso não parece plausível. Se você pode executar comandos arbitrários no servidor, pode executar o programa do lado do servidor sftp. Mesmo se não estiver instalado, você poderá reimplementá-lo como um comando shell longo e fazer com que o cliente sftp envie esse comando em vez de sftp. Esse método pode tornar menos conveniente o uso do sftp, mas não há como impedir que um usuário que possa executar comandos arbitrários use esses comandos para fazer transferências de arquivos.

— R ..

1

@sosaisapunk Isso não é verdade. Os usuários podem executar o comando que quiserem ssh user@host command, pois .profilenão serão executados se você fizer isso e, portanto, seu aplicativo não será iniciado. Eles podem obter acesso total ao shell simplesmente dizendo ssh -t user@host bash. Apenas tente e você verá. O subsistema é apenas um alias de comando; se eles pudessem usar o sftp antes, ainda poderão usá-lo - e qualquer outro comando que desejarem. Leia minha resposta abaixo.

— Aleksi Torhamo

1

@sosaisapunk: Não, o ponto é que você pode fazer isso com o ssh, mas não com .profile, pois não se destina à segurança e é facilmente ignorado. Na minha resposta, listei três métodos diferentes de fazê-lo com o ssh. Em resumo, basta mover a chamada do seu aplicativo de .profilepara um script de shell e 1) definir o script de shell como o shell do usuário 2) definir o script de shell como (correspondido corretamente) ForceCommandem sshd_config3) alternar para autenticação de chave pública e definir o shell script como commandem .ssh/authorized_keys. (Além disso, você deve usar @ nome para que as pessoas ser notificado das observações)

— Aleksi Torhamo

28

Como outros já mencionaram, a desativação sftpnão é nem de longe suficiente - um usuário com sshacesso irrestrito pode visualizar qualquer arquivo que sua conta tenha permissão para visualizar, pode modificar qualquer coisa que tenha permissão para modificar e pode facilmente baixar qualquer coisa que possa ler por conta própria máquina. A única maneira de impedi-los de fazer isso é restringir o acesso deles. Também não é ideal confiar .profilepara restringir os usuários, pois não é para isso (editar: Como Aleksi menciona em sua resposta, é de fato trivial ignorar .profile; o importante .profileé que é por conveniência, não por segurança, por isso não é para restringir o usuário.Use itens projetados para segurança, como os itens abaixo, para fornecer segurança).

Há duas maneiras básicas de fazer isso: você pode restringi-las por meio de permissões de arquivo ou forçá-las a executar apenas seu aplicativo de console. A segunda maneira é melhor: atribua usuários que devem ser restritos ao aplicativo do console a um grupo (por exemplo customers); em seguida, sshd_configadicione as seguintes linhas:

Match Group customers
ForceCommand /path/to/app

O que isso faz é permitir que todas as conexões dos usuários desse grupo abram o aplicativo do console; eles não podem iniciar mais nada, incluindo a sftpferramenta de servidor. Isso também os impede de fazer qualquer outra coisa com o sistema e, ao contrário .profile, o faz usando o próprio servidor SSH ( .profilerestringe-os no shell, ForceCommandtambém impede que outras coisas que não envolvam iniciar um shell). Também .profile, diferentemente , isso é projetado como uma coisa de segurança; foi feito especificamente para resistir a um usuário mal-intencionado que evita isso.

A alternativa (provavelmente inferior) envolveria a criação de um novo usuário para executar o aplicativo do console. Você restringiria os diretórios de dados a esse usuário, configuraria o aplicativo de console pertencente a esse usuário e u+so programa. Essa é a parte setuid; isso significa que alguém que executa o programa do console faz isso com as permissões do proprietário do programa. Dessa forma, o próprio usuário não tem acesso aos diretórios, apenas o obtém através do programa. No entanto, você provavelmente deve apenas usar ForceCommand, pois isso restringe todo o acesso a "basta executar este programa".

— cpast
fonte

4

Gostaria de acrescentar que ForceCommandnão impede o encaminhamento de porta SSH.

— nyuszika7h

1

Na verdade, confiar .profileé mais do que "não ideal"; é facilmente ignorado (veja minha resposta para obter detalhes) e, portanto, não oferece proteção alguma, apenas uma falsa sensação de segurança.

— Aleksi Torhamo

@AleksiTorhamo Ah. Eu suspeitava que você pudesse ignorá-lo, mas não sabia ao certo como (geralmente suspeito que coisas que não são destinadas à segurança são ignoráveis). Obrigado pelos detalhes de como!

— cpast

15

Não tente fazer isso com isso, .profileporque ele não oferece segurança alguma e restringe exatamente nada!

Não importa o que você colocar em .profile, desde que você pode ignorá-lo, basta dar um comando para executar na linha de comando ssh, como este: ssh user@host command. Você ainda pode obter acesso normal ao shell fazendo isso ssh -t user@host bash.

Desabilitar o subsistema sftp, como mencionado em outra resposta, não ajuda em nada. Os subsistemas são essencialmente apenas aliases de comandos, e você ainda pode usar o sftp normalmente fazendo isso sftp -s /path/to/sftp-executable user@host.

Como cpast e alguns comentaristas disseram, você deve usar os mecanismos adequados para restringir o acesso. Isso é,

Use ForceCommandemsshd_config
Use login sem senha e command="..."em.ssh/authorized_keys
Altere o shell do usuário para algo que restrinja o que o usuário pode fazer

Notas:

command="..." aplica-se apenas a uma chave, por isso não restringe o login ssh para o usuário usando uma senha ou outra chave
Você também pode restringir o encaminhamento de porta, etc. (encaminhamento de porta, encaminhamento x11, encaminhamento de agente e alocação de pty são os que eu já ouvi falar)
- AllowTcpForwarding etc. em sshd_config
- no-port-forwarding etc. em .ssh/authorized_keys
Se você tiver outros daemons (como FTP) em execução, verifique se eles não permitem a entrada do usuário (alguns daemons tomam essa decisão com base no shell do usuário; portanto, se você alterar isso, verifique novamente)
Você pode alterar o shell do usuário para um script que faça o que você deseja; ou é executado sem argumentos ou comoscript -c 'command-the-user-wanted-to-run'
Ambos ForceCommande command="..."executam o comando através do shell do usuário, para que não funcionem se o shell do usuário estiver definido como, por exemplo. /bin/falseou/sbin/nologin

Isenção de responsabilidade: eu não sou especialista no assunto de forma alguma, por isso, enquanto posso dizer que a .profilecoisa não é segura, não posso prometer que não há "pegadinha" com os outros métodos que não conheço sobre. Eles são seguros até onde eu sei, mas eu não seria a primeira pessoa a estar errada na internet.

— Aleksi Torhamo
fonte

1

Parece que pelo menos o ForceCommandlogin forçado e sem senha com command=in authorized_keys, apesar de já ter sido ignorado antes, é devido a um erro no servidor: ele se destina a ser seguro contra um usuário mal-intencionado, e um usuário que o ignora conta como uma séria vulnerabilidade no servidor SSH (e, portanto, uma correção prioritária). Como você aponta, .profileé ignorável por design: como não é considerado um recurso de segurança, um usuário que o ignora está perfeitamente bem do ponto de vista do desenvolvedor de shell.

— cpast

1

@ cpast: Sim, eu estava pensando na existência de mais recursos, como encaminhamento de porta. Quero dizer, se você não sabia que o ssh permite o encaminhamento de portas e apenas usava ForceCommandpara restringir o acesso, e tinha um daemon que apenas escuta conexões localmente e não executa autenticação, o usuário do ssh ainda pode acessar o daemon. Os recursos que listei são os que, por exemplo. As soluções de hospedagem git geralmente desabilitam, e eu também não vi nenhuma "aparência de má aparência" nas páginas de manual, mas também não encontrei nenhum tipo de documento oficial "é assim que você usa com ForceCommandsegurança".

— Aleksi Torhamo

É certo que o ~/.profileusuário é editável e não é útil para segurança, mas você poderia tornar a técnica do cpast significativa colocando-a em /etc/profile? Você pode verificar o UID para limitá-lo aos usuários certos.

— chicks

1

@chicks: Não, tem exatamente o mesmo problema. O problema não é que o arquivo seja editável pelo usuário; O problema é que ambos os arquivos podem ser ignorados completamente. Os arquivos são usados apenas para shells de login, que você obtém se você apenas diz ssh user@host, mas se você diz ao ssh para executar um comando - ie. ssh user@host command- você não recebe mais um shell de login e os arquivos não são alterados. Portanto, você pode ignorar trivialmente quaisquer restrições que alguém tentou criar com os arquivos, simplesmente fornecendo um argumento extra ao ssh.

— Aleksi Torhamo

2

@chicks: Além disso, acabei de perceber que você se referia ao cpast; o método na resposta do cpast não usa .profile, usa sshd_confige deve ser seguro. Ele apenas menciona .profilecomo um método que você não deve usar para fazer isso.

— Aleksi Torhamo

1

É possível ativar o SSH e desativar o SFTP globalmente e por usuário / grupo.

Pessoalmente, preciso disso porque quero dar acesso a alguns repositórios git sobre SSH e gosto de desativar sistemas que não são necessários. Nesse caso, o SFTP não é necessário.

Globalmente

Você pode desativar o SFTP para todos os usuários de várias maneiras.

O subsistema ausente

O daemon SFTP usado pelo SSH pode ser configurado através da Subsystempalavra - chave. Do sshd_config(5)manual:

Subsystem
        Configures an external subsystem (e.g. file transfer daemon).
        Arguments should be a subsystem name and a command (with optional
        arguments) to execute upon subsystem request.

        The command sftp-server(8) implements the “sftp” file transfer
        subsystem.

        Alternately the name “internal-sftp” implements an in-process
        “sftp” server.  This may simplify configurations using
        ChrootDirectory to force a different filesystem root on clients.

        By default no subsystems are defined.

A última linha sugere que deve ser suficiente não definir nenhum subsistema para "sftp".

Uma mentira falsa

Você também pode desativar o SFTP configurando o daemon SFTP usado pelo SSH para algo inutilizável. Por exemplo, configure o subsistema "sftp" para /bin/false:

Subsystem sftp /bin/false

Quando algo tentava efetuar login via SFTP, o daemon SSH tentava gerar o "daemon sftp" /bin/false. O /bin/falseprograma faz apenas uma coisa, e isso é retornar um código de erro. A tentativa de conexão SFTP é efetivamente negada.

Por usuário / grupo

Também é possível desativar o SFTP por usuário, grupo ou alguns outros critérios.

Isso não funciona se você deseja que o usuário obtenha um prompt de shell regular. Também não faz sentido, pois você pode contornar a maioria das coisas se tiver acesso ao shell. Só funcionará se você quiser dar acesso a um programa específico.

Coincidindo

Para corresponder a um conjunto de usuários, você pode configurar o SSH com a Matchpalavra - chave Do sshd_config(5)manual:

Match
        ...

        The arguments to Match are one or more criteria-pattern pairs or the
        single token All which matches all criteria.  The available criteria
        are User, Group, Host, LocalAddress, LocalPort, and Address.  The
        match patterns may consist of single entries or comma-separated
        lists and may use the wildcard and negation operators described in
        the PATTERNS section of ssh_config(5).

        ...

Alguns exemplos:

Match User eva corresponde ao usuário "eva"
Match User stephen,maria corresponde aos usuários "stephen" e "maria"
Match Group wheel,adams,simpsons corresponde aos grupos "roda", "adams", "simpsons"

Se você quiser obter mais informações, há muitas cargas no sshd_config(5)manual.

Comando forçado

Normalmente, você obtém o shell de login do usuário quando se conecta via SSH, mas o SSH pode ser configurado para forçar um determinado comando. O comando é forçado para qualquer conexão SSH, incluindo SFTP, e, portanto, você pode ter a opção de forçar o comando desejado.

O comando forçar pode ser configurado com a ForceCommandpalavra - chave Do sshd_config(5)manual:

ForceCommand
        Forces the execution of the command specified by ForceCommand,
        ignoring any command supplied by the client and ~/.ssh/rc if
        present.  The command is invoked by using the user's login shell
        with the -c option.  This applies to shell, command, or subsystem
        execution.  It is most useful inside a Match block.  The command
        originally supplied by the client is available in the
        SSH_ORIGINAL_COMMAND environment variable.  Specifying a command of
        “internal-sftp” will force the use of an in-process sftp server that
        requires no support files when used with ChrootDirectory.  The
        default is “none”.

Assim, você pode forçar o comando restrito que deseja usar ForceCommand <your command>. Por exemplo:

Match User kim
        ForceCommand echo 'successful login man, congrats'

Exemplo

No meu caso em que desejo conceder acesso ao git, só preciso que o usuário tenha acesso git-shell. Esta é a seção que desativa o SFTP para meus usuários git, junto com algumas opções de segurança:

Match Group git

        # have to do this instead of setting the login shell to `git-shell`,
        # to disable SFTP
        ForceCommand /usr/bin/git-shell -c "$SSH_ORIGINAL_COMMAND"

        # disable stuff we don't need
        AllowAgentForwarding no
        AllowTcpForwarding no
        AllowStreamLocalForwarding no
        PermitOpen none
        PermitTunnel no
        PermitTTY no
        X11Forwarding no

— aude
fonte

No meu caso, eu queria permitir apenas o acesso ao MySQL (desabilitando o acesso SFTP e as janelas do terminal SSH) para uma chave autorizada específica (ou seja, nenhuma alteração no arquivo sshd_config). Eu consegui fazer isso com as seguintes opções ~ / .ssh / allowed_keys para a chave específica: command = "/ usr / bin / echo 'Somente acesso MySQL é permitido.'", No-pty, no-X11-forwarding, allowopen = "127.0.0.1:3306"

— Martin_ATS 5/18/18