Permitir que um usuário altere sua senha em um ambiente chrooted

Question

Estou tentando configurar um servidor ssh e sftp chroot no servidor Ubuntu 16.04.3 LTS. Eu segui este tutorial: link

Eu consegui trabalhar. Eu posso fazer ssh e sftp para o ambiente chrooted, mas não posso alterar a senha de um usuário chrooted. Eu tentei isso: -bash-4.3 $ passwd

mas eu tenho: passwd: não é possível determinar seu nome de usuário.

A propósito, eu também incluí o comando "/ usr / bin / passwd" no ambiente chrooted e copiei os arquivos: group, group-, gshadow, gshadow-, passwd e passwd- para o ambiente chrooted. / p>

Eu também percebi que, se eu fizer um "ls -l" no ambiente chrooted, os nomes dos grupos não serão exibidos. Eu vou ver coisas como: drwxr-xr-x 3 0 33 4096 15 fev 12:26 home

Mas no ambiente real, esta entrada se parece com: drwxr-xr-x 3 raiz www-data 4096 Feb 15 13:26 home

Se eu fizer sftp, então eu verei os nomes de usuários e grupos em vez de seus ids.

Qual poderia ser o problema? Eu realmente preciso que o usuário seja capaz de alterar sua própria senha.

Atenciosamente Josef

Aqui meu / etc / ssh / sshd_config:

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_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
AcceptEnv LANG LC_*
Subsystem sftp internal-sftp
UsePAM yes

Match group chrooted
    ChrootDirectory /home/ssh_chroot
    X11Forwarding no
    AllowTcpForwarding no
    #Uncomment to allow only sftp to the chrooted jail, ssh access will be denied
    #ForceCommand internal-sftp

Aqui minha estrutura de pastas:

/home/ssh_chroot
├── bin
│   ├── bash
│   ├── cat
│   ├── chown
│   ├── cp
│   ├── date
│   ├── ls
│   ├── mkdir
│   ├── mv
│   ├── rm
│   ├── rmdir
│   ├── sh
│   └── touch
├── dev
│   ├── null
│   ├── random
│   ├── tty
│   └── zero
├── etc
│   ├── group
│   ├── group-
│   ├── gshadow
│   ├── gshadow-
│   ├── hosts
│   ├── ld.so.cache
│   ├── ld.so.conf
│   ├── nsswitch.conf
│   ├── passwd
│   └── passwd-
├── home
│   └── chusr
├── lib
│   ├── libc.so.6
│   ├── libdl.so.2
│   ├── libncurses.so.5
│   ├── libtinfo.so.5
│   └── x86_64-linux-gnu
│       ├── libacl.so.1
│       ├── libattr.so.1
│       ├── libaudit.so.1
│       ├── libcrypt.so.1
│       ├── libc.so.6
│       ├── libdl.so.2
│       ├── libexpat.so.1
│       ├── libm.so.6
│       ├── libpam_misc.so.0
│       ├── libpam.so.0
│       ├── libpcre.so.3
│       ├── libpthread.so.0
│       ├── libselinux.so.1
│       ├── libtinfo.so.5
│       ├── libutil.so.1
│       └── libz.so.1
├── lib64
│   └── ld-linux-x86-64.so.2
├── sbin
│   └── unix_chkpwd
├── usr
│   ├── bin
│   │   ├── clear
│   │   ├── dircolors
│   │   ├── groups
│   │   ├── id
│   │   ├── passwd
│   │   ├── tree
│   │   └── vi
│   └── lib
│       └── x86_64-linux-gnu
│           ├── libgpm.so.2
│           └── libpython3.5m.so.1.0
└── var
    └── www

    

Answer 1

Minha pergunta ainda não está resolvida, mas acho que vou desistir dela. Acabei de dizer que é uma má ideia copiar os arquivos: group, group-, gshadow, gshadow-, passwd e passwd- e shadow para o novo ambiente.

Em vez de trabalhar com senhas, acho que tentarei resolver isso com chaves de autenticação. Para que o usuário possa gerar suas próprias chaves com alguma senha, então eu as carregarei para o servidor.

Essa abordagem ainda não é segura, já que o usuário trabalha com uma chave, mas acho que posso invalidá-la de tempos em tempos, ou seja: a cada 6 meses.

Para os interessados: não recebi o erro: " não é possível determinar seu nome de usuário. ". Em vez disso, eu tenho:

passwd: Authentication token manipulation error
passwd: password unchanged

depois de ter digitado a senha do usuário atual. Eu descobri que alguns arquivos não foram encontrados no ambiente chroot fazendo isso:

strace passwd

Particularmente eu observei os caminhos em cada chamada stat (), read (), open (), connect (), access (), statfs () e readlink (). Então copiei alguns arquivos ou pastas encadeadas e liguei / liguei alguns dispositivos. Mas eu não consegui funcionar.

De qualquer forma, desisti de fazer isso por dois motivos:

1. Um dos meus objetivos é esconder algumas partes do sistema no chroot. Howerver, se eu tivesse que copiar muitos arquivos do meu sistema principal, então, qual o sentido de fazer isso?

2. Eu também acho que duplicar o arquivo de senha principal tem alguns problemas: você o terá em dois lugares diferentes: no seu sistema principal e no chroot. Então, se eu colocar o comando "passwd", a nova senha será armazenada? Eu acho que na cópia chroot, então, da próxima vez que o usuário logar, sua senha ainda será a antiga armazenada no arquivo passwd principal, não é?

Estou apenas imaginando como as empresas de hospedagem resolvem isso com seus programas de "hospedagem compartilhada". Tenho sido cliente de vários deles e vejo que quando uso o acesso ssh que eles oferecem, vejo apenas um sistema limitado; até mesmo o arquivo de senha não está lá. Acho que só vi minha pasta pessoal e alguns arquivos de log dos meus sites.

    

Answer 2

OK, resolvi o problema da senha com uma chave pública e uma privada. O truque aqui é colocar a chave pública em: /home/your_user/.ssh/authorized_keys

Deve estar na raiz real e não na casa localizada dentro do chroot; caso contrário, a autenticação da chave não funcionará.

Apenas um problema permanece aqui e você não pode forçar senhas complexas. Se o usuário quiser, ele pode colocar uma frase vazia ou algo como: "1234".

Eu realmente gostaria de poder trabalhar com autenticação de senha. Você pode pelo menos forçar alguma complexidade de senha com o pam.