# HOWTO native openssh chroot and SFTP

## m27315

Last Edit:  August 8, 2008

Objective:  Provide a transfer mechanism that is encrypted (SSL/SSH style), locks users to a jail (so they cannot browse your entire file system), and does not require you to maintain copies of libraries inside the jail (zero maintenance).

Solution:  Use the SFTP subsystem of openssh, along with its new, native chroot jail feature.

HOWTO:Make sure you are "root" (for the newbs)   :Smile: 

```
# su -

(enter root's password)
```

Currently, the prod version of openssh in portage (July 2, 2008:  net-misc/openssh-4.7_p1-r6) does not contain the native chroot feature.  Only versions 4.9, 5.0 and greater have this feature.  You will have to upgrade to an "unstable" version of openssh, although this should become unnecessary at some later date:

```
# echo "net-misc/openssh ~amd64" >> /etc/portage/package.keywords
```

Install the latest version of openssh:

```
# emerge -pvt openssh

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild   U   ] net-misc/openssh-5.0_p1-r1  USE="X pam tcpd -X509 -hpn -kerberos -ldap -libedit (-selinux) -skey -smartcard -static" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

(sanity check the various ebuilds)

# emerge openssh
```

One time setup:

Create an "sftponly" group (to be used later):

```
# groupadd sftponly
```

Modify SSH config (/etc/ssh/sshd_config):

```
Subsystem       sftp    internal-sftp

Match Group sftponly

        ChrootDirectory /home/%u

        ForceCommand internal-sftp

        AllowTcpForwarding no
```

This enables the native, internal SFTP server. It forces any user in the group "sftponly" to use the SFTP server, enables the native chroot feature for their home space, and it disables TCP forwarding.

Don't forget to restart ssh and add it to your box start-up, if you have not already:

```
# /etc/init.d/sshd restart

# rc-update add sshd default
```

 Optional, but handy one-time setup:

Using your favorite text editor, create this bash script to create users:

/root/bin/create_sftp_user.sh

```
#!/bin/bash

user=$1

if [ ! $user ]

then

    echo "(E) create_sftp_user.sh: No user specified!"

    echo -e "\nUsage:\n\n\tcreate_sftp_user.sh <username>"

    exit 1

fi

# OPTION A:  Choose visible, writable user directory

# OPTION A1:  username

#writable_dir=$user

# OPTION A2:  common convention, "public"

writable_dir=public

# Create User:

# OPTION B:  Choose shell

# OPTION B1: Use /bin/false as shell - requires for PAM either:

#            1) Removal of 'auth       required     pam_shells.so' from:

#               /etc/pam.d/sshd

#            2) Add /bin/false to acceptable shells:

#               echo '/bin/false' >> /etc/shells

useradd -g sftponly -s /bin/false -d /$writable_dir $user

# OPTION B2: Use /bin/bash as shell

#useradd -g sftponly -s /bin/bash -d /$writable_dir $user

# create user's home space

mkdir /home/$user

# make root owner of user's home - required by openssh for chroot feature

chown root:root /home/$user

# ensure nobody can write but root - required by openssh for chroot feature

chmod 755 /home/$user

# make writable dir for user

mkdir /home/$user/$writable_dir

# change owner of writable dir to user

chown $user:sftponly /home/$user/$writable_dir

# ensure the correct write permissions for user

chmod 755 /home/$user/$writable_dir

# OPTION C:  Choose password entry method

# OPTION C1:  Use hard-coded password - no interaction

#             set default password to "newP@$$w0rd"

echo -e "newP@\$\$w0rd\nnewP@\$\$w0rd" | passwd -q $user >& /dev/null

# OPTION C2:  Prompt user for password with confirmation

# passwd $user

# Verify /etc/passwd entry

echo -e "\nFinished. Here's the new line:\n\n" `grep $user /etc/passwd`

# exit successfully

exit 0
```

You have 3 groups of options, which are controlled by comments:

Name of user's visible home dir (username, "public", etc.)

Login shell:  /bin/false or /bin/bash - /bin/false is a more secure "shell", but requires relaxation of shell restriction in pam, which might open door for other account.  I'm no security expert, but the risk seems minuscule to me, either way.

Password entry method - hard-coded or interactive.

Don't forget to make your script editable:

```
# chmod u+x ~/bin/create_sftp_user.sh
```

Every time you want to create a new user with chrooted sftponly access, simply use the above script:

```
# ~/bin/create_sftp_user.sh <username>

New UNIX password: Retype new UNIX password: passwd: password updated successfully
```

Of course, you could hide the "passwd" output with a redirect to /dev/null, but I kind of like seeing the output.  ... You could also expose more internal options as command line arguments, like making the "writable_dir" optionally specified, or providing the password on the command line, etc.  But, this is good enough for me.   :Wink: 

You're done!  Try logging in with WinSCP or any other SFTP client.  All SSH clients should hang after entering the password, or produce "Access denied".The best part is you do not have copy and maintain various libraries and binaries any more!  The complete chroot functionality is now handled, and maintained inside openssh!  Just by simply keeping openssh up to date, you maintain the entire chroot-SFTP process!  :Cool: 

Resources:

http://www.minstrel.org.uk/papers/sftp/builtin.html

http://adamsworld.name/chrootjail5.php

HTH!Last edited by m27315 on Fri Aug 08, 2008 4:38 pm; edited 2 times in total

----------

## infernus

Alright. After a little trial and error I got it working (and with /bin/false too). Here are my files (I changed a few things)..

/etc/ssh/sshd_config:

```
# Example of overriding settings on a per-group basis

Match Group sftponly

   ChrootDirectory %h

   X11Forwarding no

   AllowTcpForwarding no

   ForceCommand internal-sftp
```

%h means home directory..

create_sftp_user.sh:

```
#!/bin/bash

user=$1

if [ ! $user ]

then

    echo "(E) create_sftp_user.sh: No user specified!"

    echo -e "\nUsage:\n\n\tcreate_sftp_user.sh <username>"

    exit 1

fi

writable_dir=public

# create user

useradd -g sftponly -s /bin/false -d /home/$user $user

# create user's home space

mkdir /home/$user

# make root owner of user's home - required by openssh for chroot feature

chown root:root /home/$user

# ensure nobody can write but root - required by openssh for chroot feature

chmod 755 /home/$user

# make writable dir for user

mkdir /home/$user/$writable_dir

# change owner of writable dir to user

chown $user:sftponly /home/$user/$writable_dir

# ensure the correct write permissions for user

chmod 755 /home/$user/$writable_dir

# No default password.. Set it manually.

passwd $user

# Show them we're finished.

echo ""

echo "Finished. Here's the new line:"

echo ""

echo `/bin/grep -i $user /etc/passwd`

exit 0
```

I changed it so that you have to manually type in a new password and it also displays the new line in /etc/passwd upon successful completion (notice the /bin/false up there)

To fix the /bin/false problem (assuming you are using PAM), you need to edit at least one file in /etc/pam.d.

/etc/pam.d/sshd:

```
#%PAM-1.0

auth     required pam_unix.so

auth     required pam_nologin.so

auth     required pam_env.so

account  required pam_unix.so

password required pam_unix.so shadow md5

session  required pam_unix.so

session  required pam_limits.so
```

There was a line there that said required pam_shells.so I believe. If yours has this line take it out and try again. Let me know if that helps..

----------

## m27315

Thanks for the tip on PAM!  Removing that line allowed me to use /bin/false.  Doing a little reading, I realized that I could also add "/bin/false" to "/etc/shells", but that would relax the shell restriction for all PAM authentication services, including login.  So, I opted to just remove the line from PAM's sshd config.  ... Even still, this method seems like it might increase the risk of other users (apache, mail, portage, etc.) from passing this PAM requirement and bring a hacker one step closer, since these users with the /bin/false shell would have otherwise been kicked out at this point.  ... Really, I think it's an academic discussion, since the shell (/bin/false) has no capability, but I thought it was interesting.

BTW, I incorporated several of your suggestions.  The only suggestion that I did not incorporate is the definition of the user's home.  FWIW, here's why I did it the above way:  

During SFTP login, the chroot feature is activated before the user is dropped into their home directory.  So, if you set a user's chroot jail to their home directory, then their home directory will not exist after chroot, unless you build a duplicate /home/$user directory inside the chroot jail.  

Personally, I don't like the extra levels of directory.  I want as few directories as possible inside the chroot jail, and I want the user to be dropped into their writable home directory immediately after login.  So, I set their home directory during user creation to be the writable dir, with respect to the chroot jail.  This prohibits me from using the "%h" variable in the sshd_config, but that is easily overcome using the "/home/%u" convention.  This way, I have minimal files & folders inside the jail, and the user does not have to change directories to start uploading files. ... Just a personal preference for a minor convenience.   :Smile: 

Thanks again for the help!  It is much appreciated!!

----------

## infernus

Glad I could help. Good luck with it. And thanks for the idea. I'm using it on my own machine now  :Smile: 

----------

## Anarcho

I would suggest that it might be better zu chroot to /home/ instead of /home/$user.

/home is already only writable by root so no changes here. But as the home-dir is writable by the user you can avoid creating the $writable_dir.

Of course you have to make sure that /home/$user is only accessable by $user.

----------

## mark_alec

Moved from Networking & Security to Documentation, Tips & Tricks.

----------

## m27315

 *Anarcho wrote:*   

> I would suggest that it might be better zu chroot to /home/ instead of /home/$user.
> 
> /home is already only writable by root so no changes here. But as the home-dir is writable by the user you can avoid creating the $writable_dir.
> 
> Of course you have to make sure that /home/$user is only accessable by $user.

 

That's an interesting idea, but wouldn't the other users be able to at least see the presence of the other user directories, even if they could not descend into them and browse their contents?  If you did not mind that, or especially if you wanted to enable browsing and sharing among the users, it would be really easy to do just as you described!  

Otherwise, I think you would want modify the user's umask to block all reading by group (since these users are all in sftponly) and others by default, like so:

/etc/login.defs

```
UMASK           077
```

Of course, this would affect all users, not just the sftponly group.  A better technique might be to use the pam_umask module in the /etc/pam.d/sshd to set the umask for all users, like so:

If you are using the /bin/bash shell, comment out the default umask setting:

/etc/profile

```
# 077 would be more secure, but 022 is generally quite realistic

#umask 022
```

This is not necessary, if the shell is /bin/false.

Add the following line to your PAM config for SSH:

/etc/pam.d/sshd

```
session    optional     pam_umask.so
```

Then set the umask for the user in the GECOS field of the passwd entry:

```
$ chfn -o umask=077 $user
```

Which might work best if added to the above script...

This will force all ssh users to pick up the default umask from /etc/login.defs, except for this user, who will get his umask from the GECOS field of his passwd entry, which can only be altered by root.    :Cool: 

Of course, WinSCP and other SFTP clients can change the permissions on each transfer, effectively overriding the default umask, but I thought it was an interesting idea.   :Smile: 

----------

## Erlend

I get,

```
[sshd] fatal: bad ownership or modes for chroot directory component "/"

```

My setup:

ls -l /home,

```
drwxr-xr-x   3 root   root     72 2008-08-08 13:45 sftpuser
```

sshd_config,

```
Subsystem    sftp    internal-sftp

Match group sftponly

    ForceCommand internal-sftp

    ChrootDirectory /home/%u

    AllowTcpForwarding no

    X11Forwarding no
```

----------

## m27315

hmmm, that sounds strange...  Would you mind posting the output of these commands?

```
# groups sftpuser

# ls -ld /

# grep sftpuser /etc/passwd

# emerge -pvt openssh

# cat /etc/pam.d/sshd
```

Did you deviate from the above procedure in any way?  Maybe that would offer a clue?

----------

## Erlend

 *m27315 wrote:*   

> 
> 
> Did you deviate from the above procedure in any way?  Maybe that would offer a clue?

 

I used rssh as the terminal, instead of /bin/false.

groups sftpuser:

```
sftponly
```

grep sftpuser /etc/passwd:

```
sftpuser:x:1002:1012::/sftpuser:/usr/bin/rssh
```

emerge -pvt openssh:

```
Calculating dependencies... done!

[ebuild   R   ] net-misc/openssh-5.0_p1-r2  USE="X pam tcpd -X509 -hpn -kerberos -ldap -libedit (-selinux) -skey -smartcard -static" 0 kB 
```

cat /etc/pam.d/sshd:

```
auth       include   system-remote-login

account    include   system-remote-login

password   include   system-remote-login

session      include   system-remote-login

```

----------

## m27315

What are the contents of the sftpuser's home dir:

```
# ls -la /home/sftpuser/
```

The sftpuser cannot actually write to this directory, so there should be a writable directory, created by root, that resides inside the user's space, like:

/home/sftpuser/sftpuser

-or-

/home/sftpuser/public

-or

/home/sftpuser/<writable_dir>

Whatever that writable dir name (not the full path) is, it should be the home for your sftpuser:

```
usermod -d /<writable_dir> sftpuser
```

You might try using bash as the shell, just to rule our rssh as a problem:

```
usermod -s /bin/bash sftpuser
```

HTH

----------

## Erlend

```
ls -la /home/sftpuser

total 0

drwxr-xr-x  3 root     root      72 2008-08-08 20:25 .

drwxr-xr-x 11 root     root     272 2008-08-08 20:25 ..

drwxr-xr-x  2 sftpuser sftponly  48 2008-08-08 20:25 public

```

```
usermod -d /public sftpuser
```

Yes - using that.

```
usermod -s /bin/bash sftpuser
```

Done this now.  No difference.

----------

## m27315

Just to make sure, would you post this result again:

```
# grep sftpuser /etc/passwd
```

I noticed earlier that the home dir was "/sftpuser", not "/public", which would cause you grief.  ... As a side note, this caused me to revisit my script and fix a bug, where I had set the user's home to $user instead of $writable_dir for the default option.    :Embarassed: 

And, please post this too:

```
ls -ld /
```

Otherwise, everything looks fine to me.  I don't know what the problem might be.  Maybe someone wiser can help.   :Smile: 

As a shot in the dark, to ensure all the processes and passwd files are in sync, have you rebooted yet?  In case you hacked on the /etc/passwd or /etc/groups files directly, or forgot to restart sshd, etc.

----------

## Erlend

 *m27315 wrote:*   

> Just to make sure, would you post this result again:
> 
> ```
> # grep sftpuser /etc/passwd
> ```
> ...

 

```
# grep sftpuser /etc/passwd

sftpuser:x:1003:1012::/public:/bin/bash

```

 *m27315 wrote:*   

> 
> 
> And, please post this too:
> 
> ```
> ...

 

```
rwxrwxr-x 20 root users 488 2008-08-08 17:21 /

```

----------

## m27315

I used the above script, after bug fix.  I used the sshd settings you posted.  And, I also could not log in.

```
Aug  8 15:26:13 [sshd] pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.12  user=sftpuser

Aug  8 15:26:15 [sshd] error: PAM: Authentication failure for sftpuser from 192.168.0.12

                - Last output repeated twice -

Aug  8 15:26:20 [sshd] Failed keyboard-interactive/pam for sftpuser from 192.168.0.12 port 1738 ssh2
```

Incidentally, I noticed that the default pam configs had been updated, which prohibited no-shell logins.  You seem to have picked these up, judging by your above post.  Anyway, I changed the shell:

```
# usermod -s /bin/bash
```

And, then I was able to login just fine with WinSCP, although I had also changed the password, during my debugging.

Here's my setup:

```
$ grep sftpuser /etc/passwd

sftpuser:x:1002:1003::/public:/bin/bash

$ ls -ld /

drwxr-xr-x 22 root root 4096 Jul 12 02:50 /

$ ls -ld /home

drwxr-xr-x 5 root root 4096 Aug  8 14:57 /home

$ ls -ld /home/sftpuser

drwxr-xr-x 3 root root 4096 Aug  8 14:57 /home/sftpuser

$ ls -ld /home/sftpuser/public

drwxr-xr-x 2 sftpuser sftponly 4096 Aug  8 15:31 /home/sftpuser/public

$ grep -v "^#" /etc/ssh/sshd_config

Protocol 2

PermitRootLogin no

MaxAuthTries 3

PasswordAuthentication no

UsePAM yes

AllowTcpForwarding no

MaxStartups 3

Banner /etc/security/banner.txt

AllowUsers sftpuser user1 user2 user3

Subsystem    sftp    internal-sftp

Match group sftponly

    ForceCommand internal-sftp

    ChrootDirectory /home/%u

    AllowTcpForwarding no

    X11Forwarding no

$ cat /etc/pam.d/sshd

auth       include      system-remote-login

account    include      system-remote-login

password   include      system-remote-login

session    include      system-remote-login

$ cat /etc/pam.d/system-remote-login

auth            include         system-login

account         include         system-login

password        include         system-login

session         include         system-login

$ cat /etc/pam.d/system-login

auth            required        pam_tally.so file=/var/log/faillog onerr=succeed

auth            required        pam_shells.so

auth            required        pam_nologin.so

auth            include         system-auth

account         required        pam_access.so

account         required        pam_nologin.so

account         include         system-auth

account         required        pam_tally.so file=/var/log/faillog onerr=succeed

password        include         system-auth

session         required        pam_env.so

session         optional        pam_lastlog.so

session         include         system-auth

session         optional        pam_motd.so motd=/etc/motd

session         optional        pam_mail.so
```

Are you still getting errors regarding chroot?  I never saw those.  What are you seeing in your logs?

If I modified the pam setup, I could go back to /bin/false for the shell, but I'm good.   :Smile: 

----------

## m27315

Try this:

```
# chmod 755 /

# chown root:root /
```

I put these commands in /etc/conf.d/local.start, because various packages tend to mess it up so often.

----------

## Erlend

 *m27315 wrote:*   

> Try this:
> 
> ```
> # chmod 755 /
> 
> ...

 

That fixed it - thanks!

----------

## m27315

Great!  Glad to help!

----------

## thrashed

hey dudes,

i configured the chroot scp service as mentioned above. first i ran into the permission issue. a good article about that --> http://www.tenshu.net/archives/2008/10/09/openssh-51-chrootdirectory-permissions-issue

i guess everything is configured ok, but when i try to login via winscp i get this error from winscp:

```
Error skipping startup message. Your shell is probably incompatible with the application (BASH is recommended).

```

It's like winscp is searching for /bin/bash in the chrooted directory. this is my scp-user. it doesnt matter if i change the login shell to /bin/bash or /bin/false or something else.

```
scptestuser :x:1001:1006::/somewebsite:/bin/false
```

this is the debug log from the ssh-service during the winscp-login

```
Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8

Nov 19 21:49:03 thrash01srv sshd[26478]: debug1: Forked child 10925.

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: inetd sockets after dupping: 3, 3

Nov 19 21:49:03 thrash01srv sshd[10925]: Connection from 192.168.0.20 port 2342

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: Client protocol version 2.0; client software version WinSCP_release_4.1.6

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: no match: WinSCP_release_4.1.6

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: Enabling compatibility mode for protocol 2.0

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: Local version string SSH-2.0-OpenSSH_5.1

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: user scptestuser matched group list sftponly at line 112

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: PAM: initializing for "scptestuser"

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: PAM: setting PAM_RHOST to "192.168.0.20"

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: PAM: setting PAM_TTY to "ssh"

Nov 19 21:49:03 thrash01srv sshd[10925]: Failed none for scptestuser from 192.168.0.20 port 2342 ssh2

Nov 19 21:49:03 thrash01srv sshd[10933]: debug1: do_pam_account: called

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: PAM: num PAM env strings 0

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: do_pam_account: called

Nov 19 21:49:03 thrash01srv sshd[10925]: Accepted keyboard-interactive/pam for scptestuser from 192.168.0.20 port 2342 ssh2

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: monitor_child_preauth: scptestuser has been authenticated by privileged process

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: PAM: establishing credentials

Nov 19 21:49:03 thrash01srv sshd[10925]: pam_unix(sshd:session): session opened for user scptestuser by (uid=0)

Nov 19 21:49:03 thrash01srv sshd[10934]: debug1: PAM: establishing credentials

Nov 19 21:49:03 thrash01srv sshd[10925]: User child is on pid 10934

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: PAM: cleanup

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: PAM: deleting credentials

Nov 19 21:49:03 thrash01srv sshd[10925]: debug1: PAM: closing session

Nov 19 21:49:03 thrash01srv sshd[10925]: pam_unix(sshd:session): session closed for user scptestuser

```

some ideas, what could be wrong?

thx!

here some configs:

sshd_config

```
....

....

   Match Group sftponly

   ChrootDirectory /var/www/localhost/htdocs/somewebsite

   X11Forwarding no

   AllowTcpForwarding no

   ForceCommand sftp-server
```

/etc/pam.d/sshd

```
auth     required pam_unix.so

auth     required pam_nologin.so

auth     required pam_env.so

account  required pam_unix.so

password required pam_unix.so shadow md5

session  required pam_unix.so

session  required pam_limits.so

```

----------

## m27315

Hey thrashed,

Nothing jumps out at me, although several questions came to mind.  Would you mind reporting all the relevant info, like I did in the above post:

https://forums.gentoo.org/viewtopic-p-5177319.html#5177319

This will help troubleshoot.

Also, I can't promise that I will be able to look at this soon.  Maybe someone else will have time?  Regardless, the above info will be needed, unless someone else recognizes a clear symptom of a known issue.  I did not.   :Sad: 

----------

## Naib

put it on the wiki!

----------

## MarcusXP

I managed to create users successfully and the permissions are working nicely (they can only write to the public folder and they are locked in the home folder).

I have an issue, though:

 how do I set a limit for download/upload speed of the users I created?

----------

## m27315

 *MarcusXP wrote:*   

> how do I set a limit for download/upload speed of the users I created?

 

I am unaware of any way to limit SFTP or SSH traffic.  (SCP does have the -l option.)  Unless a new feature has recently been added to SSH, you will have to use an external traffic shaper, or bandwidth limiter, like:  iptables, trickle, or the like.

Google turned up some interesting threads in other forums and on other mailing lists:

http://www.gossamer-threads.com/lists/openssh/users/45280

http://www.gossamer-threads.com/lists/openssh/users/45280

http://www.nabble.com/Limit-ssh-bandwidth-td15964326.html

http://www.nabble.com/Re:-Limit-ssh-bandwidth---sftp-bandwidth-td15982660.html

http://www.yak.net/fqa/404.html

http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2006-04/msg00043.html

HTH

----------

## EstebanGonzales

I cant seem to login in through scp with this script any ideas what the problem is. 

Been trying to find a solution to this for days now

----------

## m27315

The problem could be anything.  Please post relevant snippets from your log files, configs, shell transcripts, error messages, etc..  Read through the above posts to pick out the important pieces required to debug.

----------

## EstebanGonzales

Ok here we go. 

```
TestServer ~ # groups sftpuser

sftpuser

TestServer ~ #

```

```
TestServer ~ # ls -ld /

drwxr-xr-x 20 root root 4096 Oct 18 11:43 /

TestServer ~ #

```

```
TestServer ~ # grep sftpuser /etc/passwd

sftpuser:x:1005:1005::/home/sftpuser:/bin/bash
```

```
TestServer ~ # emerge -pvt openssh

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild     U ] net-misc/openssh-5.6_p1-r2 [5.5_p1-r2] USE="ldap* pam tcpd -X -X509 -hpn -kerberos -libedit (-selinux) -skey -static" 1,110 kB

Total: 1 package (1 upgrade), Size of downloads: 1,110 kB

 * IMPORTANT: 2 news items need reading for repository 'gentoo'.

 * Use eselect news to read news items.

TestServer ~ #
```

```

TestServer ~ # cat /etc/pam.d/sshd

auth       include      system-remote-login

account    include      system-remote-login

password   include      system-remote-login

session    include      system-remote-login

```

Does that help at all ?

----------

## m27315

It's been a while, so here are relevant snippets from my current configs as of October 18, 2010. ... You should compare your files and the following commands on the host server, (the one your are logging into).  If the results are identical, you will need to post your syslog/metalog record of the event.

HTH

/etc/pam.d/sshd:

```
auth       include      system-remote-login

account    include      system-remote-login

password   include      system-remote-login

session    include      system-remote-login
```

Mostly defaults in the next one too, but look near the end for SFTP config...

/etc/ssh/sshd_config:

```
#       $OpenBSD: sshd_config,v 1.81 2009/10/08 14:03:41 markus Exp $

# This is the sshd server system-wide configuration file.  See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented.  Uncommented options change a

# default value.

#Port 22

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::

# The default requires explicit activation of protocol 1

#Protocol 2

# HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h

#ServerKeyBits 1024

# Logging

# obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

#LogLevel INFO

# Authentication:

#LoginGraceTime 2m

PermitRootLogin no

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

#RSAAuthentication yes

#PubkeyAuthentication yes

#AuthorizedKeysFile     .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

# similar for protocol version 2

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

PasswordAuthentication no

#PermitEmptyPasswords no

# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no

# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing, 

# and session processing. If this is enabled, PAM authentication will 

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication.  Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

UsePAM yes

#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

PrintMotd yes

PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

#UsePrivilegeSeparation yes

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS yes

#PidFile /var/run/sshd.pid

#MaxStartups 10

#PermitTunnel no

#ChrootDirectory none

# no default banner path

#Banner none

AllowGroups root wheel sftponly

AllowUsers root sftpuser

# override default of no subsystems

#Subsystem      sftp    /usr/lib64/misc/sftp-server

Subsystem       sftp internal-sftp

Match Group sftponly

        ChrootDirectory /home/%u

        ForceCommand internal-sftp

        AllowTcpForwarding no

# Example of overriding settings on a per-user basis

#Match User anoncvs

#       X11Forwarding no

#       AllowTcpForwarding no

#       ForceCommand cvs server
```

Make sure your permissions are all correct:

```
# grep -i mask /etc/login.defs 

UMASK           022

# grep sftpuser /etc/passwd

sftpuser:x:1001:1001::/public:/bin/false

# groups sftpuser

sftponly

# ls -latd /home

drwxr-xr-x 4 root root 4096 Jan 15  2009 /home

# ls -latd /home/sftpuser

drwxr-xr-x 3 root root 4096 Jan 15  2009 /home/sftpuser

# ls -latd /home/sftpuser/public

drwxr-xr-x 4 sftpuser sftponly 73728 Oct  9 17:23 /home/sftpuser/public
```

----------

