SFTP com chroot, dependendo da chave pública de conexão do usuário

Eu quero construir um servidor (executando o Debian ou FreeBSD) que receba backups de diferentes clientes via sshfs. Cada cliente deve poder ler e gravar seus próprios dados de backup, mas não os dados de qualquer outro cliente.

Eu tive a seguinte ideia: cada cliente se conecta através da autenticação de chave pública a backup@backupserver.local. O backup do usuário possui um arquivo autorizado_keys especial, assim:

command="internal-sftp" chroot="/backup/client-1/data" ssh-rsa (key1)
command="internal-sftp" chroot="/backup/client-2/data" ssh-rsa (key2)
command="internal-sftp" chroot="/backup/client-3/data" ssh-rsa (key3)
etc...

A vantagem disso seria que eu não precisaria usar um usuário separado para cada cliente e poderia facilmente gerar automaticamente o arquivo allowed_keys com um script.

Há apenas um problema: o chroot=...não funciona. O arquivo allowed_keys do OpenSSH parece não ter um equivalente para o ChrootDirectory (que funciona em / etc / ssh / sshd_config, globalmente ou em um bloco Match User).

Existe uma maneira razoavelmente simples de realizar o que eu quero usando o OpenSSH? Talvez usando a command=...diretiva de uma maneira inteligente? Como alternativa, existem outros servidores SFTP que podem fazer o que eu quero?

EDIT : Para deixar mais claro o que eu quero alcançar: quero que vários clientes possam armazenar arquivos no meu servidor. Cada cliente não deve poder ver os arquivos de nenhum outro cliente. E não quero encher meu servidor com dezenas de contas de usuário, portanto, gostaria de uma solução facilmente gerenciável para os clientes compartilharem uma conta de usuário e ainda não terem acesso aos arquivos de outros.

Como alternativa, existem outros servidores SFTP que podem fazer o que eu quero?

sim, você pode usar proftpd

Prepare o ambiente do usuário. Com o ProFTPD, não é necessário fornecer ao usuário um shell válido.

# useradd -m -d /vhosts/backup/user1/ -s /sbin/nologin user1
# passwd --lock user1
Locking password for user user1.
passwd: Success

# mkdir /vhosts/backup/user1/.sftp/
# touch /vhosts/backup/user1/.sftp/authorized_keys

# chown -R user1:user1 /vhosts/backup/user1/
# chmod -R 700 /vhosts/backup/user1/

Para usar chaves públicas OpenSSH em um SFTPAuthorizedUserKeys, você deve convertê-las no formato RFC4716. Você pode fazer isso com a ferramenta ssh-keygen:

# ssh-keygen -e -f user1.public.key > /vhosts/backup/user1/.sftp/authorized_keys

Setup ProFTPD

ServerName "ProFTPD Default Installation"
ServerType standalone
DefaultServer off

LoadModule mod_tls.c
LoadModule mod_sftp.c
LoadModule mod_rewrite.c

TLSProtocol TLSv1 TLSv1.1 TLSv1.2

# Disable default ftp server
Port 0

UseReverseDNS off
IdentLookups off

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022

# PersistentPasswd causes problems with NIS/LDAP.
PersistentPasswd off

MaxInstances 30

# Set the user and group under which the server will run.
User nobody
Group nobody

# Normally, we want files to be overwriteable.
AllowOverwrite                  on

TimesGMT off
SetEnv TZ :/etc/localtime

<VirtualHost sftp.example.net>
    ServerName "SFTP: Backup server."
    DefaultRoot ~
    Umask 002
    Port 2121

    RootRevoke on

    SFTPEngine on
    SFTPLog /var/log/proftpd/sftp.log

    SFTPHostKey /etc/ssh/ssh_host_rsa_key
    SFTPHostKey /etc/ssh/ssh_host_dsa_key
    SFTPDHParamFile /etc/pki/proftpd/dhparam_2048.pem
    SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys

    SFTPCompression delayed
    SFTPAuthMethods publickey
</VirtualHost>

<Global>
    RequireValidShell off
    AllowOverwrite yes

    DenyFilter \*.*/

    <Limit SITE_CHMOD>
        DenyAll
    </Limit>
</Global>

LogFormat default "%h %l %u %t \"%r\" %s %b"
LogFormat auth    "%v [%P] %h %t \"%r\" %s"
ExtendedLog /var/log/proftpd/access.log read,write

Crie parâmetros de grupo DH (Diffie-Hellman).

# openssl dhparam -out /etc/pki/proftpd/dhparam_2048.pem 2048

Configure qualquer cliente SFTP. Eu usei o FileZilla

Se você executar o ProFPTD no modo de depuração

# proftpd -n -d 3 

No console, você verá algo como o seguinte

2016-02-21 22:12:48,275 sftp.example.net proftpd[50511]: using PCRE 7.8 2008-09-05
2016-02-21 22:12:48,279 sftp.example.net proftpd[50511]: mod_sftp/0.9.9: using OpenSSL 1.0.1e-fips 11 Feb 2013
2016-02-21 22:12:48,462 sftp.example.net proftpd[50511] sftp.example.net: set core resource limits for daemon
2016-02-21 22:12:48,462 sftp.example.net proftpd[50511] sftp.example.net: ProFTPD 1.3.5a (maint) (built Sun Feb 21 2016 21:22:00 UTC) standalone mode STARTUP
2016-02-21 22:12:59,780 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): mod_cap/1.1: adding CAP_SETUID and CAP_SETGID capabilities
2016-02-21 22:12:59,780 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): SSH2 session opened.
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): Preparing to chroot to directory '/vhosts/backup/user1'
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): Environment successfully chroot()ed
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): USER user1: Login successful

E as seguintes linhas em /var/log/sftp.log

2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: sending acceptable userauth methods: publickey
2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: public key MD5 fingerprint: c2:2f:a3:93:59:5d:e4:38:99:4b:fd:b1:6e:fc:54:6c
2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: sending publickey OK
2016-02-21 22:12:59,789 mod_sftp/0.9.9[50309]: public key MD5 fingerprint: c2:2f:a3:93:59:5d:e4:38:99:4b:fd:b1:6e:fc:54:6c
2016-02-21 22:12:59,790 mod_sftp/0.9.9[50309]: sending userauth success
2016-02-21 22:12:59,790 mod_sftp/0.9.9[50309]: user 'user1' authenticated via 'publickey' method

PS

O caminho configurado para um arquivo que contém chaves autorizadas ( SFTPAuthorizedUserKeys ) pode usar a variável % u , que será interpolada com o nome do usuário que está sendo autenticado. Esse recurso suporta ter arquivos por usuário de chaves autorizadas que residem em um local central, em vez de exigir (ou permitir) que os usuários gerenciem suas próprias chaves autorizadas. Por exemplo:

SFTPAuthorizedUserKeys file:/etc/sftp/authorized_keys/%u

Desejo que vários clientes possam armazenar arquivos no meu servidor. Cada cliente não deve poder ver os arquivos de nenhum outro cliente. E não quero encher meu servidor com dezenas de contas de usuário. Por isso, gostaria de uma solução facilmente gerenciável para os clientes compartilharem uma conta de usuário e ainda não terem acesso aos arquivos de outros.

com o ProFTPD também é possível. Você só precisa modificar um pouco minha configuração inicial

<VirtualHost sftp.example.net>
    ...   
    SFTPAuthorizedUserKeys file:/etc/proftpd/sftp_authorized_keys
    AuthUserFile /etc/proftpd/sftp_users.passwd

    CreateHome on 0700 dirmode 0700 uid 99 gid 99

    RewriteHome on
    RewriteEngine on
    RewriteLog /var/log/proftpd/rewrite.log
    RewriteCondition %m REWRITE_HOME
    RewriteRule (.*) /vhosts/backup/%u
</VirtualHost>

E crie uma conta virtual

# ftpasswd --passwd --file /etc/proftpd/sftp_users.passwd --sha512 --gid 99 --uid 99 --shell /sbin/nologin --name user1 --home /vhosts/backup

Isso é tudo. Para cada conta adicional, tudo o que você precisa é adicionar sua chave pública às / etc / proftpd / sftp_authorized_keys

Nota: o arquivo deve conter uma nova linha no final! É importante.

o chroot=...não funciona.

Não, não há nada parecido na página de manual para sshddescrever o formato do authorized_keysarquivo.

Se você colocasse o chroot command=, não seria capaz de usá- internal-sftplo, porque é a substituição da chamada de função interna sshd.

A maneira recomendada é configurar mais usuários, se você precisar de separação. Você também pode usar argumentos para internal-sftp, se não precisar de uma separação estrita (por exemplo, apenas diretórios de trabalho diferentes), como

command="internal-sftp -d /backup/client-1/data" ssh-rsa (key1)

Também é possível limitar a quantidade de solicitações usando a -Popção como na página de manual de sftp-server.

Enquanto isso, eu vim com outra solução simples que também funciona bem, pelo menos no meu caso de uso:

Todo cliente se conecta ao servidor com a mesma conta de usuário e possivelmente até a mesma chave (não importa). O OpenSSH faz chroots em um diretório que possui a seguinte estrutura:

d--x--x---   dark-folder
drwxr-x---   |- verylongrandomfoldername1
drwxr-x---   |- verylongrandomfoldername2
drwxr-x---   `- ...

Juntamente com o comando backup, o servidor informa ao cliente o nome da pasta na qual ele deve colocar seus arquivos. Os nomes das pastas são seqüências aleatórias de 64 bytes praticamente impossíveis de serem adivinhadas; portanto, todo cliente pode realmente acessar sua própria pasta, mesmo que os outros estejam "em algum lugar no escuro".

o modo d - x - x-- na pasta escura garante que todo cliente possa entrar na pasta (e nas pastas abaixo), mas não pode listar seu conteúdo ou criar novas entradas.

As subpastas são criadas pelo processo do servidor de backup e a conexão entre cliente e pasta é armazenada (entre outras coisas) em um banco de dados sqlite.