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?
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?
Respostas:
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.conf
para configurar o shell rssh - especialmente a allowscp
linha 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.)
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_user
no 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:
-v
arquivo de comando e o arquivo autorizado_keys)-r
arquivo de comando e o autorizado_keys se não desejar fazer uma cópia recursiva)-P 2222
do comando)-i .ssh/id_rsa_key_file
path/to/data
será 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
chmod 400 ~/.ssh/authorized_keys
.
~/.bashrc
(e o que mais o Bash executar) e ~/.ssh/rc
somente leitura. Mas se o usuário mal-intencionado tiver acesso ao rsync ou sftp, ele ainda poderá remover ~/.bashrc
e fazer upload de um novo. Como é difícil proteger, recomendo esse método ( command="..."
).
Estou um pouco atrasado para a festa, no entanto, sugiro que você dê uma olhada na ForceCommand
diretiva 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.
chrootDirectory %h
e AllowTcpForwarding no
depois 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!)
ForceCommand internal-sftp -u 0077 -d /uploaddir
pode 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, ForceCommand
não na Subsystem
diretiva, se você desejar que eles funcionem.
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
scponly
é PROJETADO exatamente para esse fim.
Eu uso o MySecureShell para fazer isso. Você também pode configurar outras restrições.
https://github.com/mysecureshell/mysecureshell
Limita as conexões apenas ao SFTP / SCP. Sem acesso ao shell.
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)
~/.ssh/authorized_keys
, ~/.bashrc
(e tudo o Bash pessoa executa) e ~/.ssh/rc
somente leitura para o usuário. Mas se o usuário mal-intencionado tiver acesso ao rsync ou sftp, ele ainda poderá remover ~/.bashrc
e fazer upload de um novo. Como é difícil proteger, recomendo esse método ( command="..."
).
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/rc
ou ~/.bashrc
, e, portanto, pode incluir e executar comandos arbitrários.
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á
~/.bashrc
). Também é esquisito no sentido de que talvez as versões mais recentes do OpenSSH definam a TERM
variável de forma diferente, ou algumas definições de configuração do sshd podem afetar TERM
.
ssh -o SetEnv TERM=dumb yourserver bash
??