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

Question

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 podem realmente efetuar login no servidor usando o SSH?

    

Answer 1

O shell rssh ( link ) foi criado exatamente para esse fim.

Como o RHEL / CentOS 5.2 não inclui um pacote para rssh, você pode procurar aqui para obter um RPM: link

Para usá-lo, basta defini-lo como um shell para um novo usuário assim:

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 descomente allowscp line para ativar o acesso SCP para todos os usuários do rssh.

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

    

Answer 2

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

no-port-forwarding,no-pty,command="scp source target" ssh-dss ...

Você pode precisar usar ps no alvo para definir as configurações de comando corretas.

PS: Se você executar um comando scp de teste com "-v", poderá ver algo assim

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

Você notará que "-t" é uma opção scp não documentada, usada pelo programa no outro extremo. Isso dá a idéia do que você precisa colocar em authorized_keys.

EDITAR: Você pode encontrar mais informações (com vários links) em essa pergunta do StackOverflow .

Aqui está um exemplo prático disso, para um usuário chamado backup_user no lado do servidor.

~backup_user/.ssh/authorized_keys content 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 vincula 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 ( opçãonal : você pode remover o -v do arquivo command e authorized_keys)
• Recursivamente copia o conteúdo do caminho / para / data. ( optionnal : você pode remover -r do arquivo command e authorized_keys se não quiser fazer uma cópia recursiva)
• Ele usa a porta 2222 para se conectar ao servidor ( optionnal : você pode remover -P 2222 do comando)
• Ele usa um arquivo de identidade para automatizar a conexão ( optionnal : você pode remover -i .ssh/id_rsa_key_file
• O conteúdo de 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 este como descrito aqui

    

Answer 3

Estou um pouco atrasado para a festa, no entanto, sugiro que você dê uma olhada na diretiva ForceCommand 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 chroot o usuário se quiser.

    

Answer 4

Eu recomendo usar scponly.

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

Uma vez 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 usar o seguinte comando: usermod -s /usr/bin/scponly USERNAME

    

Answer 5

Eu uso o MySecureShell para fazer isso. Você também pode configurar outras restrições.

link

Limita conexões somente a SFTP / SCP. Nenhum acesso ao shell.

    

Answer 6

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

    

Answer 7

Nós usamos um shell psudo chamado scponly em nossos servidores ftp seguros para usuários que só queremos ser capazes de arquivos scp mas não faça o login.

    

Answer 8

Eu descobri que uma boa maneira é usar o recurso command="..." do arquivo authorized_keys. (Sugerido para mim por esta página )

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

Este é o arquivo authorized_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 precisa proteger o arquivo authorized_keys do usuário, mas meu objetivo era ter uma chave sem senha que eu pudesse usar para backups, sem ter que criar um usuário totalmente novo e ter a chave não dar uma concha (ok, facilmente)

    

Answer 9

Não é a solução mais graciosa, mas você poderia jogar algo assim nos usuários .bashrc

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

Descobri que os usuários de SCP obtêm um TERM de "burro" e outros normalmente obtêm vt100.

Eu imagino que o usuário poderia provavelmente obter uma nova .bashrc, o que torna esta não a melhor solução, mas para uma solução rápida e suja, isso funcionará

    

Answer 10

Altere o shell de login do usuário para algo restritivo, o que permite ao usuário executar somente scp , sftp-server e rsync apenas, e também verifica que argumentos não seguros não são permitidos (por exemplo, scp -S ... e rsync -e ... são inseguros, veja aqui: link . Exemplo para esse shell de login restritivo:

• rssh
• scponly (não só scp, também permite sftp, svn etc. se configurado assim)
• transfer_shell

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

Não recomendo usar command="..." em ~/.ssh/authorized_keys , porque sem uma proteção adicional cuidadosa (como chmod -R u-w ~ para o usuário), um usuário mal-intencionado pode fazer upload de uma nova versão de ~/.ssh/authorized_keys , ~/.ssh/rc ou ~/.bashrc e, portanto, pode incluir e executar comandos arbitrários.