compartilhe a chave pública ssh na configuração do sftp

Question

Configurei um servidor SFTP no CentOS seguindoeste documento. Minha intenção é proibir o login no console para os novos usuários ( user1, user2), que pertencem ao sftpusersgrupo, mas ainda podem efetuar login em suas respectivas sftppastas.

Além disso, quero usar as mesmas chaves usadas pelo usuário CentOS (que pode fazer login no console e sftpsem problemas). Para fazer isso, copiei a .sshpasta do usuário CentOS para as pastas user1e user2home, mudando a propriedade para os usuários e 700para a .sshpasta e 600para authorized_keyso arquivo.

Mesmo assim, continuo recebendo a mensagem Server refused our key. A chave usada pelo usuário CentOS é como uma chave mestra em todos os servidores, por isso quero reutilizar essa chave para os novos usuários.

Como posso conseguir essa configuração?

ATUALIZAR

Depois de gerar chaves para cada usuário, ambos os usuários podem acessar o servidor remotamente com suas chaves privadas, mas quando eu ativo a seguinte configuração nas /etc/ssh/sshd_configpermissões são negadas usando o sftpcomando.

Configuração SSHD

Match Group sftpusers #Or you could replace Group with User and specify a different configuration for each user
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
ChrootDirectory /path/to/shared_folder/%u # %h the path to upload the files
ForceCommand internal-sftp

Mensagem do shell

packet_write_wait: Connection to IPSERVER port 22: Broken pipe
Couldn't read packet: Connection reset by peer

Answer 1

A atualização apresenta um problema diferente da pergunta original. Parece que o problema original não é mais um problema. Estou abordando a atualização.

Omanuallê:

ChrootDirectory
Especifica o nome do caminho de um diretório chroot(2)após a autenticação. Na inicialização da sessão, sshd(8)verifica se todos os componentes do nome do caminho são diretórios de propriedade da raiz que não podem ser gravados por nenhum outro usuário ou grupo.

Meus testes indicam que se esta condição não for satisfeita, ocorrerá Broken pipeao tentar fazer login com sftp.

No seu caso, o nome do caminho é /path/to/shared_folder/%u. Nota %u(após a expansão) étambémUm componente; portanto, deve ser "de propriedade do root e não gravável por qualquer outro usuário ou grupo". Você deve corrigir a propriedade e as permissões. Então, obviamente, o usuário não poderá gravar no diretório. Qualquer que seja o nome do caminho usado ChrootDirectory, o usuário não poderá escrever nele (a menos que o usuário seja root). Em outras palavras, o usuário não poderá escrever /no ambiente chroot. Para permitir a escrita, você precisa de um subdiretório. Existem algumas maneiras de lidar com isso.

• Usando diretórios iniciais em um diretório chroot comum.

  O manual também afirma:

  Após o chroot, sshd(8)altera o diretório de trabalho para o diretório inicial do usuário.

  Presumo que os diretórios iniciais sejam como /home/user1, /home/user2etc. por padrão. Isso sugere o seguinte cenário:

  1. Configure o servidor para fazer chroot /path/to/shared_folder(não %u):

     ChrootDirectory /path/to/shared_folder
     

  2. Replique a estrutura de diretórios relevante ( /path/to/shared_folder/home/user1etc.).

  3. Satisfaça a condição pathpara toe shared_folder.
  4. Faça com que a propriedade e as permissões sejam homecomo são para o arquivo /home.
  5. Faça com que a propriedade e as permissões dos diretórios internos homesejam iguais às dos diretórios em /home.

  Com esta configuração será colocado sftpautomaticamente após a autenticação, mas eles verão isso como devido a .user1/path/to/shared_folder/home/user1/home/user1chroot

• Usando diretórios personalizados em um diretório chroot comum.

  Com ForceCommand internal-sftpvocê pode especificar o diretório inicial ( internal-sftpsuporta o mesmo conjunto de opções quesftp-server). Assim:

  ChrootDirectory /path/to/shared_folder
  ForceCommand internal-sftp -d /home/%u
  

  para garantir que sftpos usuários usarão /path/to/shared_folder/home/…independentemente de seus diretórios iniciais formais no sistema operacional. Ou assim:

  ChrootDirectory /path/to/shared_folder
  ForceCommand internal-sftp -d /%u
  

  para simplificar caminhos e se livrar disso homeno meio. Dessa forma, user1você verá que eles estão logados /user1após fazer login com sftp. Neste caso, shared_folderdeve conter diretamente as pastas do usuário (não home).

• Usar pelo menos um subdiretório em um diretório chroot específico do usuário.

  As soluções acima permitem que os usuários naveguem nos diretórios uns dos outros. Um usuário poderá conceder ou negar acesso aos chmodseus arquivos ( sftpsuportes ).chmod

  Você usou %uwith ChrootDirectory, então provavelmente deseja criar diretórios chroot separados. Nesse caso, faça o que você fez:

  ChrootDirectory /path/to/shared_folder/%u
  

  e definir a propriedade e as permissões de cada componente (incluindo o que %use expande) para satisfazer a condição. A menos que se trate de acesso somente leitura, você precisa de pelo menos um subdiretório que possa ser gravado pelo usuário. Poucas possibilidades:

  • replicar o caminho para o diretório inicial do usuário, conforme definido no sistema operacional;
  • forçando /home/%ucom ForceCommand internal-sftp -d /home/%u;
  • forçando /%ucom ForceCommand internal-sftp -d /%u;
  • usando um nome de subdiretório fixo, por exemplo ForceCommand internal-sftp -d /files.

  Em cada caso, você precisa preparar a estrutura de diretórios dentro do arquivo /path/to/shared_folder. Por exemplo, se você quiser forçar /home/user1, user1o caminho relevante será:

  /path/to/shared_folder/user1/home/user1
  

  onde path, to, shared_foldere (o primeiro) user1satisfazem a condição, homesimula /homee (o segundo) user1pode ser gravado pelo usuário.

Abordagens mais flexíveis são possíveis. Por exemplo, você pode ter um diretório chroot comum para user1e user2, mas diferente para user3.

Diretório chroot comum ou não, pessoalmente eu faria os subdiretórios da maneira menos surpreendente, para que qualquer usuário se encontre em um diretório que espera. Depois de digitar pwd, sftpeles deverão ver algo como /home/user1. Acho outras possibilidades ( /user1, /files) um tanto surpreendentes.