chrootssh-users — A mailing list primarily for informing users of new releases

[Chrootssh-users] Cannot find account for uid

[Bob R. <bo...@ro...>]

I saw an email on this list from a month or two ago about someone seeing the following error when running sshd -d (but saw no post about a solution):

login_get_lastlog: Cannot find account for uid xxx

I'm having the same problem and was wondering if a solution was found.  I am running the latest (I think) tarball openssh-3.7.1p2-chroot.tar.gz

If I have the user without the /./ in the path, he can login fine.  If I use root and run chroot /his/path /bin/sh  I get a working, chroot-ed shell.  If I try to ssh I get immediately disconnected with the above error showing up in the log.

Any suggestions on where to look?

thanks,
bob

[Chrootssh-users] chrootssh for 3.7.1p2?

[Brandon H. <hu...@cs...>]

Hello! I was wondering if chrootssh is going to be "upgraded" for OpenSSH 
3.7.1p2? 

I believe this version was released 9/23/03 to fix a problem in 3.7.1p1. I 
don't think 3.7.1p1 is exploitable except in a non-privilege separation 
configuration, which is not the default.

More information:
http://developers.slashdot.org/article.pl?sid=03/09/23/1736243&mode=thread&tid=126&tid=156&tid=172

Thanks!

Brandon Hutchinson

RE: [Chrootssh-users] chrootssh under FreeBSD 4.8

[John R. <joh...@da...>]

Nope.

Dot does refer to teh current dir.  This notation allows access locally as
well (although that wouldn't be chrooted).  If needed you can edit teh
passwd file manually to add the .

Basically /./ acts as a silent flag.

-----Original Message-----
From: Matt Rideout [mailto:mri...@wi...]
Sent: 18 September 2003 18:33
To: chr...@li...
Subject: [Chrootssh-users] chrootssh under FreeBSD 4.8


I'm trying to setup chrootssh on a FreeBSD 4.8 box. I've been following
the chrooted sftp howto
(http://chrootssh.sourceforge.net/docs/chrootedsftp.html), and everything
went smoothly until I got to the point where the instructions said to
create a new user account with a home directory of
"/path/to/chroot/./home/username". AFAIK, under FreeBSD (and I'm pretty
sure under Linux too), you can't create a "." directory since "." refers
to the present working directory. Am I misunderstanding the directions?

Matt


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Chrootssh-users mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chrootssh-users

[Chrootssh-users] chrootssh under FreeBSD 4.8

[Matt R. <mri...@wi...>]

I'm trying to setup chrootssh on a FreeBSD 4.8 box. I've been following
the chrooted sftp howto
(http://chrootssh.sourceforge.net/docs/chrootedsftp.html), and everything
went smoothly until I got to the point where the instructions said to
create a new user account with a home directory of
"/path/to/chroot/./home/username". AFAIK, under FreeBSD (and I'm pretty
sure under Linux too), you can't create a "." directory since "." refers
to the present working directory. Am I misunderstanding the directions?

Matt

[Chrootssh-users] OpenSSH Vulnerability And Update

[Russell H. <har...@cu...>]

Hello.

  I have updated the OpenSSH-Chroot packages for the new version, 3.7p1 of
OpenSSH-portable.

The tarball would not be delivered by the mailing list, so I have put it
up at: http://www.cunap.com/~hardingr/openssh-3.7p1-chroot.tar.gz

Please see that these packages end up on the sourceforge repository asap.

     Thanks much,
         -Russell Harding

---------- Forwarded message ----------
Date: Tue, 16 Sep 2003 09:45:06 -0600
From: Alan V. <Al...@bi...>
To: SANITIZED
Subject: OpenSSH Vulnerability

http://isc.sans.org/diary.html?date=2003-09-16

"A vulnerability has been discovered in OpenSSH. This vulnerability
appears to have been exploited to compromise machines at a few ISPs.
We highly recommend upgrading to the version 3.7p1 which was released
earlier today.
This bug may not be exploitable on some platforms (e.g. OpenBSD) but
could be exploitable on others (e.g. Linux).
Currently, there is no widely available exploit. However, there are
some rumors about intrusions using this vulnerability to compromise
systems."



"I don't have time to be impatient."
Alan R. V.
<snip>

RE: [Chrootssh-users] Problem with transferring files + groups/id error

[Niall O'H. <np...@ei...>]

I've done a bit more research and its definitely the unknown user error =
501
from scp that is causing the problem so can anyone help with this?

< WinSCP: this is begin-of-file
! unknown user 501
< inSCP: this is end-of-file:255

501 is the uid of the user that is chrooted

-----Original Message-----
From: chr...@li...
[mailto:chr...@li...] On Behalf Of Niall
O'Hara
Sent: 12 September 2003 02:54
To: chr...@li...
Subject: [Chrootssh-users] Problem with transferring files + groups/id =
error


Hi everyone,

I've a strange problem here I had to install groups and id to get rid of =
nag
errors in winSCP but now whenever I connect to the Linux box using =
winSCP I
get the following error

Command "groups"
failed with return code 1 and error message
id: cannot find name for group ID 501.

If I click cancel it logs on ok and connects to the chrooted dir no =
problem
but I cannot upload any files, if I try it just hangs and I have to =
abort.

If I try ssh to the box it closes the shell after I enter a username and
password for a user who is chrooted other users can ssh to it no probs.

Any ideas???




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Chrootssh-users mailing list Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chrootssh-users

[Chrootssh-users] Problem with transferring files + groups/id error

[Niall O'H. <np...@ei...>]

Hi everyone,

I've a strange problem here I had to install groups and id to get rid of =
nag
errors in winSCP but now whenever I connect to the Linux box using =
winSCP I
get the following error

Command "groups"
failed with return code 1 and error message
id: cannot find name for group ID 501.

If I click cancel it logs on ok and connects to the chrooted dir no =
problem
but I cannot upload any files, if I try it just hangs and I have to =
abort.

If I try ssh to the box it closes the shell after I enter a username and
password for a user who is chrooted other users can ssh to it no probs.

Any ideas???

[Chrootssh-users] [Solaris 7] 3 problems after connecting via patched sshd

[Sajid A. <saj...@in...>]

Setting up chroot-patched OpenSSH on Solaris 7
----------------------------------------------
  shell: bash-2.05             used openssl-0.9.7b
  using: openssh-3.6.1p1       used zlib-1.1.4   =20
  patch version 2.5.4          used libgcc-3.2.3 =20
  used osshChroot-3.6.1.diff  =20
 -patched sshd daemon starts-up fine;
 -accepts connection and chroots the user just fine;
   (although not critical, for the record: owner, group info for =
files/dirs not displayed;
   uid/gid mapping not done perhaps due to absence of /etc/passwd, =
/etc/group, /etc/nsswitch.conf)

Few problems:

[X] Problem #1 (^C, ^D et al do not work)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  [CARNATION /var/log]# cd /
  [CARNATION /]# ls
  200          bin@         etc/         kernel/      mnt/         =
nsmail/      proc/        tmp/         vol/
  TT_DB/       cdrom/       export/      lib@         net/         opt/  =
       sbin/        upgrade/     xfn/
  apache-tmp/  dev/         home/        local/       new.dat      pkgs/ =
       systeminfo   usr/
  backup/      devices/     jail/        lost+found/  nohup.out    =
platform/    test/        var/

  [CARNATION /]# cd /var/log/    ; "just changed to an arbitrary dir"

  [CARNATION /var/log]# /usr/sbin/chroot /jail /usr/local/bin/bash     ; =
"testing the jail from command-line"
  [CARNATION /]# ls
  bin       dev       etc       lib       test.txt  tmp       usr       =
var

  [CARNATION /]# tail -f test.txt=20
  ...
  Microsoft using a Linux service is ironic, given that Microsoft has =
identified Linux as its biggest competitor. In a conference call with =
analysts last month, company CFO John Connors ranked Linux as the #2 =
risk faced by the company. The #1 risk was the general economic =
environment, Connors said. Nearly one in five small and mid-sized =
businesses are using Linux on the desktop.=20

  =
http://story.news.yahoo.com/news?tmpl=3Dstory&u=3D/cmp/20030821/tc_cmp/13=
100775
  =
-------------------------------------------------------------------------=
--------------------
  Test line to test 'tail' from jail...
  Test line to test 'tail' from jail...
  Test line to test 'tail' from jail...
  Test line to test 'tail' from jail...
  Test line to test 'tail' from jail...
  ^C
  [CARNATION /]#=20
  (breaking from the 'tail' by ^C)

  [CARNATION /]# exit
  [CARNATION /var/log]#            "jail 'seems' ok; back to where we =
started"

Now, loging in via an ssh connection, although chroots to the specified =
dir, does not break from 'tail':

  [CARNATION /]$ tail -f test.txt=20
  ...
  =
http://story.news.yahoo.com/news?tmpl=3Dstory&u=3D/cmp/20030821/tc_cmp/13=
100775
  =
-------------------------------------------------------------------------=
--------------------
  Test line to test 'tail' from jail...
  Test line to test 'tail' from jail...

  ^C^C^C^C^C^Z^C^C
  (the only way is to close the terminal window, thereby losing the =
session!)

[X] Problem #2 (truss won't run! Need it to find out other dependencies =
for programs I wish to add to the jail on the go...)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  ldd /usr/bin/truss shows:                       |   =
/jail/usr/bin/truss present                               =20
  libc.so.1 =3D>     /usr/lib/libc.so.1             |    required =
libraries present                                =20
  libdl.so.1 =3D>    /usr/lib/libdl.so.1            |    =
/jail/usr/lib/libc.so.1                          =20
  /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1   |    =
/jail/usr/lib/libdl.so.1                         =20
                                                  |    =
/jail/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
  but I get, for instance:
  [CARNATION /]# truss ls
  truss: getexecname() failed

[X] Problem #3 (can't clear screen)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  'clear' does not work
  from within jail, I get:

  [CARNATION /]# /usr/bin/clear    ; "/usr/bin/clear exists"
  bash: /usr/bin/clear: bad interpreter: No such file or directory
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++++++++++++++++


[CARNATION /jail]# ls -lR        ; "my jail looks like this"
  .:
  total 20
  drwxrwx---   2 apache   portal       512 Sep  8 07:06 bin/
  drwxrwx---   2 apache   portal       512 Sep  8 07:23 dev/
  drwxrwx---   2 apache   portal       512 Sep  8 07:06 etc/
  lrwxrwxrwx   1 root     other          8 Sep  9 06:55 lib -> /usr/lib/
  -rw-rw-r--   1 root     other       2935 Sep 11 08:01 test.txt
  drwxrwxrwx   3 apache   portal       512 Sep 11 08:13 tmp/
  drwxrwx---   7 apache   portal       512 Sep 11 07:11 usr/
  drwxrwx---   3 apache   portal       512 Sep  8 12:16 var/

  ./bin:
  total 0

  ./dev:
  total 0
  crw-rw-rw-   1 root     other     21,  5 Sep  8 07:23 log
  crw-rw-rw-   1 root     other     13,  2 Sep  8 07:22 null
  crw-rw-rw-   1 root     other     13, 12 Sep  8 07:22 zero

  ./etc:
  total 0

  ./tmp:
  total 2
  drwx------   2 dev      portal       512 Sep 11 08:13 ssh-xgx17624/

  ./tmp/ssh-xgx17624:
  total 0
  srwxrwxr-x   1 dev      portal         0 Sep 11 08:13 agent.17624=3D

  ./usr:
  total 10
  drwxrwxr-x   2 root     other        512 Sep 11 06:58 bin/
  drwxrwxr-x   2 root     other        512 Sep  9 06:49 lib/
  drwxrwxr-x   3 root     other        512 Sep  8 07:11 local/
  drwxrwxr-x   3 root     other        512 Sep  8 07:13 platform/
  drwxrwxr-x   3 root     other        512 Sep 11 07:12 share/

  ./usr/bin:
  total 110
  -r-xr-xr-x   1 root     other        131 Sep  8 09:22 cd*
  -r-xr-xr-x   1 root     other        647 Sep 11 06:58 clear*
  -r-xr-xr-x   1 root     other      18704 Sep  9 06:54 ln*
  -r-xr-xr-x   1 root     other      18120 Sep  8 09:22 ls*
  -r-xr-xr-x   1 root     other       9588 Sep  8 09:23 tail*
  -r-xr-xr-x   1 root     other       5540 Sep  8 11:17 truss*

  ./usr/lib:
  total 5426
  -rwxr-xr-x   1 root     other     211268 Sep  8 07:32 ld.so.1*
  -rwxr-xr-x   1 root     other    1126044 Sep  8 11:23 libc.so.1*
  -rwxr-xr-x   1 root     other     474964 Sep  8 11:22 libcurses.so.1*
  -rwxr-xr-x   1 root     other       4908 Sep  8 11:23 libdl.so.1*
  -rwxr-xr-x   1 root     other      19876 Sep  8 11:23 libmp.so.2*
  -rwxr-xr-x   1 root     other     838640 Sep  8 11:23 libnsl.so.1*
  -rwxr-xr-x   1 root     other      56988 Sep  8 11:22 libsocket.so.1*

  ./usr/local:
  total 2
  drwxrwxr-x   2 root     other        512 Sep  8 07:12 bin/

  ./usr/local/bin:
  total 7216
  -rwxr-xr-x   1 root     other    3685104 Sep  8 07:12 bash*

  ./usr/platform:
  total 2
  drwxrwxr-x   3 root     other        512 Sep  8 07:13 SUNW,Ultra-60/

  ./usr/platform/SUNW,Ultra-60:
  total 2
  drwxrwxr-x   2 root     other        512 Sep  8 07:14 lib/

  ./usr/platform/SUNW,Ultra-60/lib:
  total 34
  -rwxr-xr-x   1 root     other      17256 Sep  8 11:23 libc_psr.so.1*

  ./usr/share:
  total 2
  drwxrwxr-x   3 root     other        512 Sep 11 07:12 lib/

  ./usr/share/lib:
  total 2
  drwxrwxr-x   3 root     other        512 Sep 11 07:12 terminfo/

  ./usr/share/lib/terminfo:
  total 2
  drwxrwxr-x   2 root     other        512 Sep 11 07:13 v/

  ./usr/share/lib/terminfo/v:
  total 4
  -rw-r--r--   1 root     other       1493 Sep 11 07:13 vt100

  ./var:
  total 2
  drwxrwxr-x   2 root     other        512 Sep  8 12:16 tmp/

  ./var/tmp:
  total 0

Any and all help will be greatly apprecited friends.
Thank you all much in advance.

Best regards.
  ^
<s.a>
  V

[Chrootssh-users] Chroot on Solaris 8?

[Aaron M. H. <ah...@le...>]

I have a Solaris 8 machine that I have downloaded and installed zlib-1.1.4, 
openssl-0.9.7b, and openssh-3.6p1-chroot.  

All is working fine and I have created a chroot enviornment that I am able to 
execute chroot /chevn /bin/bash and be put into the chrooted enviornment.  I 
know that the setup for this is different on Solaris then Linux for two 
reasons, a) the documentation indicates it and b) I have performed the same 
steps on the Solaris host as I did on the Linux host.

User home directories would be /chenv/home/$USERNAME.  I have created the 
following structure in /chenv:
bin dev etc home lib opt usr var and have copied the entire contents of /lib 
and /usr/lib to their respective places in /chenv.  I have also copied 
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 to it's respective location 
as well.

The daemon is functioning and I am able to connect and login, however I am not 
put in the chroot environment.  I had to same issue with Linux initially, but 
have resolved it and tried the same method on the solaris box without any 
success.

Does anyone have any ideas where I should start to look on the Solaris side?

TIA.

p.s.  I could post the sshd -d log and ssh -vvv log if deemed necessary, but 
I'm not seeing any "blatent" errors. 

-- 
Aaron M. Hirsch

Re: [Chrootssh-users] Users not being dropped into chroot shell

[Aaron M. H. <ah...@le...>]

As requested I have put the daemon in debug mode and attached to the specified 
port as a test user.  Here is the output from it:

sh-2.05b# /opt/local/sbin/sshd -d
debug1: sshd version OpenSSH_3.6p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
socket: Address family not supported by protocol
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug1: Server will not fork when running in debugging mode.
Connection from 192.168.1.1 port 36330
debug1: Client protocol version 2.0; client software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6p1
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user chrootuser service ssh-connection method 
none
debug1: attempt 0 failures 0
debug1: userauth_banner: sent
Failed none for chrootuser from 192.168.1.1 port 36330 ssh2
Failed none for chrootuser from 192.168.1.1 port 36330 ssh2
debug1: userauth-request for user chrootuser service ssh-connection method 
publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 6013/6013 (e=0/0)
debug1: trying public key file /chroot/./home/chroot/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 6013/6013 (e=0/0)
debug1: trying public key file /chroot/./home/chroot/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for chrootuser from 192.168.1.1 port 36330 ssh2
debug1: userauth-request for user chrootuser service ssh-connection method 
keyboard-interactive
debug1: attempt 2 failures 2
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=chrootuser devs=
debug1: kbdint_alloc: devices ''
Failed keyboard-interactive for chrootuser from 192.168.1.1 port 36330 ssh2
debug1: userauth-request for user chrootuser service ssh-connection method 
password
debug1: attempt 3 failures 3
Accepted password for chrootuser from 192.168.1.1 port 36330 ssh2
debug1: monitor_child_preauth: chrootuser has been authenticated by privileged 
process
Accepted password for chrootuser from 192.168.1.1 port 36330 ssh2
debug1: Entering interactive session for SSH2.
debug1: fd 3 setting O_NONBLOCK
debug1: fd 7 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/1
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.
debug1: channel 0: rfd 9 isatty
debug1: fd 9 setting O_NONBLOCK
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 25615
debug1: session_exit_message: session 0 channel 0 pid 25615
debug1: channel 0: request exit-status
debug1: session_exit_message: release channel 0
debug1: channel 0: write failed
debug1: channel 0: close_write
debug1: channel 0: output open -> closed
debug1: session_close: session 0 pid 25615
debug1: session_pty_cleanup: session 0 release /dev/pts/1
debug1: channel 0: read<=0 rfd 9 len -1
debug1: channel 0: read failed
debug1: channel 0: close_read
debug1: channel 0: input open -> drain
debug1: channel 0: ibuf empty
debug1: channel 0: send eof
debug1: channel 0: input drain -> closed
debug1: channel 0: send close
debug1: channel 0: rcvd close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: server-session, nchannels 1
Connection closed by 192.168.1.1
Closing connection to 192.168.1.1

So, it appears that I am connecting to the daemon I thought I was but how do I 
verify that it is the patched daemon?  I did a diff on the openssh-3.6p1 and 
openssh-3.6p1-chroot before installing openssh-3.6p1-chroot and saw 171 lines 
that are different, mainly things that are only in the openssh-3.6p1-chroot.  

Should the trace show openssh-3.6p1-chroot as the version?

> can you get some trace from the server (run it with debug flags).
> That will help check that you are running the code you think you are.
>
> Cheers
>
> John
>
> -----Original Message-----
> From: Aaron M. Hirsch [mailto:ah...@le...]
> Sent: 08 September 2003 20:45
> To: chr...@li...
> Subject: [Chrootssh-users] Users not being dropped into chroot shell
>
>
> All,
>
> I am attempting to setup a RH9 server and need to allow shell access to
> clients to meet with contract requirements.
>
> I have downloaded openssh-3.6p1-chroot.tar.gz (the pre-patched source) and
> openssl-0.9.7b.tar.gz.  I have successfully installed both into /opt/local.
>
> For testing reasons I have this instance of ssh listening on port 2222 and
> the
> regular sshd daemon listening on port 22.
>
> I can successfully run chroot /chroot /bin/bash and get dropped into the
> chrooted enviornment.  However, when I ssh/scp/sftp into the machine I am
> not
> getting dropped into the chrooted enviornment.
>
> aaron@testbox1$ ssh -p 2222 newtest@testbox2
> Use is restricted to Schlumberger authorized users who must
> comply with the Electronic Communications Policy.  Usage is
> monitored; unauthorized use will be prosecuted.
> newtest@shogun1's password:
> Last login: Mon Sep  8 13:19:41 from testbox1
> -bash-2.05b$
>
> As you can see I am logging in successfully, but look where I'm put:
> -bash-2.05b$ pwd
> /chroot/./home/newtest
>
> Instead of /home/newtest.  Can anyone think of something I may have
> "overlooked", or why I can manually chroot to the enviornment but not
> automatically during login?
>
> TIA!

-- 
Aaron M. Hirsch
Systems Administrator II
Schlumberger 
11146 Thompson Ave.
Lenexa, KS 66219

Phone:  (913) 312-4717
Mobile: (913) 284-9094
Fax:	(913) 312-4701

[Chrootssh-users] Users not being dropped into chroot shell

[Aaron M. H. <ah...@le...>]

All,

I am attempting to setup a RH9 server and need to allow shell access to 
clients to meet with contract requirements.

I have downloaded openssh-3.6p1-chroot.tar.gz (the pre-patched source) and 
openssl-0.9.7b.tar.gz.  I have successfully installed both into /opt/local.

For testing reasons I have this instance of ssh listening on port 2222 and the 
regular sshd daemon listening on port 22.

I can successfully run chroot /chroot /bin/bash and get dropped into the 
chrooted enviornment.  However, when I ssh/scp/sftp into the machine I am not 
getting dropped into the chrooted enviornment.

aaron@testbox1$ ssh -p 2222 newtest@testbox2
Use is restricted to Schlumberger authorized users who must
comply with the Electronic Communications Policy.  Usage is
monitored; unauthorized use will be prosecuted.
newtest@shogun1's password:
Last login: Mon Sep  8 13:19:41 from testbox1
-bash-2.05b$

As you can see I am logging in successfully, but look where I'm put:
-bash-2.05b$ pwd
/chroot/./home/newtest

Instead of /home/newtest.  Can anyone think of something I may have 
"overlooked", or why I can manually chroot to the enviornment but not 
automatically during login?

TIA!

-- 
Aaron M. Hirsch

[Chrootssh-users] chroot under OpenBSD working

[<Ala...@ne...>]

I was right about the #ifdefs, apparently those are working differently in OpenBSD than they do in Linux.  I've essentially moved the chroot outside the #ifdefs and it's been working fine for a little over a week.

Anyway, I put together a verbose how-to for OpenBSD users, which I've stuck at http://www-unix.oit.umass.edu/~coreya/OpenBSD/chroot_ssh/index.html

Thanks for your help in this,

  Alan Corey

__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

RE: [Chrootssh-users] chroot() not happening here either

[John R. <JR...@da...>]

New_root
new_root

C is case sensitive - you might want to check that you have got the right
capitalizationsin the code.  But actulaly they are just warnings, what
happens when the code is compiled - does it run?

-----Original Message-----
From: Ala...@ne... [mailto:Ala...@ne...]
Sent: 15 August 2003 03:47
To: chr...@li...
Subject: [Chrootssh-users] chroot() not happening here either


I'm using OpenBSD 3.1 and 3.3.  I've got the tarball
openssh-3.6.1p1-chroot.tar.gz

When it's compiling I notice in the warnings:
session.c: In function Do_setusercontext':
session.c:1217: warning: unused variable New_root'
session.c:1216: warning: unused variable User_dir'

It seems to me from looking at the code that do_setusercontext() is where
the actual chroot() happens, based on whether /./ is found in the variable
new_root, but that's only if CHROOT is defined.  CHROOT is defined,
unconditionally, just after the #includes.

The lines 1217 and 1216 where the warnings originate are inside an #ifdef
CHROOT, as is the chroot() call itself, based on the condition:
if(strncmp(new_root, "/./", 3) == 0) {

It seems like new_root is kind of a critical variable to get warnings about
it being unused.

I haven't done any programming under OpenBSD at all, only some C under
FreeBSD, and C isn't my forte anyway, being more of a Pascal/Delphi type.
This just looks odd.

The chroot just doesn't happen, but the sshd itself seems to be working, and
according to this I'm running the patched version I expect to be:
  leto:alan {102} ssh -V
  OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f

  Alan


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial
today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Chrootssh-users mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chrootssh-users

[Chrootssh-users] chroot() not happening here either

[<Ala...@ne...>]

I'm using OpenBSD 3.1 and 3.3.  I've got the tarball openssh-3.6.1p1-chroot.tar.gz

When it's compiling I notice in the warnings:
session.c: In function Do_setusercontext':
session.c:1217: warning: unused variable New_root'
session.c:1216: warning: unused variable User_dir'

It seems to me from looking at the code that do_setusercontext() is where the actual chroot() happens, based on whether /./ is found in the variable new_root, but that's only if CHROOT is defined.  CHROOT is defined, unconditionally, just after the #includes.

The lines 1217 and 1216 where the warnings originate are inside an #ifdef CHROOT, as is the chroot() call itself, based on the condition:
if(strncmp(new_root, "/./", 3) == 0) {

It seems like new_root is kind of a critical variable to get warnings about  it being unused.

I haven't done any programming under OpenBSD at all, only some C under FreeBSD, and C isn't my forte anyway, being more of a Pascal/Delphi type.  This just looks odd.

The chroot just doesn't happen, but the sshd itself seems to be working, and according to this I'm running the patched version I expect to be:
  leto:alan {102} ssh -V
  OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f

  Alan


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: [Chrootssh-users] Chroot not working

[Michael R. <mr...@mr...>]

These are from the new tarball.

--Mike

John Robson wrote:

> Try getting the right tarball and start again
>
>     -----Original Message-----
>     From: Michael Robokoff [mailto:mr...@mr...]
>     Sent: 07 August 2003 16:52
>     To: 'chr...@li...'
>     Cc: John Robson
>     Subject: Re: [Chrootssh-users] Chroot not working
>
>     I did some checking and it looks as though I did indeed have the
>     wrong tarball. I am very sorry about that. I must have got crossed
>     up somewhere when I was going to down load it.
>
>     Ok, with that behind me now I have a different problem.
>
>     When I :
>     ssh -l test whatever.com
>
>     I get:
>     te...@wh...'s password:
>     Connection to whatever.com closed by remote host.
>     Connection to whatever.com closed.
>
>     The end of the debug output is this:
>
>     Accepted password for test from xxx.xxx.xxx.xxx port 43559 ssh2
>     debug3: mm_send_keystate: Sending new keys: 0x808b440 0x808a700
>     debug3: mm_newkeys_to_blob: converting 0x808b440
>     debug3: mm_newkeys_to_blob: converting 0x808a700
>     debug3: mm_send_keystate: New keys have been sent
>     debug3: mm_send_keystate: Sending compression state
>     debug3: mm_request_send entering: type 24
>     debug3: mm_send_keystate: Finished sending state
>     debug3: mm_newkeys_from_blob: 0x8092890(118)
>     debug2: mac_init: found hmac-md5
>     debug3: mm_get_keystate: Waiting for second key
>     debug3: mm_newkeys_from_blob: 0x8092890(118)
>     debug2: mac_init: found hmac-md5
>     debug3: mm_get_keystate: Getting compression state
>     debug3: mm_get_keystate: Getting Network I/O buffers
>     debug3: mm_share_sync: Share sync
>     debug3: mm_share_sync: Share sync end
>     debug1: permanently_set_uid: 530/200
>     debug2: set_newkeys: mode 0
>     debug2: set_newkeys: mode 1
>     debug1: Entering interactive session for SSH2.
>     debug1: fd 7 setting O_NONBLOCK
>     debug1: fd 8 setting O_NONBLOCK
>     debug1: server_init_dispatch_20
>     debug2: User child is on pid 21794
>     debug3: mm_request_receive entering
>     debug1: server_input_channel_open: ctype session rchan 0 win 65536
>     max 16384
>     debug1: input_session_request
>     debug1: channel 0: new [server-session]
>     debug1: session_new: init
>     debug1: session_new: session 0
>     debug1: session_open: channel 0
>     debug1: session_open: session 0: link with channel 0
>     debug1: server_input_channel_open: confirm session
>     debug1: server_input_channel_req: channel 0 request pty-req reply 0
>     debug1: session_by_channel: session 0 channel 0
>     debug1: session_input_channel_req: session 0 req pty-req
>     login_get_lastlog: Cannot find account for uid 530
>     debug1: Calling cleanup 0x8061d58(0x0)
>     debug1: channel_free: channel 0: server-session, nchannels 1
>     debug3: channel_free: status: The following connections are open:\015
>       #0 server-session (t10 r0 i0/0 o0/0 fd -1/-1)\015
>
>     debug3: channel_close_fds: channel 0: r -1 w -1 e -1
>     debug1: Calling cleanup 0x8068a08(0x0)
>
>
>     I think the real clue here is
>     login_get_lastlog: Cannot find account for uid 530
>
>     But the account does exist in the passwd file.
>
>     --Mike
>
>
>     John Robson wrote:
>
>>You are't actually at the point where that is significant - The debug output
>>would be the most helpful thing at this point.
>>
>>Cheers
>>
>>John
>>
>>
>>-----Original Message-----
>>From: Michael Robokoff [mailto:mr...@mr...]
>>Sent: 07 August 2003 15:06
>>To: John Robson; chrootssh-users-request
>>Subject: Re: [Chrootssh-users] Chroot not working
>>
>>
>>I tried moving the dot to see if that had any effect. I know
>>it should change the location of the new root. Anyway
>>here is my passwd file entry for this user:
>>
>>test:x:530:200:Test User:/home/test/./:/bin/sh
>>
>>--Mike
>>
>>
>>
>>John Robson wrote:
>>
>>  
>>
>>>The passwd file needs /./ (which your directory has)
>>>
>>>Are you sure that is still present (in the passwd file)?
>>>You are sure you have the right tarball... (Worth checking)
>>>Have you got debug output from the server (run it manually with -ddd)
>>>
>>>It is only a few lines of code change to the server binary so a straight
>>>swap of that would have done the trick. (Still would if you decided to
>>>reinstall)
>>>
>>>As your chroot jail is working FOR ROOT (who may have extra permisisons on
>>>the files therein) we can assume that the file system in yout chroot jail
>>>    
>>>
>>is
>>  
>>
>>>OK. [The sysmptoms of it not being OK would be that the SSH session would
>>>log straight back out again, we're not there yet so I'll ignore it for the
>>>mo.]
>>>
>>>The debug output should help determine why it isn't chrooting.
>>>
>>>Cheers
>>>
>>>-----Original Message-----
>>>From: Michael Robokoff [mailto:mr...@mr...]
>>>Sent: 07 August 2003 14:50
>>>To: John Robson
>>>Cc: chr...@li...
>>>Subject: Re: [Chrootssh-users] Chroot not working
>>>
>>>
>>>I did put together a script to start it. I didn't know however you could 
>>>just
>>>replace the binary That would have been a lot easier. Anyway ssh works
>>>fine I can log in as my test user but I do not get chrooted. So I login as
>>>root and run the chroot command to that dir and it works fine all the
>>>necessary libraries are in place and work.  When you say " If you have not
>>>built a file system under the jail" I assume you mean creating the 
>>>necessary
>>>sub directories with the necessary files in them for the shell which 
>>>tested fine
>>>by manually running the command.
>>>
>>>Am I missing something with the dot? I just added the dot to the home dir
>>>path in the etc/passwd file.
>>>
>>>--Mike
>>>
>>>
>>>John Robson wrote:
>>>
>>> 
>>>
>>>    
>>>
>>>>You could have just installed the rpm then replaced the binary.  That
>>>>      
>>>>
>>would
>>  
>>
>>>>give you all the relevant autostart functionality.
>>>>
>>>>However, the appropriate /rc.d/ script wouldn't be hard to put together -
>>>>your easier alternative would be an inittab entry...
>>>>
>>>>If you are not getting chrooted then the patch isn't working.  Assuming
>>>>      
>>>>
>>you
>>  
>>
>>>>have built a complete chroot jail then you should see your path as /test/
>>>>If you have not built a file system under the jail then you'll not get to
>>>>log in, because there will be no shell for you to use.
>>>>
>>>>HTH
>>>>
>>>>John
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Michael Robokoff [mailto:mr...@mr...]
>>>>Sent: 06 August 2003 18:49
>>>>To: chr...@li...
>>>>Subject: [Chrootssh-users] Chroot not working
>>>>
>>>>
>>>>I am running redhat 9, I removed all the ssh rpms
>>>>and got the pre patched tarball. I installed it as
>>>>indicated and I tested the chroot function and
>>>>that works fine. The w problems I see is I have to
>>>>manually start sshd. I think a /etc/rc.d/init.d/
>>>>script would be nice. Other than that I can ssh in
>>>>but chroot does not appear to work I have the
>>>>users path as /home/./test in the password file and
>>>>the actual path is /home/test.
>>>>
>>>>Does anyone have any ideas?
>>>>
>>>>All help is appreciated.
>>>>
>>>>--Mike
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>>>Data Reports, E-commerce, Portals, and Forums are available now.
>>>>Download today and enter to win an XBOX or Visual Studio .NET.
>>>>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/0
>>>>      
>>>>
>>1
>>  
>>
>>>>_______________________________________________
>>>>Chrootssh-users mailing list
>>>>Chr...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/chrootssh-users
>>>>
>>>>
>>>>   
>>>>
>>>>      
>>>>
>

Re: [Chrootssh-users] Chroot not working

[Michael R. <mr...@mr...>]

I did some checking and it looks as though I did indeed have the
wrong tarball. I am very sorry about that. I must have got crossed
up somewhere when I was going to down load it.

Ok, with that behind me now I have a different problem.

When I :
ssh -l test whatever.com

I get:
te...@wh...'s password:
Connection to whatever.com closed by remote host.
Connection to whatever.com closed.

The end of the debug output is this:

Accepted password for test from xxx.xxx.xxx.xxx port 43559 ssh2
debug3: mm_send_keystate: Sending new keys: 0x808b440 0x808a700
debug3: mm_newkeys_to_blob: converting 0x808b440
debug3: mm_newkeys_to_blob: converting 0x808a700
debug3: mm_send_keystate: New keys have been sent
debug3: mm_send_keystate: Sending compression state
debug3: mm_request_send entering: type 24
debug3: mm_send_keystate: Finished sending state
debug3: mm_newkeys_from_blob: 0x8092890(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 0x8092890(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Getting compression state
debug3: mm_get_keystate: Getting Network I/O buffers
debug3: mm_share_sync: Share sync
debug3: mm_share_sync: Share sync end
debug1: permanently_set_uid: 530/200
debug2: set_newkeys: mode 0
debug2: set_newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug1: fd 7 setting O_NONBLOCK
debug1: fd 8 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug2: User child is on pid 21794
debug3: mm_request_receive entering
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
login_get_lastlog: Cannot find account for uid 530
debug1: Calling cleanup 0x8061d58(0x0)
debug1: channel_free: channel 0: server-session, nchannels 1
debug3: channel_free: status: The following connections are open:\015
  #0 server-session (t10 r0 i0/0 o0/0 fd -1/-1)\015

debug3: channel_close_fds: channel 0: r -1 w -1 e -1
debug1: Calling cleanup 0x8068a08(0x0)


I think the real clue here is
login_get_lastlog: Cannot find account for uid 530

But the account does exist in the passwd file.

--Mike


John Robson wrote:

>You are't actually at the point where that is significant - The debug output
>would be the most helpful thing at this point.
>
>Cheers
>
>John
>
>
>-----Original Message-----
>From: Michael Robokoff [mailto:mr...@mr...]
>Sent: 07 August 2003 15:06
>To: John Robson; chrootssh-users-request
>Subject: Re: [Chrootssh-users] Chroot not working
>
>
>I tried moving the dot to see if that had any effect. I know
>it should change the location of the new root. Anyway
>here is my passwd file entry for this user:
>
>test:x:530:200:Test User:/home/test/./:/bin/sh
>
>--Mike
>
>
>
>John Robson wrote:
>
>  
>
>>The passwd file needs /./ (which your directory has)
>>
>>Are you sure that is still present (in the passwd file)?
>>You are sure you have the right tarball... (Worth checking)
>>Have you got debug output from the server (run it manually with -ddd)
>>
>>It is only a few lines of code change to the server binary so a straight
>>swap of that would have done the trick. (Still would if you decided to
>>reinstall)
>>
>>As your chroot jail is working FOR ROOT (who may have extra permisisons on
>>the files therein) we can assume that the file system in yout chroot jail
>>    
>>
>is
>  
>
>>OK. [The sysmptoms of it not being OK would be that the SSH session would
>>log straight back out again, we're not there yet so I'll ignore it for the
>>mo.]
>>
>>The debug output should help determine why it isn't chrooting.
>>
>>Cheers
>>
>>-----Original Message-----
>>From: Michael Robokoff [mailto:mr...@mr...]
>>Sent: 07 August 2003 14:50
>>To: John Robson
>>Cc: chr...@li...
>>Subject: Re: [Chrootssh-users] Chroot not working
>>
>>
>>I did put together a script to start it. I didn't know however you could 
>>just
>>replace the binary That would have been a lot easier. Anyway ssh works
>>fine I can log in as my test user but I do not get chrooted. So I login as
>>root and run the chroot command to that dir and it works fine all the
>>necessary libraries are in place and work.  When you say " If you have not
>>built a file system under the jail" I assume you mean creating the 
>>necessary
>>sub directories with the necessary files in them for the shell which 
>>tested fine
>>by manually running the command.
>>
>>Am I missing something with the dot? I just added the dot to the home dir
>>path in the etc/passwd file.
>>
>>--Mike
>>
>>
>>John Robson wrote:
>>
>> 
>>
>>    
>>
>>>You could have just installed the rpm then replaced the binary.  That
>>>      
>>>
>would
>  
>
>>>give you all the relevant autostart functionality.
>>>
>>>However, the appropriate /rc.d/ script wouldn't be hard to put together -
>>>your easier alternative would be an inittab entry...
>>>
>>>If you are not getting chrooted then the patch isn't working.  Assuming
>>>      
>>>
>you
>  
>
>>>have built a complete chroot jail then you should see your path as /test/
>>>If you have not built a file system under the jail then you'll not get to
>>>log in, because there will be no shell for you to use.
>>>
>>>HTH
>>>
>>>John
>>>
>>>
>>>-----Original Message-----
>>>From: Michael Robokoff [mailto:mr...@mr...]
>>>Sent: 06 August 2003 18:49
>>>To: chr...@li...
>>>Subject: [Chrootssh-users] Chroot not working
>>>
>>>
>>>I am running redhat 9, I removed all the ssh rpms
>>>and got the pre patched tarball. I installed it as
>>>indicated and I tested the chroot function and
>>>that works fine. The w problems I see is I have to
>>>manually start sshd. I think a /etc/rc.d/init.d/
>>>script would be nice. Other than that I can ssh in
>>>but chroot does not appear to work I have the
>>>users path as /home/./test in the password file and
>>>the actual path is /home/test.
>>>
>>>Does anyone have any ideas?
>>>
>>>All help is appreciated.
>>>
>>>--Mike
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>>Data Reports, E-commerce, Portals, and Forums are available now.
>>>Download today and enter to win an XBOX or Visual Studio .NET.
>>>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/0
>>>      
>>>
>1
>  
>
>>>_______________________________________________
>>>Chrootssh-users mailing list
>>>Chr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/chrootssh-users
>>>
>>>
>>>   
>>>
>>>      
>>>

RE: [Chrootssh-users] Chroot not working

[John R. <JR...@da...>]

The passwd file needs /./ (which your directory has)

Are you sure that is still present (in the passwd file)?
You are sure you have the right tarball... (Worth checking)
Have you got debug output from the server (run it manually with -ddd)

It is only a few lines of code change to the server binary so a straight
swap of that would have done the trick. (Still would if you decided to
reinstall)

As your chroot jail is working FOR ROOT (who may have extra permisisons on
the files therein) we can assume that the file system in yout chroot jail is
OK. [The sysmptoms of it not being OK would be that the SSH session would
log straight back out again, we're not there yet so I'll ignore it for the
mo.]

The debug output should help determine why it isn't chrooting.

Cheers

-----Original Message-----
From: Michael Robokoff [mailto:mr...@mr...]
Sent: 07 August 2003 14:50
To: John Robson
Cc: chr...@li...
Subject: Re: [Chrootssh-users] Chroot not working


I did put together a script to start it. I didn't know however you could 
just
replace the binary That would have been a lot easier. Anyway ssh works
fine I can log in as my test user but I do not get chrooted. So I login as
root and run the chroot command to that dir and it works fine all the
necessary libraries are in place and work.  When you say " If you have not
built a file system under the jail" I assume you mean creating the 
necessary
sub directories with the necessary files in them for the shell which 
tested fine
by manually running the command.

Am I missing something with the dot? I just added the dot to the home dir
path in the etc/passwd file.

--Mike


John Robson wrote:

>You could have just installed the rpm then replaced the binary.  That would
>give you all the relevant autostart functionality.
>
>However, the appropriate /rc.d/ script wouldn't be hard to put together -
>your easier alternative would be an inittab entry...
>
>If you are not getting chrooted then the patch isn't working.  Assuming you
>have built a complete chroot jail then you should see your path as /test/
>If you have not built a file system under the jail then you'll not get to
>log in, because there will be no shell for you to use.
>
>HTH
>
>John
>
>
>-----Original Message-----
>From: Michael Robokoff [mailto:mr...@mr...]
>Sent: 06 August 2003 18:49
>To: chr...@li...
>Subject: [Chrootssh-users] Chroot not working
>
>
>I am running redhat 9, I removed all the ssh rpms
>and got the pre patched tarball. I installed it as
>indicated and I tested the chroot function and
>that works fine. The w problems I see is I have to
>manually start sshd. I think a /etc/rc.d/init.d/
>script would be nice. Other than that I can ssh in
>but chroot does not appear to work I have the
>users path as /home/./test in the password file and
>the actual path is /home/test.
>
>Does anyone have any ideas?
>
>All help is appreciated.
>
>--Mike
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Chrootssh-users mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chrootssh-users
>  
>

Re: [Chrootssh-users] Chroot not working

[Michael R. <mr...@mr...>]

I did put together a script to start it. I didn't know however you could 
just
replace the binary That would have been a lot easier. Anyway ssh works
fine I can log in as my test user but I do not get chrooted. So I login as
root and run the chroot command to that dir and it works fine all the
necessary libraries are in place and work.  When you say " If you have not
built a file system under the jail" I assume you mean creating the 
necessary
sub directories with the necessary files in them for the shell which 
tested fine
by manually running the command.

Am I missing something with the dot? I just added the dot to the home dir
path in the etc/passwd file.

--Mike


John Robson wrote:

>You could have just installed the rpm then replaced the binary.  That would
>give you all the relevant autostart functionality.
>
>However, the appropriate /rc.d/ script wouldn't be hard to put together -
>your easier alternative would be an inittab entry...
>
>If you are not getting chrooted then the patch isn't working.  Assuming you
>have built a complete chroot jail then you should see your path as /test/
>If you have not built a file system under the jail then you'll not get to
>log in, because there will be no shell for you to use.
>
>HTH
>
>John
>
>
>-----Original Message-----
>From: Michael Robokoff [mailto:mr...@mr...]
>Sent: 06 August 2003 18:49
>To: chr...@li...
>Subject: [Chrootssh-users] Chroot not working
>
>
>I am running redhat 9, I removed all the ssh rpms
>and got the pre patched tarball. I installed it as
>indicated and I tested the chroot function and
>that works fine. The w problems I see is I have to
>manually start sshd. I think a /etc/rc.d/init.d/
>script would be nice. Other than that I can ssh in
>but chroot does not appear to work I have the
>users path as /home/./test in the password file and
>the actual path is /home/test.
>
>Does anyone have any ideas?
>
>All help is appreciated.
>
>--Mike
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Chrootssh-users mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chrootssh-users
>  
>

RE: [Chrootssh-users] Chroot not working

[John R. <JR...@da...>]

You could have just installed the rpm then replaced the binary.  That would
give you all the relevant autostart functionality.

However, the appropriate /rc.d/ script wouldn't be hard to put together -
your easier alternative would be an inittab entry...

If you are not getting chrooted then the patch isn't working.  Assuming you
have built a complete chroot jail then you should see your path as /test/
If you have not built a file system under the jail then you'll not get to
log in, because there will be no shell for you to use.

HTH

John


-----Original Message-----
From: Michael Robokoff [mailto:mr...@mr...]
Sent: 06 August 2003 18:49
To: chr...@li...
Subject: [Chrootssh-users] Chroot not working


I am running redhat 9, I removed all the ssh rpms
and got the pre patched tarball. I installed it as
indicated and I tested the chroot function and
that works fine. The w problems I see is I have to
manually start sshd. I think a /etc/rc.d/init.d/
script would be nice. Other than that I can ssh in
but chroot does not appear to work I have the
users path as /home/./test in the password file and
the actual path is /home/test.

Does anyone have any ideas?

All help is appreciated.

--Mike



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Chrootssh-users mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chrootssh-users

[Chrootssh-users] Chroot not working

[Michael R. <mr...@mr...>]

I am running redhat 9, I removed all the ssh rpms
and got the pre patched tarball. I installed it as
indicated and I tested the chroot function and
that works fine. The w problems I see is I have to
manually start sshd. I think a /etc/rc.d/init.d/
script would be nice. Other than that I can ssh in
but chroot does not appear to work I have the
users path as /home/./test in the password file and
the actual path is /home/test.

Does anyone have any ideas?

All help is appreciated.

--Mike

RE: [Chrootssh-users] chrootsftp - missing hint

[John R. <JR...@da...>]

Give the user(s) /bin/false as their shell.  That should jinder their
attempts to get an interactive session quite nicely.

John

-----Original Message-----
From: Erik Groennerud [mailto:Eri...@An...]
Sent: 04 July 2003 16:24
To: chr...@li...
Subject: [Chrootssh-users] chrootsftp - missing hint



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear chrootsft,

thanks for your nice patch.

I have one hint which wasn't in your documentation:

I needed for chrootsftp one /etc/passwd and /etc/group in the
chroot-envirement because sshd wanted to know the name of the uid and =
gui.
With the two files all worked perfect.

My next thing is to make sftp-server compiled as hole thing so that no
libraries are needed.
Hits will come, if you want it?

Is it possible so stop logging in in the chroot-envirement with ssh? I =
want
sftp but no ssh.

Best regards

Erik Gr=F8nnerud

- -----------------------------------
antwerpes ag
Erik Gr=F8nnerud
Systemadministrator
Vogelsanger Stra=DFe 66
D - 50823 K=F6ln
Fon: +49.221.92053-182
Fax: +49.221.92053-133
http://www.antwerpes.ag
mailto:eri...@an...
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPwWcGMtzU5XCCfBSEQIJAwCgzSzThMrg4yxFjwgCcVsfhzwh3jEAoI42
7q/2pHSWXpUIEdjNTpMe42ui
=3DI5m9
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01=

_______________________________________________
Chrootssh-users mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chrootssh-users

[Chrootssh-users] chrootsftp - missing hint

[Erik G. <Eri...@An...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear chrootsft,

thanks for your nice patch.

I have one hint which wasn't in your documentation:

I needed for chrootsftp one /etc/passwd and /etc/group in the
chroot-envirement because sshd wanted to know the name of the uid and gui.
With the two files all worked perfect.

My next thing is to make sftp-server compiled as hole thing so that no
libraries are needed.
Hits will come, if you want it?

Is it possible so stop logging in in the chroot-envirement with ssh? I want
sftp but no ssh.

Best regards

Erik Grønnerud

- -----------------------------------
antwerpes ag
Erik Grønnerud
Systemadministrator
Vogelsanger Straße 66
D - 50823 Köln
Fon: +49.221.92053-182
Fax: +49.221.92053-133
http://www.antwerpes.ag
mailto:eri...@an...
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPwWcGMtzU5XCCfBSEQIJAwCgzSzThMrg4yxFjwgCcVsfhzwh3jEAoI42
7q/2pHSWXpUIEdjNTpMe42ui
=I5m9
-----END PGP SIGNATURE-----

[Chrootssh-users] User not automatically being Chrooted

[Michael C. <pu...@mj...>]

Hi,

I am trying to set things up so that I can allow a user to login via SSH =
but be restricted to their home directory.  I have created a chroot =
environment in /home/nomad (by placing the required folders and files in =
there) and I can now do "chroot /home/nomad" and things will work as =
expected.

I have changed the home of the user to /home/nomad/./
The problem is that when I log in as the user, either on the machine =
itself or through ssh, the user does not become automatically chrooted.  =
Ie. the user can still cd out of the /home/user.
I followed the instructions on this site (and am using a patched version =
of ssh) and I can't see anything that I have missed.

Any ideas as to what I could have missed?  I was under the impression =
that it was the "/home/nomad/./" setting for the user's home that =
defined the fact that the user should be chrooted and that it would =
either work or throw up an error (if something wasn't right.)  Just now =
it just seems to be ignoring the /./ in the user's home directory =
setting.  I am running RH9

Thanks=20


---
Michael Christie

This message has been certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 25/06/2003


---
Michael Christie

This message has been certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 25/06/2003

[Chrootssh-users] Using CHROOT ssh on FreeBSD 4.8

[Krux <kr...@th...>]

I installed openssh-3.6.1p1-chroot on a FreeBSD 4.8 system, setup the chroot
environment correctly  chroot /chrootdirectory /bin/sh worked
The problem is when users log in, they are not getting chrooted.

here is what I get

%sftp localhost
Connecting to localhost...
krux@localhost's password:
sftp> pwd
Remote working directory: /usr/home/krux
sftp> exit


here is the debug log

/usr/local/sbin/sshd -ddd
debug2: read_server_config: filename /usr/local/etc/sshd_config
debug1: sshd version OpenSSH_3.6.1p1
debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
Connection from ::1 port 1494
debug1: Client protocol version 2.0; client software version OpenSSH_3.6.1p1
debug1: match: OpenSSH_3.6.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1
debug2: Network child is on pid 20173
debug3: privsep user:group 22:22
debug3: preauth child monitor started
debug1: permanently_set_uid: 22/22
debug3: mm_request_receive entering
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rij...@ly...
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rij...@ly...
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rij...@ly...
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rij...@ly...
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hma...@op...,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug3: mm_request_send entering: type 0
debug3: monitor_read: checking request 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_answer_moduli: got parameters: 1024 2048 8192
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_send entering: type 1
debug3: mm_request_receive entering
debug2: monitor_read: 0 used once, disabling now
debug3: mm_choose_dh: remaining 0
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 1602/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 1592/3191
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: monitor_read: checking request 4
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_answer_sign
debug3: mm_request_receive_expect entering: type 5
debug3: mm_answer_sign: signature 0x8105000(143)
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 5
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: monitor_read: 4 used once, disabling now
debug2: kex_derive_keys
debug3: mm_request_receive entering
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user krux service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: monitor_read: checking request 6
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_answer_pwnamallow
debug3: mm_request_receive_expect entering: type 7
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 7
debug2: input_userauth_request: setting up authctxt for krux
debug2: monitor_read: 6 used once, disabling now
debug3: mm_inform_authserv entering
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 3
debug3: monitor_read: checking request 3
debug2: input_userauth_request: try method none
debug3: mm_answer_authserv: service=ssh-connection, style=
debug3: mm_auth_password entering
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_send entering: type 10
debug3: mm_request_receive entering
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: monitor_read: checking request 10
debug3: mm_request_receive_expect entering: type 11
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 11
debug3: mm_auth_password: user not authenticated
Failed none for krux from ::1 port 1494 ssh2
Failed none for krux from ::1 port 1494 ssh2
debug3: mm_request_receive entering
debug1: userauth-request for user krux service ssh-connection method
keyboard-interactive
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=krux devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices
Failed keyboard-interactive for krux from ::1 port 1494 ssh2
debug1: userauth-request for user krux service ssh-connection method password
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method password
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: monitor_read: checking request 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_answer_authpassword: sending result 1
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_send entering: type 11
debug3: mm_request_receive entering
Accepted password for krux from ::1 port 1494 ssh2
debug3: mm_auth_password: user authenticated
debug1: monitor_child_preauth: krux has been authenticated by privileged
process
Accepted password for krux from ::1 port 1494 ssh2
debug3: mm_get_keystate: Waiting for new keys
debug3: mm_request_receive_expect entering: type 24
debug3: mm_send_keystate: Sending new keys: 0x8106200 0x81061c0
debug3: mm_request_receive entering
debug3: mm_newkeys_to_blob: converting 0x8106200
debug3: mm_newkeys_to_blob: converting 0x81061c0
debug3: mm_send_keystate: New keys have been sent
debug3: mm_send_keystate: Sending compression state
debug3: mm_request_send entering: type 24
debug3: mm_newkeys_from_blob: 0x8104400(118)
debug3: mm_send_keystate: Finished sending state
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 0x8104400(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Getting compression state
debug3: mm_get_keystate: Getting Network I/O buffers
debug3: mm_share_sync: Share sync
debug3: mm_share_sync: Share sync end
debug2: User child is on pid 20174
debug2: set_newkeys: mode 0
debug3: mm_request_receive entering
debug2: set_newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug1: fd 4 setting O_NONBLOCK
debug1: fd 8 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request subsystem reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req subsystem
subsystem request for sftp
debug1: subsystem: exec() /usr/local/libexec/sftp-server
debug1: fd 10 setting O_NONBLOCK
debug2: fd 10 is O_NONBLOCK
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: Received SIGCHLD.
debug1: channel 0: output drain -> closed
debug2: notify_done: reading
debug1: session_by_pid: pid 20175
debug1: session_exit_message: session 0 channel 0 pid 20175
debug1: channel 0: request exit-status
debug1: session_exit_message: release channel 0
debug1: session_close: session 0 pid 20175
debug1: channel 0: read<=0 rfd 10 len 0
debug1: channel 0: read failed
debug1: channel 0: close_read
debug1: channel 0: input open -> drain
debug1: channel 0: ibuf empty
debug1: channel 0: send eof
debug1: channel 0: input drain -> closed
debug1: channel 0: send close
debug3: channel 0: will not send data after close
debug1: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: server-session, nchannels 1
debug3: channel_free: status: The following connections are open:\015
  #0 server-session (t4 r0 i3/0 o3/0 fd 10/10)\015

debug3: channel_close_fds: channel 0: r 10 w 10 e -1
Connection closed by ::1
Closing connection to ::1
debug3: mm_request_send entering: type 42
debug3: monitor_read: checking request 42
debug3: mm_answer_term: tearing down sessions

[Chrootssh-users] ...on FreeBSD4_8REL

[Andy K. <an...@sy...>]

Hmm, fail to see how this patch is supposed to work.
I followed the instructions and testing $ chroot /home/user /bin/sh
worked a treat so I know I had the setup correct.

So I hacked the code and added in some debugging.
It seems to me the chroot call is made after the
child process has changed it's uid/gid away from
the super-user process. chroot doesn't work if
your not a super-user ????

Explanations on a pCard

fwiw, FreeBSD 4.8 REL, using 3.6.1 patch (applying
and build the patch was fine, just didn't chroot
on login)

--Ak