Configurar o sftp no Amazon Linux 2 com chaves ssh, segregação de usuários (sftp vs ssh), portas diferentes e restrições de diretório de usuários

Question

TDLR: Eu tenho um Catch 22 onde, dependendo das permissões no diretório inicial do usuário, posso fazer com que a autenticação SSH funcione ou as restrições do diretório do usuário, mas não ambas.

Aliás, eu realmente quero lançar meu próprio servidor SFTP. Por favor, não recomendo que eu experimente o serviço AWS Transfer ou algo alternativo. Obrigado.

Aqui está o conteúdo relevante (alterado do padrão) em /etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Port 22
Port 2299
Match Group sftpusers LocalPort 2299
  ChrootDirectory /sftp-data/%u
  ForceCommand internal-sftp
Match Group sftpusers LocalPort 22
  DenyGroups sftpusers
Match LocalPort 2299  Group *,!sftpusers
  DenyUsers *

Quero que a porta 22 funcione como o ssh normalmente funciona, mas apenas para usuários não-sftp. Para usuários de SFTP, no grupo "sftpusers", quero que a porta 2299 funcione apenas como SFTP, e não como SSH. Para usuários que não são sftpusers, quero que o acesso à porta 2299 seja negado.

Ok, então criei um usuário "user1" com diretório inicial /sftp-data/user1 e shell /sbin/nologin. Criei /sftp-data/user1/.ssh/authorized_keys e preenchi-o com a chave ssh pública. /sftp-data pertence ao root com 700 permissões. /sftp-data/user1/.ssh e abaixo são propriedade do usuário1, e /sftp-data/user1/.ssh/authorized_keys tem permissão 600. A propriedade/permissões de /sftp-data/user1 estão em questão aqui. Mais abaixo.

Criei o grupo de usuários sftpusers e adicionei o usuário1 a esse grupo. No entanto, o usuário ec2 integrado que você obtém com a AWS não é membro desse grupo. Os testes com ec2-user funcionaram muito bem: acesso via ssh, a porta 22 funcionou como sempre, mas sem acesso à porta 2299.

Então, testar com o usuário1 foi onde tudo ficou interessante. O usuário1 não tem acesso à porta 22 – isso é ótimo! Com o usuário1 possuindo /sftp-data/user1, a autenticação da chave pública ssh é bem-sucedida na porta 2299, mas o usuário é imediatamente desconectado, com esta mensagem salva em /var/log/secure:

Sep  2 19:21:38 ip-192-168-0-25 sshd[10369]: Accepted publickey for user1 from <ip-address redacted> port 61110 ssh2: ECDSA SHA256:<sha redacted>
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: fatal: bad ownership or modes for chroot directory "/sftp-data/user1" [postauth]
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session closed for user user1

Claro, isso faz sentido. Chroot requer que /sftp-data/user1 pertença ao root, permissões 700. Então, faça isso e agora a autenticação sftp (chave ssh) falha.

Sep  2 19:41:00 ip-192-168-0-25 sshd[11693]: error: AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys user1 SHA256:<sha redacted> failed, status 22

A propósito, eic_run_authorized_keys é um wrapper que a AWS coloca em torno da autenticação ssh padrão para habilitar o AWS Instance Connect.

Para crédito extra... se o problema acima não for desafiador o suficiente, você pode criar um esquema onde eu possa dar a usuários de FTP específicos acesso a diretórios de projetos específicos, e somente aqueles, sem criar um grupo para cada projeto? Link do diretório inicial de cada usuário para um diretório de projeto seria incrível.

Informações adicionais solicitadas por @anx:

# getent passwd user1
user1:x:1001:1001::/sftp-data/user1:/sbin/nologin
# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

Ativei o log DEBUG para sshd. Usando a diretiva ChrootDirectory, com /sftp-data/user1 de propriedade do root e falha na autenticação SSH, vejo isso em /var/log/secure:

debug1: Não foi possível abrir chaves autorizadas '/sftp-data/user1/.ssh/authorized_keys': Permissão negada

ps me mostra claramente que o root está executando o processo sshd.

Answer 1

Seu ChrootDirectoryé /sftp-data/user1, que deve pertencer ao root. E isso é:

# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

No entanto, neste ponto o sshd já alterou o usuário para user1 e eliminou os privilégios, portanto o user1 não pode descer para diretórios de nível inferior. Para fazer isso, o diretório precisa de permissão de pesquisa ( a+x).

chmod a+x /sftp-data/user1

Agora o usuário1 pode descer para subdiretórios e o .sshdiretório deve estar legível.

Answer 2

Acho que isso é principalmente um problema de permissão de pasta. Eu acho que isso /sftp-data/user1/.sshe os diretórios abaixo devem pertencer a user1, mas parece que eles pertencem a root. Tente o seguinte como root:

Verifique se a chave pública /sftp-data/user1/.ssh/authorized_keysestá correta. Depois disso, acho que estas são as permissões que você pode precisar alterar:

chmod 700 /sftp-data/user1/.ssh
chmod 600 /sftp-data/user1/.ssh/authorized_keys
chown root:sftpusers /sftp-data
chown -R user1:user1 /sftp-data/user1/.ssh

Reinicie o SSH e acho que você estará pronto.