Permitir login SCP, mas não real, usando SSH


62

Existe alguma maneira de configurar um usuário em uma caixa Linux (Centos 5.2 neste caso) para que eles possam usar o scp para recuperar arquivos, mas não possam realmente fazer login no servidor usando SSH?


Tentei configurar o shell de login como / bin / false, mas isso apenas interrompe o funcionamento do scp.
DrStalker 12/11/2009

Respostas:


45

O rssh shell ( http://pizzashack.org/rssh/ ) foi desenvolvido para esse fim.

Como o RHEL / CentOS 5.2 não inclui um pacote para rssh, você pode procurar aqui para obter um RPM: http://dag.wieers.com/rpm/packages/rssh/

Para usá-lo, basta configurá-lo como um shell para um novo usuário como este:

useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1

..ou altere o shell para um existente como este:

chsh -s /usr/bin/rssh scpuser1

..e edite /etc/rssh.confpara configurar o shell rssh - especialmente a allowscplinha de comentários para permitir o acesso do SCP a todos os usuários do rssh.

(Você também pode usar chroot para manter os usuários em suas casas, mas isso é outra história.)


isso é incrível - Eu estive procurando por algo como isso por um tempo, também
Warren

6
a idéia por trás do rssh é boa, mas o iirc rssh não era exatamente um milagre da segurança em termos de programação. Um simples google sobre 'rssh explorar' produz mais resultados do que eu estou confortável com ...
wzzrd

7
scponly é mais ou menos a mesma coisa que bem e aparentemente menos exploits propensas: sublimation.org/scponly/wiki/index.php/Main_Page
François Feugeas

scponly parece ter se mudado para o github. O link de sublimação está morto. github.com/scponly/scponly/wiki
spazm 13/09/13

38

Estou muito atrasado, mas você pode usar as teclas ssh e especificar o comando exato permitido no arquivo ~ / .ssh / allowed_keys, por exemplo

no-port-forwarding, no-pty, command = "destino da fonte scp" ssh-dss ...

Pode ser necessário usar ps no destino para definir as configurações de comando corretas.

PS: Se você executar um comando test scp com "-v", poderá ver algo como isto

debug1: Sending command: scp -v -t myfile.txt

Você observará que "-t" é uma opção scp não documentada, usada pelo programa na extremidade oposta. Isso lhe dá a idéia do que você precisa colocar nas chaves_autorizadas.

EDIT: Você pode encontrar mais informações (com vários links) nesta pergunta StackOverflow .

Aqui está um exemplo prático disso, para um usuário nomeado backup_userno lado do servidor.

~backup_user/.ssh/authorized_keys conteúdo no lado do servidor (com mais algumas restrições de segurança):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

Crie um link em ~ backup_user / que vincule ao diretório em que o conteúdo deve estar acessível.

$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

Agora, do lado do cliente, o seguinte comando deve funcionar:

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

O que este comando faz:

  • Ele exibe informações detalhadas ( opcional : você pode remover o -varquivo de comando e o arquivo autorizado_keys)
  • Ele copia recursivamente o conteúdo do caminho / para / dados. ( opcional : você pode remover o -rarquivo de comando e o autorizado_keys se não desejar fazer uma cópia recursiva)
  • Ele usa a porta 2222 para conectar-se ao servidor ( opcional : você pode remover -P 2222do comando)
  • Ele usa um arquivo de identidade para automatizar a conexão ( opcional : você pode remover-i .ssh/id_rsa_key_file
  • O conteúdo de path/to/dataserá copiado para/path/to/directory/with/accessible/content/

Para fazer uma cópia de um arquivo (ou vários) do servidor para o cliente, você deve criar um script de shell que lide com isso conforme descrito aqui


11
O que impede o usuário de vasculhar seu arquivo allowed_keys? Pode ser restrito a não pertencer ao próprio usuário?
Dan

11
@ Dan - Deve ser possível definir permissões somente leitura no arquivo allowed_keys, ou seja. chmod 400 ~/.ssh/authorized_keys.
Roger Dueck

Além disso, você deve criar ~/.bashrc(e o que mais o Bash executar) e ~/.ssh/rcsomente leitura. Mas se o usuário mal-intencionado tiver acesso ao rsync ou sftp, ele ainda poderá remover ~/.bashrce fazer upload de um novo. Como é difícil proteger, recomendo esse método ( command="...").
pts

31

Estou um pouco atrasado para a festa, no entanto, sugiro que você dê uma olhada na ForceCommanddiretiva do OpenSSH.

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

Concedido, isso é SFTP e não SCP, mas atinge o mesmo objetivo, com mais segurança do que com um shell restrito. Além disso, você pode fazer chroot do usuário, se desejar.


2
adicione a seção chrootDirectory %he AllowTcpForwarding nodepois da partida para forçar os usuários sftponly a chroot para sua casa. por favor note que a partida deve ser a última seção sobre a configuração e as opções de ssh depois que são opções apenas para os usuários combinados (must!)
Higuita

4
ForceCommand internal-sftp -u 0077 -d /uploaddirpode fortalecê-lo ainda mais, forçando uma umask em um diretório de upload. Em conjunto com o 'ChrootDirectory`, ele cria um ambiente de upload isolado e muito controlado. Nota de bônus: o dir padrão e o umask devem ser definidos na diretiva, ForceCommandnão na Subsystemdiretiva, se você desejar que eles funcionem.
Marcin

Um artigo mais longo explicando isso está disponível em debian-administration.org/article/590/…
koppor

7

Eu recomendo usar o scponly.

É um shell restrito que permite que os usuários façam exatamente o que parece, arquivos SCP no servidor, mas não efetuem login. Informações e downloads de código-fonte para o software estão disponíveis aqui e os pacotes RPM pré-compilados estão disponíveis no diretório Repositórios EPEL YUM .

Depois de instalado, você precisará configurar cada conta de usuário, à qual deseja restringir o acesso, para usar o shell restrito recém-instalado. Você pode fazer isso manualmente via / etc / passwd ou use o seguinte comando: usermod -s /usr/bin/scponly USERNAME


Eu segundo isso. scponlyé PROJETADO exatamente para esse fim.
precisa saber é o seguinte

11
scponly parece estar morto. parece que o debian o removeu: packages.debian.org/search?keywords=scponly e o código no github também está morto. Discussão de acompanhamento: serverfault.com/questions/726519/…
koppor


3

Muito tarde para a festa, mas apenas defina o shell do usuário git como / usr / bin / git-shell. É um shell restrito que não permite login interativo. Você ainda pode entrar no usuário com 'su -s / bin / bash git' ou qualquer que seja o seu nome de usuário do git.


2

Usamos um psudo shell chamado scponly em nossos servidores ftp seguros para usuários que desejamos apenas poder scp arquivos, mas não efetuar login.


2

Eu encontrei uma boa maneira é usar o recurso command = "..." do arquivo allowed_keys. (Sugerido por esta página )

O comando que você executaria seria aquele que testa argumentos que começam com scp (e rsync).

Aqui está o arquivo allowed_keys:

# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew

Aqui está o conteúdo do remote-cmd.sh:

#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
 'scp'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 'rsync'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 *)
    echo "Access Denied"
    ;;
esac

Eu acho que você provavelmente ainda precisará proteger o arquivo allowed_keys do usuário, mas meu objetivo era ter uma chave sem senha que eu pudesse usar para backups, sem precisar criar um usuário totalmente novo, e a chave não fornecer um shell (ok, facilmente)


3
Isso é bem legal - mas eu imagino que ele possa ser subvertido emitindo um comando que faz um scp e execute um script depois!
davidgo

@davidgo prepending $ SSH_ORIGINAL_COMMAND com exec pode resolver essa vulnerabilidade, assumindo scp e rsync não-se tentar executar vários programas (caso em que, isso iria quebrar isso)
Phil

Além disso, você deve fazer ~/.ssh/authorized_keys, ~/.bashrc(e tudo o Bash pessoa executa) e ~/.ssh/rcsomente leitura para o usuário. Mas se o usuário mal-intencionado tiver acesso ao rsync ou sftp, ele ainda poderá remover ~/.bashrce fazer upload de um novo. Como é difícil proteger, recomendo esse método ( command="...").
pts

11
@pts, você pode criar os arquivos rc e os diretórios que os contêm pertencerem a alguém que não seja o usuário (ninguém?) e não podem ser gravados pelo usuário. Mas, neste ponto, é melhor usar algo dedicado como o rssh. Uau, acabei de perceber que esta é a minha resposta! É velho! Haha!
Phil

Não esqueça que scp -S ... e rsync -e ... permitem ao usuário executar comandos arbitrários. Portanto, você deve verificar os argumentos em $ SSH_ORIGINAL_COMMAND antes de executá-lo. Mais informações aqui: exploit-db.com/exploits/24795
pts

1

Altere o shell de login do usuário para algo restritivo, que permite ao usuário executar apenas scp , sftp-server e rsync , e também verifica se argumentos não seguros não são permitidos (por exemplo, scp -S ... e rsync -e .. . não são seguras, consulte aqui: http://exploit-db.com/exploits/24795 ). Exemplo para esse shell de login restritivo:

Você pode executar um destes em um chroot ou em outro ambiente restrito (por exemplo, nsjail no Linux), para desativar o acesso à rede e para um controle mais fácil (na lista de permissões) de quais diretórios podem ser lidos e / ou gravados.

Eu não recomendo o uso command="..."em ~/.ssh/authorized_keys, porque sem proteção adicional cuidadoso (como chmod -R u-w ~para o usuário) que um usuário malicioso pode fazer upload de uma nova versão do ~/.ssh/authorized_keys, ~/.ssh/rcou ~/.bashrc, e, portanto, pode incluir e executar comandos arbitrários.


0

Não é a solução mais elegante, mas você pode lançar algo assim nos usuários .bashrc

if [ "$TERM"  != "dumb" ]; then
  exit
fi

Descobri que os usuários do SCP obtêm um TERM de 'burro' e outros normalmente recebem o vt100.

Eu imagino que o usuário provavelmente possa scp sobre um novo .bashrc, o que torna essa não a melhor solução, mas para uma solução rápida e suja, isso funcionará


11
Eu recomendo fortemente contra essa solução proposta, é muito fácil para um usuário mal-intencionado contornar (por exemplo, enviando outro ~/.bashrc). Também é esquisito no sentido de que talvez as versões mais recentes do OpenSSH definam a TERMvariável de forma diferente, ou algumas definições de configuração do sshd podem afetar TERM.
pts

11
Ehhh ... ssh -o SetEnv TERM=dumb yourserver bash??
ulidtko 2/07
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.