Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
What is in the server logs? Are you sure you've created all the necessary files in the chroot? –  Gilles Apr 10 '11 at 18:53
    
Edited a response (in the main question) to both you and poisonbit and reviewing the logs points to an ownership issue. I appreciate the response. –  Cor Apr 11 '11 at 0:01
    
If you don't post the logs, we can't help you read them. The permissions look right for functionality, but /home/sftpuser, /home/sftpuser/.ssh and /home/sftpuser/.ssh/* should be owned by root, otherwise the SFTP user will be able to write to them and may be able to gain shell access (I'm not sure about that). –  Gilles Apr 11 '11 at 0:09
    
I agree with Gilles. For what it's worth, adduser's default permissions are fine for normal login users, but do not work well with sftp. –  justarobert Apr 11 '11 at 0:38
    
Added relevant logs in main question –  Cor Apr 11 '11 at 0:40

2 Answers 2

up vote 0 down vote accepted

Under Subsystem and ForceCommand change

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

to

Subsystem       sftp    internal-sftp

and change

ForceCommand /usr/lib/openssh/sftp-server

to

ForceCommand internal-sftp
share|improve this answer
    
Thanks. Just tried... exact same result as the latest logs (EDIT03 above). Definitely worth a try. –  Cor Apr 11 '11 at 2:48
    
Before I move on, you did restart ssh after changing correct? –  rfelsburg Apr 11 '11 at 2:55
    
Yes... and I even meant to mention that - long day. /etc/init.d/ssh reload –  Cor Apr 11 '11 at 2:58
    
What is your log verbosity set to? If it's not set to debug please do so, and try logging in again and posting the results. –  rfelsburg Apr 11 '11 at 3:01
    
Just tried disabling PAM in the sshd_config and was able to gain access. So it looks like a misconfigured PAM is the culprit (or the bug I noted above). Don't know that I actually need PAM... but at least there's some clear and apparent cause here. Thanks again for responding. Off to update the main question. –  Cor Apr 11 '11 at 3:10

Authentication succeeded (publickey). So it should be something after that... lets check:

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.

...

Is the home of the sftpuser user (and parent paths) owned by root and 700 (drwx------) ?

If owners of directories are ok, and write perms too, you can search for more info in /var/log on the ssh server, or try the sftp client from command line, adding the -v option, and send us the output.

share|improve this answer
    
Edited a response to both you and Gilles (in the main question) and reviewing the logs points to an ownership issue. I appreciate the response. Any thoughts on where my efforts are breaking down? I'm googling how to connect to sftp from the shell right now (and will dump a -v if it turns out that the permissions are appropriate.) –  Cor Apr 11 '11 at 0:03
    
Okay so I have re-read this answer and run chown -R on ~sftpuser and the authorization fails. By making ~sftpuser/.ssh owned by sftpuser again I can authorize and I get a new log saying "subsystem request for sftp"!!! but then pam ends the session again. Progress ;p –  Cor Apr 11 '11 at 1:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.