Não é possível obter o SFTP sem senha (fornecido pelo SSH)

Question

Eu configurei o sftp do chroot como abaixo.

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes
AllowGroups admins clients

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

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

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

#Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes



Subsystem sftp internal-sftp

Match group clients
    ChrootDirectory /var/chroot-home
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

um usuário fictício

root:~# tail -n1 /etc/passwd
david:x:1000:1001::/david:/bin/sh

Agora, neste caso o david pode usar o ftft usando o cliente filezilla e ele é chrooted para / var / chroot-home / david /. Mas e se eu fosse configurar uma autenticação sem senha? Eu tentei colar sua chave em /var/chroot-home/david/.ssh/authorized_keys mas não uso, tentei ssh'ing como david para a caixa e ele pára em "debug1: Env Env env LC_CTYPE = C" depois de eu fornecer a senha e não há nada mostrado no auth.log, pode ser porque não consegue encontrar o homedir. Se eu faço "su - david" como root eu vejo "Nenhum diretório, logando com HOME = /" que faz sentido. O Symlink também não ajuda.

Eu também tentei com:

Match group clients
        ChrootDirectory /var/chroot-home/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

um usuário fictício

root:~# tail -n1 /etc/passwd
david:x:1000:1001::/var/chroot-home/david:/bin/sh

Desta forma, se eu não mudar / var / chroot-home / david para root: root sshd reclama de propriedade incorreta ou modos de permissão, e se eu fizer isso, david não poderá mais carregar / apagar qualquer coisa diretamente em sua casa enquanto usando o sftp do filezilla.

    

Answer 1

Primeiramente, os diretórios base em /etc/passwd devem refletir os caminhos não-chrooted, ou você terá problemas em geral. Nesse caso, sshd verifica as chaves autorizadas antes de executar o chroot, portanto, ele precisa encontrá-las usando um caminho não chroot. É por isso que sua primeira tentativa não funciona.

Segunda coisa a ser notada: Em sua primeira configuração, quando david se conecta, ele inicia em /var/chroot-home/david , mas na verdade ele é chrooted para /var/chroot-home , o que significa que se ele digitar cd .. , ele poderá ver todos os outros diretórios (embora não o seu conteúdo, se as permissões estiverem corretas). Isso pode ou não ser um problema para você, mas é bom estar ciente disso.

Se estiver acima, você pode usar o seu primeiro sshd_config, configurar o diretório home do david para /var/chroot-home/david no arquivo passwd e adicionar o seguinte link simbólico para que o david ainda inicie em seu diretório home:

cd /var/chroot-home
mkdir var
ln -s .. var/chroot-home

Esse link simbólico irá garantir que você possa acessar um diretório inicial usando o mesmo caminho, esteja ou não no chroot.

No entanto, se você não quiser que os clientes vejam os nomes dos diretórios pessoais uns dos outros, será necessário fazer o chroot no próprio diretório inicial, como em sua segunda solução. Mas, como você viu, sshd não gosta disso (porque, por várias razões sutis, é perigoso permitir que um usuário grave acesso à raiz de um sistema de arquivos). Infelizmente, você está quase sem sorte aqui. Uma (kludgy) solução para isso é criar um subdiretório files/ em cada diretório inicial e fornecer ao cliente acesso de gravação para ele.

Outra opção pode ser chroot para / var / chroot-home de qualquer maneira e nomear os diretórios base de forma diferente, por exemplo, usando o número de ID do usuário em vez do nome.

    

Answer 2

Eu resolvi esse problema usando isto:

AuthorizedKeysFile /sftp/%u/.ssh/authorized_keys

Onde% u é o usuário do chRooted que está registrando.

Match Group sftp
   ChrootDirectory /sftp/%u

    

Answer 3

Você verificou as permissões de arquivo para .ssh e authorized_keys?

drwx------   .ssh/                   (chmod 0700)
-rw-------   .ssh/authorized_keys    (chomd 0600)

Pode ser óbvio, mas às vezes é negligenciado.

    

Answer 4

Você precisa criar um subdiretório na home chroot do usuário (/ var / chroot-home / david / incoming ou qualquer outro) e, em seguida, chown david:clients incoming e conceder permissões apropriadas com chmod 755 incoming .

Veja este post para detalhes.

Descobri que eu tinha que criar um chroot home (como descrito acima), mas também uma home real (/ home / david) para armazenar seu arquivo .ssh / authorized_keys. Eu acredito que isso é porque a autenticação SSH acontece antes do chroot, então o sshd não sabe procurar lá o arquivo .ssh.

Pensando nisso agora, provavelmente tentarei novamente usando seus diretórios pessoais reais como o chroot home: ainda é necessário criar uma pasta incoming , mas pelo menos .ssh estará onde ela é esperada.