I'm building a UVPS for myself, just to use as a simple playground. The user I need to have sftp access authenticates but get's booted. I believe it's due to my hardening, but it could be something I just am oblivious to or don't know. Can anyone help using the following info?
I've installed Ubuntu 10.04 and hardened it up pretty well (for my non sys admin knowledge-base), but I am having trouble connecting via SFTP via a limited user setup to be the only SFTP user (will also likely be used for rsync/git/hg access but one thing at a time). I want this user restricted to it's home - so I've put that in the sshd_config.
The configuration consists exclusively of a Sudo user we'll call sudouser and a sftp user we'll call sftpuser.
Obfuscated sshd_config file:
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
I have generated a rsa key pair for sftpuser placed it's public in ~sftpuser/.ssh/ with sftpuser having 700 on it's .ssh directory and 600 on it's public key.
When attempting to connect via sftp in Netbeans, I get the following message:
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
It also connects with cyberduck, but immediately disconnects.
Some other details for anyone who might be interested in helping.
iptable rules:
*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 Hardening
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: Response to poisonbit and Gilles (since there's overlap)
In the logs I do see it's an ownership issue. My understanding (or lack there of) is that when I adduser as root, the permissions and files created from /etc/skeleton should be right… for this - but now I'm confused.
This was all done as 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
Examining the permissions, here's what I see:
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
Should these be owned by root?
Are there files/folders that are not created by adduser that are needed to make a basic user?
I do apologize, I'm capable as a basic user of linux... but while most things are logical once you "get it" I feel like I'm always reading explanations of minutia/quirks in the manpages or google results when doing simple things.
============================================================
EDIT02: Relevant /var/log/auth.log entries.
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
The pam messages seem related to a bug Ubuntu Bug #155794 and likely aren't contributing - the fatal entry on the other hand :p
============================================================
EDIT03: Update.
Changing the owner of ~sftpuser recursively caused authentication to fail. By returning ownership of ~sftpuser/.ssh (-R) to sftpuser the sftp client could connect. The new log entries were:
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
So perhaps the PAM bug (or the default config as provided by ubuntu) is in need of some love. I'm reading about PAM, and it's so much more than I was hoping to get into just to get a simple sandboxed sftp operator in place. Hmmm.
============================================================
EDIT04: Reasonable confirmation.
Disabling PAM in the sshd_config file made it work. So at this point anyone who follows this as reference in the future should be able to get this going w/o PAM. As to PAM, I need to evaluate why I may/not need it and if/when I wrap my head around it and determine if it being on offers any substantial benefit for my uses, I'll update this.
Many thanks to the people that contributed... you led me to the problem and made it clear I really need to get better at logging, and analyzing the logs. Frankly using ubuntudesktop/osx/windows has never really caused me need to spend a great deal of time in the logs. Configuring even a simple server however... Who can I credit the answer with? Everyone helped.
============================================================
EDIT05: Quirk?.
Re-enabled PAM to do the deeper logging that was recommended and reloaded SSH... and everything continued to work as it did with PAM disabled. o.O
