Sob o Subsistema e o ForceCommand, altere
Subsystem sftp /usr/lib/openssh/sftp-server
para
Subsystem sftp internal-sftp
e altere
ForceCommand /usr/lib/openssh/sftp-server
para
ForceCommand internal-sftp
Estou construindo um UVPS para mim, apenas para usar como um playground simples. O usuário que eu preciso ter acesso sftp autentica mas é iniciado. Eu acredito que é devido ao meu endurecimento, mas pode ser algo que eu simplesmente não conheço ou não sei. Alguém pode ajudar usando as seguintes informações?
Instalei o Ubuntu 10.04 e o endureitei muito bem (para minha base de conhecimento não sys admin), mas estou tendo problemas para conectar via SFTP por meio de uma configuração de usuário limitada para ser o único usuário SFTP (também provavelmente usado para acesso rsync / git / hg, mas uma coisa por vez). Eu quero esse usuário restrito a ele - então coloquei isso no sshd_config.
A configuração consiste exclusivamente de um usuário do Sudo que chamaremos sudouser e um usuário do sftp que chamaremos de sftpuser .
Arquivo sshd_config ofuscado:
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
UseDNS no
AllowUsers sudouser sftpuser
Match User sftpuser
ChrootDirectory %h
ForceCommand /usr/lib/openssh/sftp-server
AllowTcpForwarding no
Eu criei um par de chaves rsa para o sftpuser, que é público em ~ sftpuser / .ssh / com sftpuser , tendo 700 em seu diretório .ssh e 600 em sua chave pública.
Ao tentar se conectar via sftp no Netbeans, recebo a seguinte mensagem:
Host '123.45.678.910' is known and mathces the RSA host key
SSH_MSG_NEWKEYS sent
SSH_MSG_NEWKEYS received
SSH_MSG_SERVICE_REQUEST sent
SSH_MSG_SERVICE_ACCEPT received
Authentications that can continue: publickey,keyboard-interactive,password
Next authentication method: publickey
Authentication succeeded (publickey).
Caught an exception, leaving main loop due to Connection reset
Disconnecting from 123.45.678.910 port 22
QUIT
Goodbye
Ele também se conecta ao cyberduck, mas desconecta imediatamente.
Alguns outros detalhes para qualquer pessoa que possa estar interessada em ajudar.
regras de iptable:
*filter
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -j ACCEPT
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j REJECT
-A FORWARD -j REJECT
COMMIT
Misc Enduring
dpkg-statoverride --update --add root sudoers 4750 /bin/su
sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
sudo sysctl -w net.ipv4.conf.default.accept_source_route=0
============================================================
EDIT01: Resposta ao poisonbit e Gilles (desde que haja sobreposição)
Nos registros, vejo que é um problema de propriedade. Meu entendimento (ou falta disso) é que quando eu adiciono o usuário como root, as permissões e arquivos criados a partir do / etc / skeleton devem estar certos ... para isso - mas agora estou confuso.
Tudo isso foi feito como root.
/usr/sbin/groupadd sudoers
/usr/sbin/adduser sudouser
mkdir ~sudouser/.ssh
mv /tmp/uploadpackage/sudouser.pub ~sudouser/.ssh/authorized_keys
chown -R sudouser:sudouser ~sudouser/.ssh
chmod 700 ~sudouser/.ssh
chmod 600 ~sudouser/.ssh/authorized_keys
/usr/sbin/usermod -a -G sudoers sudouser
:modified visudo:
/usr/sbin/adduser sftpuser
mkdir ~sftpuser/.ssh
mv /tmp/uploadpackage/sftpuser.pub ~sftpuser/.ssh/authorized_keys
chown -R sftpuser:sftpuser ~sftpuser/.ssh
chmod 700 ~sftpuser/.ssh
chmod 600 ~sftpuser/.ssh/authorized_keys
Examinando as permissões, aqui está o que eu vejo:
sudouser @ uvps: ~ $ sudo ls -l /
<snip>
drwxr-xr-x 4 root root 4096 Apr 10 16:39 home
<snip>
sudouser @ uvps: ~ $ ls -l / home
drwxr-xr-x 4 sftpuser sftpuser 4096 Apr 10 17:03 sftpuser
drwxr-xr-x 4 sudouser sudouser 4096 Apr 10 16:58 sudouser
Esses devem ser de propriedade do root?
Existem arquivos / pastas que não são criados pelo adduser necessários para criar um usuário básico?
Peço desculpas, sou capaz como usuário básico do linux ... mas enquanto a maioria das coisas são lógicas uma vez que você "entende" eu sinto que estou sempre lendo explicações de minutia / quirks nas manpages ou no google resultados ao fazer coisas simples.
============================================================
EDIT02: Entradas relevantes do /var/log/auth.log.
Apr 11 00:18:22 uvps sshd[8694]: Accepted publickey for sftpuser from 109.87.654.321 port 55555 ssh2
Apr 11 00:18:22 uvps sshd[8694]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Apr 11 00:18:22 uvps sshd[8694]: pam_unix(sshd:session): session opened for user sftpuser by (uid=0)
Apr 11 00:18:22 uvps sshd[8706]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Apr 11 00:18:22 uvps sshd[8706]: fatal: bad ownership or modes for chroot directory "/home/sftpuser"
Apr 11 00:18:22 uvps sshd[8694]: pam_unix(sshd:session): session closed for user sftpuser
Apr 11 00:18:22 uvps sshd[8694]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
As mensagens pam parecem relacionadas a um bug Ubuntu Bug # 155794 e provavelmente não estão contribuindo - a entrada fatal por outro lado: p
============================================================
EDIT03: atualização.
A alteração do proprietário do ~ sftpuser fez com que a autenticação falhasse recursivamente. Ao retornar a propriedade de ~ sftpuser / .ssh (-R) para sftpuser , o cliente sftp pôde se conectar. As novas entradas de log foram:
Apr 11 01:02:36 uvps sshd[8745]: Accepted publickey for sftpuser from 109.87.654.321 port 55555 ssh2
Apr 11 01:02:36 uvps sshd[8745]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Apr 11 01:02:36 uvps sshd[8745]: pam_unix(sshd:session): session opened for user sftpuser by (uid=0)
Apr 11 01:02:36 uvps sshd[8756]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Apr 11 01:02:36 uvps sshd[8756]: subsystem request for sftp
Apr 11 01:02:36 uvps sshd[8745]: pam_unix(sshd:session): session closed for user sftpuser
Apr 11 01:02:36 uvps sshd[8745]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory
Então talvez o bug do PAM (ou a configuração padrão como fornecida pelo Ubuntu) está precisando de algum amor. Eu estou lendo sobre o PAM, e é muito mais do que eu esperava entrar apenas para ter um simples operador sftp em sandbox no lugar. Hmmm.
============================================================
EDIT04: Confirmação razoável.
A desativação do PAM no arquivo sshd_config fez com que funcionasse. Então, neste ponto, qualquer um que siga isso como referência no futuro deve ser capaz de fazer isso sem o PAM. Quanto ao PAM, eu preciso avaliar porque eu posso / não precisar dele e se / quando eu envolver minha cabeça em torno dele e determinar se ele está oferecendo algum benefício substancial para meus usos, eu atualizarei isso.
Muito obrigado às pessoas que contribuíram ... você me levou ao problema e deixou claro que eu realmente preciso melhorar o registro e analisar os logs. Francamente, usar o ubuntudesktop / osx / windows nunca me fez realmente precisar gastar muito tempo nos logs. Configurando até mesmo um servidor simples, no entanto ... Com quem posso creditar a resposta? Todos ajudaram.
============================================================
EDIT05: Quirk?.
PAB habilitado para fazer o registro mais profundo que foi recomendado e recarregado SSH ... e tudo continuou funcionando como aconteceu com o PAM desativado. o.O
Autenticação bem sucedida (publickey). Então deve ser algo depois disso ... vamos conferir:
ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after
authentication. All components of the pathname must be root-
owned directories that are not writable by any other user or
group. After the chroot, sshd(8) changes the working directory
to the user's home directory.
...
A casa do usuário do sftpuser (e caminhos pai) é de propriedade de root e 700 (drwx ------)?
Se os proprietários dos diretórios estiverem ok, e escreva perms também, você pode procurar por mais informações em / var / log no servidor ssh, ou tentar o cliente sftp a partir da linha de comando, adicionando o -v opção, e envie-nos a saída.