Настройка простого изолированного sftp для одного пользователя

Я строю UVPS для себя, просто чтобы использовать его как простую площадку. Пользователь, которому мне нужен sftp-доступ, аутентифицируется, но загружается. Я считаю, что это из-за моей жесткости, но это может быть то, о чем я просто не замечаю или не знаю. Может ли кто-нибудь помочь, используя следующую информацию?

Я установил Ubuntu 10.04 и довольно хорошо укрепил его (для моей базы знаний, не связанной с системным администратором), но у меня возникают проблемы с подключением через SFTP через ограниченную настройку пользователя, чтобы быть единственным пользователем SFTP (также, вероятно, будет использоваться для rsync / git / hg доступ, но по одному за раз). Я хочу, чтобы этот пользователь был ограничен своим домом - поэтому я поместил это в файл sshd_config.

Конфигурация состоит исключительно из пользователя Sudo, которого мы назовем Sudouser и пользователя sftp мы назовем sftpuser.

Обфусцированный файл sshd_config:

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

Я создал пару ключей rsa для sftpuser и разместил ее публично в ~ sftpuser / .ssh / с sftpuser имея 700 в каталоге .ssh и 600 в открытом ключе.

При попытке подключиться через sftp в Netbeans я получаю следующее сообщение:

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

Он также подключается к cyberduck, но сразу отключается.

Некоторые другие подробности для всех, кто может быть заинтересован в помощи.

Правила 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

Разное упрочнение

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: ответ на отраву и Жиля (поскольку есть совпадение)

В журналах я вижу, что это проблема с правом собственности. Мое понимание (или отсутствие такового) состоит в том, что когда я являюсь пользователем как root, разрешения и файлы, созданные из / etc / skeleton, должны быть правильными… для этого - но теперь я запутался.

Все это было сделано с правами 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

Исследуя разрешения, я вижу следующее:

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

Должны ли они принадлежать root?

Есть ли файлы / папки, которые не созданы Добавить пользователя что нужно сделать базовому пользователю?

Прошу прощения, я способен как базовый пользователь Linux ... но хотя большинство вещей логичны, как только вы "понимаете", мне кажется, что я всегда читаю объяснения мелочей / причуд на страницах руководства или в результатах Google, когда выполняю простые вещи.

============================================================

EDIT02: соответствующие записи /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

Сообщения pam кажутся связанными с ошибкой Ubuntu Bug # 155794 и, вероятно, не вносят свой вклад - фатальный вход с другой стороны: p

============================================================

EDIT03: Обновление.

Изменение владельца ~ sftpuser рекурсивно приводило к сбою аутентификации. Вернув право собственности на ~ sftpuser / .ssh (-R) на sftpuser клиент sftp мог подключиться. Новые записи журнала были:

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

Так возможно ошибка PAM (или конфигурация по умолчанию, предоставляемая ubuntu) нуждается в некоторой любви. Я читаю о PAM, и это намного больше, чем я надеялся, просто чтобы получить простой изолированный оператор sftp на месте. Хммм.

============================================================

EDIT04: разумное подтверждение.

Отключение PAM в файле sshd_config заставило его работать. Так что на этом этапе любой, кто будет следовать этому как справочнику в будущем, сможет начать это без PAM. Что касается PAM, мне нужно оценить, почему он мне может / не нужен, и если / когда я обернусь вокруг него и определю, предлагает ли он какое-либо существенное преимущество для моего использования, я обновлю это.

Большое спасибо людям, которые внесли свой вклад ... вы привели меня к проблеме и ясно дали понять, что мне действительно нужно улучшить ведение журнала и анализ журналов. Откровенно говоря, использование ubuntudesktop / osx / windows никогда не заставляло меня тратить много времени на журналы. Однако настройка даже простого сервера ... Кому я могу доверять ответ? Все помогли.

============================================================

EDIT05: Причуда ?.

Повторно включил PAM для более глубокого ведения журнала, который был рекомендован, и перезагрузил SSH ... и все продолжало работать, как и с отключенным PAM. o.O