Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HOWTO native openssh chroot and SFTP
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Wed Jul 02, 2008 8:07 pm    Post subject: HOWTO native openssh chroot and SFTP Reply with quote

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:
  1. Make sure you are "root" (for the newbs) :)

    Code:
    # su -
    (enter root's password)

  2. 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:

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

  3. Install the latest version of openssh:

    Code:
    # 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

  4. One time setup:

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

    Code:
    # groupadd sftponly

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

    Code:
    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:

    Code:
    # /etc/init.d/sshd restart
    # rc-update add sshd default

  5. Optional, but handy one-time setup:

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

    /root/bin/create_sftp_user.sh
    Code:
    #!/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:
    1. Name of user's visible home dir (username, "public", etc.)
    2. 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.
    3. Password entry method - hard-coded or interactive.

    Don't forget to make your script editable:

    Code:
    # chmod u+x ~/bin/create_sftp_user.sh

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

    Code:
    # ~/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. ;)

  7. 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! 8)

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
Back to top
View user's profile Send private message
infernus
n00b
n00b


Joined: 11 Jan 2008
Posts: 24
Location: US

PostPosted: Sat Jul 05, 2008 1:30 am    Post subject: Reply with quote

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:
Code:
# 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:
Code:
#!/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:
Code:
#%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..
_________________
--
Sal.

Linux latitude 2.6.25-hardened-r4 #1 SMP Sat Aug 23 15:23:14 EDT 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Tue Jul 08, 2008 2:37 pm    Post subject: Thanks! Reply with quote

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. :)

Thanks again for the help! It is much appreciated!!
Back to top
View user's profile Send private message
infernus
n00b
n00b


Joined: 11 Jan 2008
Posts: 24
Location: US

PostPosted: Tue Jul 08, 2008 8:38 pm    Post subject: Reply with quote

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

Linux latitude 2.6.25-hardened-r4 #1 SMP Sat Aug 23 15:23:14 EDT 2008 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux
Back to top
View user's profile Send private message
Anarcho
Advocate
Advocate


Joined: 06 Jun 2004
Posts: 2959
Location: Wuppertal (Germany)

PostPosted: Wed Jul 09, 2008 8:50 am    Post subject: Reply with quote

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.
_________________
...it's only Rock'n'Roll, but I like it!
HOWTO:WLAN mit OpenVPN absichern | TOOL:useedit - USE-flag editor/changer
Back to top
View user's profile Send private message
mark_alec
Bodhisattva
Bodhisattva


Joined: 11 Sep 2004
Posts: 6066
Location: Melbourne, Australia

PostPosted: Wed Jul 09, 2008 12:46 pm    Post subject: Reply with quote

Moved from Networking & Security to Documentation, Tips & Tricks.
_________________
www.gentoo.org.au || #gentoo-au
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Wed Jul 09, 2008 3:09 pm    Post subject: Reply with quote

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
Code:
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:
  1. If you are using the /bin/bash shell, comment out the default umask setting:

    /etc/profile
    Code:
    # 077 would be more secure, but 022 is generally quite realistic
    #umask 022

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

  2. Add the following line to your PAM config for SSH:

    /etc/pam.d/sshd
    Code:
    session    optional     pam_umask.so


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

    Code:
    $ 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. 8)

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. :)
Back to top
View user's profile Send private message
Erlend
Guru
Guru


Joined: 26 Dec 2004
Posts: 484

PostPosted: Fri Aug 08, 2008 1:00 pm    Post subject: Reply with quote

I get,
Code:
[sshd] fatal: bad ownership or modes for chroot directory component "/"


My setup:

ls -l /home,
Code:
drwxr-xr-x   3 root   root     72 2008-08-08 13:45 sftpuser


sshd_config,
Code:
Subsystem    sftp    internal-sftp

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /home/%u
    AllowTcpForwarding no
    X11Forwarding no

_________________
Thunar-thumbnailers
Raw-thumbnailer
http://brainstorm.ubuntu.com/idea/6878/image/1/
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Fri Aug 08, 2008 2:44 pm    Post subject: Reply with quote

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

Code:
# 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?
Back to top
View user's profile Send private message
Erlend
Guru
Guru


Joined: 26 Dec 2004
Posts: 484

PostPosted: Fri Aug 08, 2008 4:20 pm    Post subject: Reply with quote

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:
Code:
sftponly


grep sftpuser /etc/passwd:
Code:
sftpuser:x:1002:1012::/sftpuser:/usr/bin/rssh


emerge -pvt openssh:
Code:
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:
Code:
auth       include   system-remote-login
account    include   system-remote-login
password   include   system-remote-login
session      include   system-remote-login

_________________
Thunar-thumbnailers
Raw-thumbnailer
http://brainstorm.ubuntu.com/idea/6878/image/1/
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Fri Aug 08, 2008 4:37 pm    Post subject: Reply with quote

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

Code:
# 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:

Code:
usermod -d /<writable_dir> sftpuser

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

Code:
usermod -s /bin/bash sftpuser


HTH
Back to top
View user's profile Send private message
Erlend
Guru
Guru


Joined: 26 Dec 2004
Posts: 484

PostPosted: Fri Aug 08, 2008 7:31 pm    Post subject: Reply with quote

Code:
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


Code:
usermod -d /public sftpuser

Yes - using that.

Code:
usermod -s /bin/bash sftpuser

Done this now. No difference.
_________________
Thunar-thumbnailers
Raw-thumbnailer
http://brainstorm.ubuntu.com/idea/6878/image/1/
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Fri Aug 08, 2008 7:42 pm    Post subject: Reply with quote

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

Code:
# 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. :oops:

And, please post this too:

Code:
ls -ld /

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

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.
Back to top
View user's profile Send private message
Erlend
Guru
Guru


Joined: 26 Dec 2004
Posts: 484

PostPosted: Fri Aug 08, 2008 8:43 pm    Post subject: Reply with quote

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

Code:
# 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. :oops:

Code:
# grep sftpuser /etc/passwd
sftpuser:x:1003:1012::/public:/bin/bash



m27315 wrote:

And, please post this too:

Code:
ls -ld /

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

_________________
Thunar-thumbnailers
Raw-thumbnailer
http://brainstorm.ubuntu.com/idea/6878/image/1/
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Fri Aug 08, 2008 8:57 pm    Post subject: Reply with quote

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

Code:
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:

Code:
# 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:

Code:
$ 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. :)
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Fri Aug 08, 2008 9:01 pm    Post subject: Reply with quote

Try this:
Code:
# 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.
Back to top
View user's profile Send private message
Erlend
Guru
Guru


Joined: 26 Dec 2004
Posts: 484

PostPosted: Fri Aug 08, 2008 9:03 pm    Post subject: Reply with quote

m27315 wrote:
Try this:
Code:
# 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.

That fixed it - thanks!
_________________
Thunar-thumbnailers
Raw-thumbnailer
http://brainstorm.ubuntu.com/idea/6878/image/1/
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Fri Aug 08, 2008 9:19 pm    Post subject: Reply with quote

Great! Glad to help!
Back to top
View user's profile Send private message
thrashed
Apprentice
Apprentice


Joined: 01 Sep 2004
Posts: 292

PostPosted: Wed Nov 19, 2008 8:52 pm    Post subject: Reply with quote

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:
Code:
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.
Code:
scptestuser :x:1001:1006::/somewebsite:/bin/false


this is the debug log from the ssh-service during the winscp-login
Code:
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
Code:
....
....
   Match Group sftponly
   ChrootDirectory /var/www/localhost/htdocs/somewebsite
   X11Forwarding no
   AllowTcpForwarding no
   ForceCommand sftp-server


/etc/pam.d/sshd
Code:
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
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Wed Nov 19, 2008 9:09 pm    Post subject: need more info Reply with quote

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. :(
Back to top
View user's profile Send private message
Naib
Advocate
Advocate


Joined: 21 May 2004
Posts: 4076
Location: Removed by Neddy

PostPosted: Fri Nov 21, 2008 10:33 am    Post subject: Reply with quote

put it on the wiki!
_________________
A free press is the unsleeping guardian of every other right that free men prize; it is the most dangerous foe of tyranny. Where men have the habit of liberty, the Press will continue to be the vigilant guardian of the rights of the ordinary citizen.
Back to top
View user's profile Send private message
MarcusXP
Apprentice
Apprentice


Joined: 18 Apr 2007
Posts: 183
Location: Toronto, ON, Canada

PostPosted: Wed Apr 08, 2009 5:19 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Wed Apr 08, 2009 1:05 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
EstebanGonzales
n00b
n00b


Joined: 14 Oct 2010
Posts: 8

PostPosted: Mon Oct 18, 2010 10:37 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
m27315
Apprentice
Apprentice


Joined: 10 Dec 2004
Posts: 234
Location: 2 workstations down

PostPosted: Mon Oct 18, 2010 10:40 pm    Post subject: need more info Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum