Início / unix / Perguntas / 425973
Accepted
Jon Buys
Asked: 2018-02-23 11:55:07 +0800 CST

Por que os clientes SFTP não podem renomear um arquivo em seu diretório inicial montado pelo NFS?

  • 772

Eu tenho uma instância do Amazon Linux executando SSH atuando como um servidor SFTP. Os clientes efetuam login e são colocados em chroot em um diretório montado por NFS. Os usuários podem ler, gravar e excluir arquivos, mas a renomeação de arquivos falha com um "erro de protocolo" não específico.

Aqui está uma cópia do meu sshd_configarquivo:

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
UsePrivilegeSeparation yes

KeyRegenerationInterval 3600
ServerKeyBits 1024

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes

IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

PasswordAuthentication yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

AcceptEnv LANG LC_*

# Subsystem sftp /usr/lib/openssh/sftp-server -u 0002
Subsystem sftp internal-sftp -l DEBUG -u 002 -d %u

UsePAM yes
Match Group sftpusers
    ChrootDirectory /autohome
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp -l DEBUG -u 002 -d %u

Eu vi referência ao sftp renomear não funcionando quando a origem e o destino estão em sistemas de arquivos separados, mas esse não é o caso aqui. Também vi referências à renomeação de sftp que não funcionam em sistemas de arquivos que não oferecem suporte a links físicos, mas acho que nosso servidor NFS (AWS File Storage Gateway) deve funcionar bem. Estou perdido, qualquer ajuda é apreciada.

sshd sftp

1 respostas

  1. Best Answer

    Graças à dica de @Kenster, encontrei o problema. Eu estava enganado ao presumir que o NFS do AWS File Storage Gateway montava hard links suportados, já que a documentação afirma claramente que não.

    Eu tinha tanta certeza de que era esse o caso que acabei rastreando as chamadas do sistema com strace. Se você anexar um cliente sftp ao seu servidor durante o ssh, obtenha o pid do processo sftp atual com ps -eaf | grep sftp. Em seguida, você pode rastrear as chamadas do sistema com strace e salvar a saída em um arquivo com este comando: strace -ff -p 2116 -o sftp_rename.logonde -ff segue os processos filhos, -p é o pid e -o é o arquivo de saída.

    Isso fornecerá uma saída realmente terrível, mas o que achei interessante foi este trecho:

    write(7, "\0\0\0L\0\0\0\3\0\0\0Drename old \"/testuse"..., 80) = 80
lstat("/testuser/test/asdfasdf.txt", {st_mode=S_IFREG|0664, st_size=159, ...}) = 0
link("/testuser/test/asdfasdf.txt", "/testuser/test/as.txt") = -1 ENOTSUPP (Unknown error 524)

    Que testei com um comando de link simples para criar um link físico, que falhou.

    # ln asdfasdf.txt link.txt
ln: failed to create hard link ‘link.txt’ => ‘asdfasdf.txt’: Unknown error 524
#

    O que me levou de volta à documentação da AWS. Porém, isso não é tudo, aparentemente a renomeação do SFTP funcionará com certos clientes (como o Paramiko) que implementam um CMD_EXTENDEDprotocolo específico do fornecedor, como o Paramiko faz :

        oldpath = self._adjust_cwd(oldpath)
    newpath = self._adjust_cwd(newpath)
    self._log(DEBUG, 'posix_rename({!r}, {!r})'.format(oldpath, newpath))
    self._request(
        CMD_EXTENDED, "[email protected]", oldpath, newpath
    )

    Não parece haver nenhuma maneira de forçar o uso da posix-renameopção para todos os clientes, mas pelo menos sabemos o que aconteceu e por quê.

    • 2

relate perguntas