chroot: ssh works, scp doesn't
Hello all.... Thanks for earlier help setting up a chroot ssh login. That now works fully, and because of "compartment"'s --user --group options I don't need the su that I thought I did (in the chroot user's /bin). Problem: I can log on to my chroot user's area using ssh, but I can't scp files across to it. I _can_ scp files from the chroot login to the remote server. I'll eventually use rsync, but scp is a starting point; scp and rsync fail similarly. The command I'm running from the remote machine is: "scp -vvv rsync/* update@test:/tmp/tmk" And the output is as follows: (snip lots) 2634: debug2: we sent a publickey packet, wait for reply 2634: debug1: authentications that can continue: publickey,password 2634: debug2: we did not send a packet, disable method 2634: debug3: authmethod_lookup password 2634: debug3: remaining preferred: ,password 2634: debug3: authmethod_is_enabled password 2634: debug1: next auth method to try is password update@test's password: 2634: debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) 2634: debug2: we sent a password packet, wait for reply 2634: debug1: ssh-userauth2 successful: method password 2634: debug1: fd 4 setting O_NONBLOCK 2634: debug1: fd 5 setting O_NONBLOCK 2634: debug1: channel 0: new [client-session] 2634: debug3: ssh_session2_open: channel_new: 0 2634: debug1: send channel open 0 2634: debug1: Entering interactive session. 2634: debug2: callback start 2634: debug1: ssh_session2_setup: id 0 2634: debug1: Sending command: scp -v -d -t /tmp/tmk 2634: debug1: channel request 0: exec 2634: debug2: callback done 2634: debug1: channel 0: open confirm rwindow 0 rmax 32768 2634: debug2: channel 0: rcvd adjust 131072 Obviously, the password works fine, but I can't figure out where to look next. I can send the output of running "ssh -vvv update@test" if that helps. Permissions on $JAIL/tmp/tmk look like this: tmp: total 0 0 drwxrwxrwx 3 update nogroup 72 2004-01-22 14:34 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 0 drwxrwxrwx 2 update nogroup 48 2004-01-22 14:34 tmk tmp/tmk: total 0 0 drwxrwxrwx 2 update nogroup 48 2004-01-22 14:34 . 0 drwxrwxrwx 3 update nogroup 72 2004-01-22 14:34 .. I can send a description of the setup of the chroot jail if _that_ helps. I know this isn't directly a security issue, so I won't be hurt if you point me somewhere else... just _don't_ suggest Google, I've had a look around there already! In the long run I'll be using public key stuff to avoid passwords, but I've taken that out to eliminate it as a possible problem. Thanks, Tom. --------------- Tom Knight System Administration Officer Arts & Humanities Data Service Web: http://www.ahds.ac.uk Email: tom.knight@ahds.ac.uk Tel: (0)20 7928 7371
* Tom Knight;
total 0 0 drwxrwxrwx 3 update nogroup 72 2004-01-22 14:34 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 0 drwxrwxrwx 2 update nogroup 48 2004-01-22 14:34 tmk
tmp/tmk: total 0 0 drwxrwxrwx 2 update nogroup 48 2004-01-22 14:34 . 0 drwxrwxrwx 3 update nogroup 72 2004-01-22 14:34 ..
I can send a description of the setup of the chroot jail if _that_ helps.
Please do so -- Togan Muftuoglu | Unofficial SuSE FAQ Maintainer | Please reply to the list; http://susefaq.sf.net | Please don't put me in TO/CC. Nisi defectum, haud refiecendum
I can send a description of the setup of the chroot jail if _that_ helps.
Please do so
The scenario is that the remote machine is the development server, and we need to get files from this to the public facing server. The files will be uploaded to the chroot jail's "upload" area, the system will perform a sanity check on them and then move/copy them to the appropriate place for public viewing. Rsync will probably be used instead of scp, but we'll see. Okay, this is _not_ a secure chroot at the moment, I'm trying to get it to work, first off. Once it works, I'll start again from nothing. Obviously, a chroot user doesn't need to use ldd, but it's there while I'm working this out! I'm new to chroot, so if there's anything I'm doing that's really stupid, please let me know! Commands used to access server (from remote): ssh update@test (works fine, log with -vvv can be given) scp /tmp/tmk/* update@test:/tmp/tmk (doesn't work, log with -vvv given in previous post) Entry in server's /etc/passwd: update:x:5000:65534:Update User:/home/update:/bin/compart.jail Details of /bin/compart.jail: #!/bin/bash sudo /usr/sbin/compartment --user update --group nogroup --chroot /home/update/JAIL /bin/bash Okay, /etc/sudoers has an apropriate entry for user update. /home/update is the update user's home directory, will contain the .ssh/authorised_keys file to allow passwordless logins for a user from a remote machine. /home/update/JAIL is the chroot jail for the update user. Files in /home/update/JAIL (apologies for the length of this!): .: total 5 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 . 0 drwxr-xr-x 4 update nogroup 120 2004-01-22 16:18 .. 4 -rw------- 1 update nogroup 1053 2004-01-22 16:46 .bash_history 0 drwx------ 2 update nogroup 112 2004-01-22 11:33 .ssh 0 drwxr-xr-x 2 root root 360 2004-01-22 14:49 bin 0 drwxr-xr-x 2 root root 96 2004-01-22 15:58 dev 0 drwxr-xr-x 3 root root 176 2004-01-22 16:12 etc 1 drwxr-xr-x 5 root root 776 2004-01-22 16:05 lib 0 drwxrwxrwx 3 update nogroup 72 2004-01-22 14:34 tmp 0 drwxrwxrwx 4 update nogroup 112 2004-01-22 09:33 upload 0 drwxr-xr-x 4 root root 96 2004-01-22 14:50 usr ./.ssh: total 8 0 drwx------ 2 update nogroup 112 2004-01-22 11:33 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 4 -rw-r--r-- 1 update nogroup 440 2004-01-22 14:39 known_hosts ./bin: total 1753 0 drwxr-xr-x 2 root root 360 2004-01-22 14:49 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 469 -rwxr-xr-x 1 root root 477132 2004-01-20 15:02 bash 8 -rwxr-xr-x 1 root root 4786 2004-01-22 14:49 ldd 68 -rwxr-xr-x 1 root root 68460 2004-01-20 15:02 ls 20 -rwxr-xr-x 1 root root 18928 2004-01-20 15:02 mkdir 52 -rwxr-xr-x 1 root root 52184 2004-01-20 15:02 mv 8 -rwxr-xr-x 1 root root 6096 2004-01-20 15:02 pwd 28 -rwxr-xr-x 1 root root 26656 2004-01-20 15:02 rm 12 -rwxr-xr-x 1 root root 8760 2004-01-22 12:53 rmt 192 -rwxr-xr-x 1 root root 196256 2004-01-20 16:54 rsync 32 -rwxr-xr-x 1 root root 28772 2004-01-22 14:33 scp 469 -rwxr-xr-x 1 root root 477132 2004-01-22 14:49 sh 256 -rwsr-xr-x 1 root root 260976 2004-01-22 12:58 ssh 140 -rwxr-xr-x 1 root root 142252 2004-01-22 12:54 tar ./dev: total 0 0 drwxr-xr-x 2 root root 96 2004-01-22 15:58 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 0 crw-rw-rw- 1 root root 5, 0 2004-01-22 14:39 tty 0 crw-r--r-- 1 root root 1, 9 2004-01-20 16:00 urandom ./etc: total 16 0 drwxr-xr-x 3 root root 176 2004-01-22 16:12 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 4 -rw-r--r-- 1 root root 27 2004-01-22 16:11 group 4 -rw-r--r-- 1 root root 41 2004-01-22 14:39 hosts 4 -rw-r--r-- 1 root root 1722 2004-01-21 09:08 ld.so.cache 0 drwxr-xr-x 3 root root 96 2004-01-21 12:15 pam.d 4 -rw-r--r-- 1 root root 65 2004-01-22 16:12 passwd ./etc/pam.d: total 4 0 drwxr-xr-x 3 root root 96 2004-01-21 12:15 . 0 drwxr-xr-x 3 root root 176 2004-01-22 16:12 .. 4 -rw-r--r-- 1 root root 396 2004-01-21 11:08 other # I guess I'll have to tie this entry down! ^^ ./lib: total 1838 1 drwxr-xr-x 5 root root 776 2004-01-22 16:05 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 0 drwxr-xr-x 2 root root 112 2004-01-20 15:02 i686 92 -rwxr-xr-x 1 root root 91085 2004-01-22 14:47 ld-linux.so.2 28 -rwxr-xr-x 1 root root 25416 2004-01-20 15:02 libacl.so.1 16 -rwxr-xr-x 1 root root 13974 2004-01-20 15:02 libattr.so.1 8 -rwxr-xr-x 1 root root 7518 2004-01-22 16:05 libcom_err.so.2 44 -rwxr-xr-x 1 root root 43395 2004-01-22 14:47 libcrypt.so.1 12 -rwxr-xr-x 1 root root 11856 2004-01-20 15:02 libdl.so.2 104 -rwxr-xr-x 1 root root 104452 2004-01-22 16:05 libext2fs.so.2 124 -rwxr-xr-x 1 root root 122891 2004-01-20 15:02 libhistory.so.4 304 -rwxr-xr-x 1 root root 307598 2004-01-20 15:02 libncurses.so.5 88 -rwxr-xr-x 1 root root 87717 2004-01-22 14:47 libnsl.so.1 52 -rwxr-xr-x 1 root root 50541 2004-01-21 09:11 libnss_compat.so.2 44 -rwxr-xr-x 1 root root 44639 2004-01-21 09:13 libnss_files.so.2 36 -rwxr-xr-x 1 root root 35088 2004-01-21 10:22 libpam.so.0 12 -rwxr-xr-x 1 root root 11881 2004-01-21 10:22 libpam_misc.so.0 637 -rwxr-xr-x 1 root root 650278 2004-01-20 15:02 libreadline.so.4 72 -rwxr-xr-x 1 root root 70056 2004-01-22 14:47 libresolv.so.2 36 -rwxr-xr-x 1 root root 34085 2004-01-20 15:02 librt.so.1 12 -rwxr-xr-x 1 root root 10600 2004-01-22 14:47 libutil.so.1 52 -rwxr-xr-x 1 root root 52751 2004-01-21 11:35 libxcrypt.so.1 64 -rwxr-xr-x 1 root root 61850 2004-01-22 14:47 libz.so.1 0 drwxr-xr-x 2 root root 208 2004-01-21 11:47 security ./lib/i686: total 1390 0 drwxr-xr-x 2 root root 112 2004-01-20 15:02 . 1 drwxr-xr-x 5 root root 776 2004-01-22 16:05 .. 1289 -rwxr-xr-x 1 root root 1315242 2004-01-20 15:02 libc.so.6 100 -rwxr-xr-x 1 root root 98628 2004-01-20 15:02 libpthread.so.0 ./lib/security: total 185 0 drwxr-xr-x 2 root root 208 2004-01-21 11:47 . 1 drwxr-xr-x 5 root root 776 2004-01-22 16:05 .. 44 -rwxr-xr-x 1 root root 43076 2004-01-21 11:46 pam_unix.so 44 -rwxr-xr-x 1 root root 43076 2004-01-21 11:46 pam_unix2.so 44 -rwxr-xr-x 1 root root 44711 2004-01-21 11:47 pam_unix_acct.so 44 -rwxr-xr-x 1 root root 44711 2004-01-21 11:47 pam_unix_auth.so 8 -rwxr-xr-x 1 root root 5841 2004-01-21 11:46 pam_warn.so ./tmp: total 0 0 drwxrwxrwx 3 update nogroup 72 2004-01-22 14:34 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 0 drwxrwxrwx 2 update nogroup 48 2004-01-22 14:34 tmk ./tmp/tmk: total 0 0 drwxrwxrwx 2 update nogroup 48 2004-01-22 14:34 . 0 drwxrwxrwx 3 update nogroup 72 2004-01-22 14:34 .. ./upload: total 0 0 drwxrwxrwx 4 update nogroup 112 2004-01-22 09:33 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 0 drwxrwxrwx 2 update nogroup 48 2004-01-22 09:33 catalogue 0 drwxrwxrwx 2 update nogroup 48 2004-01-21 13:00 publicsite ./upload/catalogue: total 0 0 drwxrwxrwx 2 update nogroup 48 2004-01-22 09:33 . 0 drwxrwxrwx 4 update nogroup 112 2004-01-22 09:33 .. ./upload/publicsite: total 0 0 drwxrwxrwx 2 update nogroup 48 2004-01-21 13:00 . 0 drwxrwxrwx 4 update nogroup 112 2004-01-22 09:33 .. ./usr: total 0 0 drwxr-xr-x 4 root root 96 2004-01-22 14:50 . 0 drwxr-xr-x 10 update nogroup 272 2004-01-22 14:34 .. 0 drwxr-xr-x 2 root root 192 2004-01-22 16:03 bin 0 drwxr-xr-x 2 root root 280 2004-01-20 15:02 lib ./usr/bin: total 504 0 drwxr-xr-x 2 root root 192 2004-01-22 16:03 . 0 drwxr-xr-x 4 root root 96 2004-01-22 14:50 .. 8 -rwxr-xr-x 1 root root 6056 2004-01-22 16:03 env 4 -rw-r--r-- 1 root root 19 2004-01-20 15:00 groups 12 -rwxr-xr-x 1 root root 9400 2004-01-20 15:02 id 192 -rwxr-xr-x 1 root root 196256 2004-01-20 15:02 rsync 32 -rwxr-xr-x 1 root root 28772 2004-01-22 14:33 scp 256 -rwsr-xr-x 1 root root 260976 2004-01-20 15:02 ssh # Yes, some of these are in the /bin directory as well. ./usr/lib: total 2221 0 drwxr-xr-x 2 root root 280 2004-01-20 15:02 . 0 drwxr-xr-x 4 root root 96 2004-01-22 14:50 .. 148 -rwxr-xr-x 1 root root 147873 2004-01-22 14:48 libasn1.so.5 8 -rwxr-xr-x 1 root root 7801 2004-01-22 14:48 libcom_err.so.1 941 -r-xr-xr-x 1 root root 961852 2004-01-22 14:47 libcrypto.so.0.9.6 729 -rwxr-xr-x 1 root root 744626 2004-01-22 14:48 libdb-4.0.so 52 -rwxr-xr-x 1 root root 53230 2004-01-22 14:48 libgssapi.so.1 260 -rwxr-xr-x 1 root root 263374 2004-01-22 14:48 libkrb5.so.17 84 -rwxr-xr-x 1 root root 84253 2004-01-22 14:48 libroken.so.9 Thanks in advance for any ideas, Tom. --------------- Tom Knight System Administration Officer Arts & Humanities Data Service Web: http://www.ahds.ac.uk Email: tom.knight@ahds.ac.uk Tel: (0)20 7928 7371
-----Original Message----- From: Tom Knight [mailto:thomas.knight@ahds.ac.uk] Sent: 23 January 2004 10:02 To: suse-security@suse.com Subject: RE: [suse-security] chroot: ssh works, scp doesn't
I can send a description of the setup of the chroot jail if _that_ helps.
Please do so
I've been playing with this a lot now. Looking at the two files /etc/passwd and /bin/compart.jail: If I change the /etc/passwd shell for the user to /bin/bash, scp is fine. When I cange it back to /bin/compart.jail, it's not fine, as before. If I change /bin/compart.jail to read: #!/bin/bash /bin/bash scp is _still_ not functioning in the same way as before Looking at debug logging of sshd, I can see that the sudo line in the /bin/compart.jail is called, so I know the system does manage to read that file. In case you really want to know, here are its permissions: 4 -rwxr-xr-x 1 root root 390 2004-01-23 12:09 /bin/compart.jail So it looks like scp doesn't like the login shell being /bin/compart.jail There must be a way..... Tom. --------------- Tom Knight System Administration Officer Arts & Humanities Data Service Web: http://www.ahds.ac.uk Email: tom.knight@ahds.ac.uk Tel: (0)20 7928 7371
/ 2004-01-23 12:44:59 -0000 \ Tom Knight:
I've been playing with this a lot now.
Looking at the two files /etc/passwd and /bin/compart.jail:
If I change the /etc/passwd shell for the user to /bin/bash, scp is fine. When I cange it back to /bin/compart.jail, it's not fine, as before.
If I change /bin/compart.jail to read: #!/bin/bash /bin/bash scp is _still_ not functioning in the same way as before
Looking at debug logging of sshd, I can see that the sudo line in the /bin/compart.jail is called, so I know the system does manage to read that file. In case you really want to know, here are its permissions: 4 -rwxr-xr-x 1 root root 390 2004-01-23 12:09 /bin/compart.jail
So it looks like scp doesn't like the login shell being /bin/compart.jail
There must be a way.....
blindly guessing: echo "/bin/compart.jail" >> /etc/shells Lars Ellenberg
So it looks like scp doesn't like the login shell being /bin/compart.jail
There must be a way.....
blindly guessing: echo "/bin/compart.jail" >> /etc/shells
Worth a try I guess, even though ssh works fine. Just tried it, and no joy :-( Thanks anyway, Tom.
/ 2004-01-23 16:21:58 -0000 \ Tom Knight:
So it looks like scp doesn't like the login shell being /bin/compart.jail
There must be a way.....
blindly guessing: echo "/bin/compart.jail" >> /etc/shells
Worth a try I guess, even though ssh works fine.
Just tried it, and no joy :-(
what I found by means of google: | I suspect this won't work. Scp is nothing but a hardcoded command running | over an ssh channel. When you scp a file to a remote host, your local | host makes an ssh connection to the remote system and then runs a specific | command on that remote system -- which means that you have to have a | shell that, minimally, accept the '-c <command>' command line option. | | For example, the following command: | | scp file remotehost: | | Is largely equivilent to: | | ssh remotehost <shell> -c "scp -t ." so please try again with /bin/compart.jail: #!/bin/bash /bin/bash "$@" if that works, all you have to do is go back to your first try, but don't forget to pass the command line arguments ;) Lars Ellenberg
what I found by means of google:
| I suspect this won't work. Scp is nothing but a hardcoded command running | over an ssh channel. When you scp a file to a remote host, your local | host makes an ssh connection to the remote system and then runs a specific | command on that remote system -- which means that you have to have a | shell that, minimally, accept the '-c <command>' command line option. | | For example, the following command: | | scp file remotehost: | | Is largely equivilent to: | | ssh remotehost <shell> -c "scp -t ."
so please try again with
/bin/compart.jail: #!/bin/bash /bin/bash "$@"
if that works, all you have to do is go back to your first try, but don't forget to pass the command line arguments
;)
Lars Ellenberg
May I praise you to the world? Of course, that DID work. Now I've changed my /bin/compart.jail to read: #!/bin/bash sudo /usr/sbin/compartment --user update --group nogroup --chroot /home/update/JAIL /bin/bash "$@" Thank you _very_ much indeed for bringing a smile to an otherwise rubbish Monday morning! Tom.
participants (3)
-
Lars Ellenberg -
Togan Muftuoglu -
Tom Knight