Fwd: [Re: openpty() and jail in RELENG_7]
- Forwarded message from Dan Epure [EMAIL PROTECTED] - Date: Thu, 15 Nov 2007 19:11:43 +0200 From: Dan Epure [EMAIL PROTECTED] To: John Baldwin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: openpty() and jail in RELENG_7 The /etc/defaults/devfs.rules version is: # $FreeBSD: src/etc/defaults/devfs.rules,v 1.4.2.1 2007/11/11 22:52:31 csjp Exp $ This solved my problem. But other issues came out. 1. The following patch would help the stop/start of the jail (now, if you stop and start a jail /dev/pts and /dev/pty would not show again): === cut here === *** /usr/src/etc/defaults/devfs.rules Mon Nov 12 09:56:30 2007 --- /etc/defaults/devfs.rules Thu Nov 15 18:20:35 2007 *** *** 54,56 --- 54,58 add path 'ttyS*' unhide + add path 'pts' unhide add path 'pts/*' unhide + add path 'pty' unhide add path 'pty/*' unhide === and here === 2. I noticed a strange behavior. === cut here === # ls -la /dev/pt[sy]/ /dev/pts/: total 1 dr-xr-xr-x 2 root wheel 512 Nov 15 18:46 . dr-xr-xr-x 6 root wheel 512 Nov 15 18:42 .. crw-rw-rw- 1 root wheel0, 95 Nov 15 18:48 0 /dev/pty/: total 1 dr-xr-xr-x 2 root wheel 512 Nov 15 18:46 . dr-xr-xr-x 6 root wheel 512 Nov 15 18:42 .. crw-rw-rw- 1 root wheel0, 93 Nov 15 18:48 0 # ls -la /dev/ptmx crw-rw-rw- 1 root wheel0, 99 Nov 15 18:41 /dev/ptmx # ls -la /dev/pt[sy] /dev/pts: total 1 dr-xr-xr-x 2 root wheel 512 Nov 15 18:45 . dr-xr-xr-x 6 root wheel 512 Nov 15 18:41 .. crw--w 1 gepu tty 0, 95 Nov 15 19:06 0 /dev/pty: total 1 dr-xr-xr-x 2 root wheel 512 Nov 15 18:45 . dr-xr-xr-x 6 root wheel 512 Nov 15 18:41 .. crw-rw-rw- 1 root wheel0, 93 Nov 15 19:06 0 crw-rw-rw- 1 root wheel0, 99 Nov 15 18:41 1 crw-rw-rw- 1 root wheel0, 100 Nov 15 18:41 2 === and here === for every ls -la /dev/ptmx I get another two entries in /dev/pty and no aditional entry in /dev/pts. I can repeat this until I reach kern.pts.max in /dev/pty. At this moment there is not available pty. Regards, Gepu On Thu, Nov 15, 2007 at 08:56:34AM -0500, John Baldwin wrote: On Sunday 11 November 2007 06:24:56 am Dan Epure wrote: Maybe I have better luck here: Do you have the recent fix to unhide /dev/pts devices in the default jail rules for devfs? -- John Baldwin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] - End forwarded message - ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Christian, Christian S.J. Peron wrote: Please try the attached patch. I have committed this to head and it somehow slipped through the cracks in terms of an MFC (patch /etc/defaults/devfs.rules) Do we need to expose /dev/ptmx as well? A glance at the code seems to be necessary if we want to use pts, but I need to dig deeper to confirm. Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHONWxhcUczkLqiksRAhJmAKCv66+cvroD0mrTJcB5JII855dPtQCfZ0cj iIQ3fcYOtNY4m213YS8UNc4= =SGEr -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
Please try the attached patch. I have committed this to head and it somehow slipped through the cracks in terms of an MFC (patch /etc/defaults/devfs.rules) On Thu, Nov 08, 2007 at 07:30:39PM +0200, Dan Epure wrote: I can provide more info on request. - Forwarded message from Dan Epure [EMAIL PROTECTED] - Date: Wed, 7 Nov 2007 19:25:08 +0200 From: Dan Epure [EMAIL PROTECTED] To: Tom Evans [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: openpty() and jail in RELENG_7 Thank you for your answer. This is not Xin Li's scenario. Description: the host of the jail - H (192.168.168.2/24) the jail running on H - J (192.168.168.254/32) the testing system - T (192.168.168.253/24) 1. I start the ssh daemon on H: === cut here === H# /usr/sbin/sshd -d debug1: sshd version OpenSSH_4.5p1 FreeBSD-20061110 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 192.168.168.2. Server listening on 192.168.168.2 port 22. === and here === 2. On T I run: === cut here === T# ssh 192.168.168.2 -l test2 === and here === 3. On H I see: === cut here === Debug1: fd 4 clearing O_NONBLOCK Debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 debug1: res_init() Connection from 192.168.168.253 port 60155 debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1 Debian-5 debug1: match: OpenSSH_4.6p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: 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 test2 service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for test2 debug1: userauth-request for user test2 service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: PAM: setting PAM_RHOST to 192.168.168.253 debug1: test whether pkalg/pkblob are acceptable debug1: trying public key file /home/test2/.ssh/authorized_keys debug1: trying public key file /home/test2/.ssh/authorized_keys2 Failed publickey for test2 from 192.168.168.253 port 60155 ssh2 debug1: audit_event: unhandled event 6 debug1: userauth-request for user test2 service ssh-connection method keyboard-interactive debug1: attempt 2 failures 2 debug1: keyboard-interactive devs debug1: auth2_challenge: user=test2 devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. 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_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/3 debug1: Ignoring unsupported tty mode opcode 37 (0x25) debug1: Ignoring unsupported tty mode opcode 52 (0x34) debug1: Ignoring unsupported tty mode opcode 71 (0x47) 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: PAM: setting PAM_TTY to /dev/pts/3 debug1: Setting controlling tty using TIOCSCTTY. === and here === 4. On T I am logged in on H: === cut here === Password: H$ === and here === 5. I start the jail on H: === cut here === H
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
I just used the patch and it is working. Thank you, Gepu On Sun, Nov 11, 2007 at 09:31:12AM -0600, Christian S.J. Peron wrote: Please try the attached patch. I have committed this to head and it somehow slipped through the cracks in terms of an MFC (patch /etc/defaults/devfs.rules) On Thu, Nov 08, 2007 at 07:30:39PM +0200, Dan Epure wrote: I can provide more info on request. - Forwarded message from Dan Epure [EMAIL PROTECTED] - Date: Wed, 7 Nov 2007 19:25:08 +0200 From: Dan Epure [EMAIL PROTECTED] To: Tom Evans [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: openpty() and jail in RELENG_7 Thank you for your answer. This is not Xin Li's scenario. Description: the host of the jail - H (192.168.168.2/24) the jail running on H - J (192.168.168.254/32) the testing system - T (192.168.168.253/24) 1. I start the ssh daemon on H: === cut here === H# /usr/sbin/sshd -d debug1: sshd version OpenSSH_4.5p1 FreeBSD-20061110 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 192.168.168.2. Server listening on 192.168.168.2 port 22. === and here === 2. On T I run: === cut here === T# ssh 192.168.168.2 -l test2 === and here === 3. On H I see: === cut here === Debug1: fd 4 clearing O_NONBLOCK Debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 debug1: res_init() Connection from 192.168.168.253 port 60155 debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1 Debian-5 debug1: match: OpenSSH_4.6p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: 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 test2 service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for test2 debug1: userauth-request for user test2 service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: PAM: setting PAM_RHOST to 192.168.168.253 debug1: test whether pkalg/pkblob are acceptable debug1: trying public key file /home/test2/.ssh/authorized_keys debug1: trying public key file /home/test2/.ssh/authorized_keys2 Failed publickey for test2 from 192.168.168.253 port 60155 ssh2 debug1: audit_event: unhandled event 6 debug1: userauth-request for user test2 service ssh-connection method keyboard-interactive debug1: attempt 2 failures 2 debug1: keyboard-interactive devs debug1: auth2_challenge: user=test2 devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. 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_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/3 debug1: Ignoring unsupported tty mode opcode 37 (0x25) debug1: Ignoring unsupported tty mode opcode 52 (0x34) debug1: Ignoring unsupported tty mode opcode 71 (0x47) 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
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/11/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. Unfortunately, this doesn't fix the problems with screen :( -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Sun, Nov 11, 2007 at 10:17:31PM +0200, Vlad GALU wrote: On 11/11/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. Unfortunately, this doesn't fix the problems with screen :( Which? I can look into it. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/12/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 10:17:31PM +0200, Vlad GALU wrote: On 11/11/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. Unfortunately, this doesn't fix the problems with screen :( Which? I can look into it. This one: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html Thanks! -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Mon, Nov 12, 2007 at 01:14:14AM +0200, Vlad GALU wrote: [..] This one: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html Thanks! Ah.. ok. At first glance this doesn't look like a problem. This is actually looks like a side effect of devices which support cloning. Even though a device has been closed, it's existence will persist within the devfs directory entries. devfs should garbage collect this when its required. But I will confirm. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/12/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 01:14:14AM +0200, Vlad GALU wrote: [..] This one: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html Thanks! Ah.. ok. At first glance this doesn't look like a problem. This is actually looks like a side effect of devices which support cloning. Even though a device has been closed, it's existence will persist within the devfs directory entries. devfs should garbage collect this when its required. But I will confirm. I tested by setting kern.pts.max to an appropriately small value, such as 20-30, then opening many ptys from within screen. Even after closing all of them and exiting screen, the cleanup wasn't done. Thanks once again for your attention! -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
I can provide more info on request. - Forwarded message from Dan Epure [EMAIL PROTECTED] - Date: Wed, 7 Nov 2007 19:25:08 +0200 From: Dan Epure [EMAIL PROTECTED] To: Tom Evans [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: openpty() and jail in RELENG_7 Thank you for your answer. This is not Xin Li's scenario. Description: the host of the jail - H (192.168.168.2/24) the jail running on H - J (192.168.168.254/32) the testing system - T (192.168.168.253/24) 1. I start the ssh daemon on H: === cut here === H# /usr/sbin/sshd -d debug1: sshd version OpenSSH_4.5p1 FreeBSD-20061110 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 192.168.168.2. Server listening on 192.168.168.2 port 22. === and here === 2. On T I run: === cut here === T# ssh 192.168.168.2 -l test2 === and here === 3. On H I see: === cut here === Debug1: fd 4 clearing O_NONBLOCK Debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 debug1: res_init() Connection from 192.168.168.253 port 60155 debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1 Debian-5 debug1: match: OpenSSH_4.6p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: 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 test2 service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for test2 debug1: userauth-request for user test2 service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: PAM: setting PAM_RHOST to 192.168.168.253 debug1: test whether pkalg/pkblob are acceptable debug1: trying public key file /home/test2/.ssh/authorized_keys debug1: trying public key file /home/test2/.ssh/authorized_keys2 Failed publickey for test2 from 192.168.168.253 port 60155 ssh2 debug1: audit_event: unhandled event 6 debug1: userauth-request for user test2 service ssh-connection method keyboard-interactive debug1: attempt 2 failures 2 debug1: keyboard-interactive devs debug1: auth2_challenge: user=test2 devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. 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_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/3 debug1: Ignoring unsupported tty mode opcode 37 (0x25) debug1: Ignoring unsupported tty mode opcode 52 (0x34) debug1: Ignoring unsupported tty mode opcode 71 (0x47) 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: PAM: setting PAM_TTY to /dev/pts/3 debug1: Setting controlling tty using TIOCSCTTY. === and here === 4. On T I am logged in on H: === cut here === Password: H$ === and here === 5. I start the jail on H: === cut here === H# /etc/rc.d/jail start Configuring jails:. Starting jails: test2.mydomain.org. 6. I start the ssh daemon on J: === cut here === J# /usr/sbin/sshd -d debug1: sshd version OpenSSH_4.5p1 FreeBSD-20061110 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d
Re: openpty() and jail in RELENG_7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Epure wrote: Thank you for your answer. This is not Xin Li's scenario. That's true, these are different scenarios. I think it is caused by some devfs.rules(5) configuration issue, as if you mount the whole devfs into /dev, you will have openpty() to succeed. I have not yet determined which is the device that is needed for openpty(), maybe cognet@ or someone can shed us some light before we digging the code? Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHM7WDhcUczkLqiksRAnzeAJ0eMNWxPYTJmeV4rfC0mYAbSglOlgCg6dHA OkYa+PPR2776dKAe7CAp9ZU= =lYYv -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: openpty() and jail in RELENG_7
On Tue, 2007-11-06 at 22:19 +0200, Dan Epure wrote: Hi All, I'm using on the host system (7.0-BETA2): #sysctl kern.pts.enable kern.pts.enable: 1 I have no problem at all. The jail is also 7.0-BETA2 The problem is inside the jail openpty() can not allocate the pty: === cut here === debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. 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_new: init debug1: session_new: session 0 openpty: No such file or directory session_pty_req: session 0 alloc failed 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 === and here === the ssh session just hangs. (no pty ?) I did not forget to mount devfs inside the jail. The jail is configured in rc.conf: === cut here === jail_enable=YES jail_list=test jail_test_hostname=test.mydomain.org jail_test_rootdir=/jails/test jail_test_interface=bge0 jail_test_devfs_enable=YES jail_test_ip=192.168.10.2 jail_set_hostname_allow=NO jail_sysvipc_allow=NO jail_socket_unixiproute_only=YES === and here === I think the problem is related to restrictions imposed by the jail. Please advise. Gepu This is because you haven't been allocated a pty inside your jail. Enable sshd inside your jail, ssh to your jail (which will allocate you a pty). Then from inside your jail, you can use any pty-using application you wish. I am presuming you are doing something like 'jexec 1 /bin/csh' or similar, and I'm only really repeating Xin Li's advice to me[1]. Cheers Tom [1] http://lists.freebsd.org/pipermail/freebsd-jail/2007-October/000106.html signature.asc Description: This is a digitally signed message part
Re: openpty() and jail in RELENG_7
On Wed, 2007-11-07 at 16:21 +0200, Vlad GALU wrote: On 11/7/07, Tom Evans [EMAIL PROTECTED] wrote: On Tue, 2007-11-06 at 22:19 +0200, Dan Epure wrote: Hi All, snip I think the problem is related to restrictions imposed by the jail. Please advise. Gepu This is because you haven't been allocated a pty inside your jail. Enable sshd inside your jail, ssh to your jail (which will allocate you a pty). Then from inside your jail, you can use any pty-using application you wish. I am presuming you are doing something like 'jexec 1 /bin/csh' or similar, and I'm only really repeating Xin Li's advice to me[1]. Cheers Tom [1] http://lists.freebsd.org/pipermail/freebsd-jail/2007-October/000106.html I'm chiming in to signal a possibly related problem. Logging in and out via sshd behaves normally (ie: the ptys are cleaned up accordingly) but opening virtual consoles in screen and then closing them does not, thus leading to starvation. I can confirm this also occurs in our jails on 6.2-RELEASE-p5. Tom signature.asc Description: This is a digitally signed message part
Re: openpty() and jail in RELENG_7
Thank you for your answer. This is not Xin Li's scenario. Description: the host of the jail - H (192.168.168.2/24) the jail running on H - J (192.168.168.254/32) the testing system - T (192.168.168.253/24) 1. I start the ssh daemon on H: === cut here === H# /usr/sbin/sshd -d debug1: sshd version OpenSSH_4.5p1 FreeBSD-20061110 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 192.168.168.2. Server listening on 192.168.168.2 port 22. === and here === 2. On T I run: === cut here === T# ssh 192.168.168.2 -l test2 === and here === 3. On H I see: === cut here === Debug1: fd 4 clearing O_NONBLOCK Debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 debug1: res_init() Connection from 192.168.168.253 port 60155 debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1 Debian-5 debug1: match: OpenSSH_4.6p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: 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 test2 service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for test2 debug1: userauth-request for user test2 service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: PAM: setting PAM_RHOST to 192.168.168.253 debug1: test whether pkalg/pkblob are acceptable debug1: trying public key file /home/test2/.ssh/authorized_keys debug1: trying public key file /home/test2/.ssh/authorized_keys2 Failed publickey for test2 from 192.168.168.253 port 60155 ssh2 debug1: audit_event: unhandled event 6 debug1: userauth-request for user test2 service ssh-connection method keyboard-interactive debug1: attempt 2 failures 2 debug1: keyboard-interactive devs debug1: auth2_challenge: user=test2 devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. 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_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/3 debug1: Ignoring unsupported tty mode opcode 37 (0x25) debug1: Ignoring unsupported tty mode opcode 52 (0x34) debug1: Ignoring unsupported tty mode opcode 71 (0x47) 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: PAM: setting PAM_TTY to /dev/pts/3 debug1: Setting controlling tty using TIOCSCTTY. === and here === 4. On T I am logged in on H: === cut here === Password: H$ === and here === 5. I start the jail on H: === cut here === H# /etc/rc.d/jail start Configuring jails:. Starting jails: test2.mydomain.org. 6. I start the ssh daemon on J: === cut here === J# /usr/sbin/sshd -d debug1: sshd version OpenSSH_4.5p1 FreeBSD-20061110 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 192.168.168.254. Server listening on 192.168.168.254 port 22. === and here === 7. On T I run: === cut here === T# ssh 192.168.168.254 -l test2 === and here === 8. On J I see: === cut here === debug1: fd 4 clearing O_NONBLOCK debug1: Server will not fork
Re: openpty() and jail in RELENG_7
On 11/7/07, Tom Evans [EMAIL PROTECTED] wrote: On Tue, 2007-11-06 at 22:19 +0200, Dan Epure wrote: Hi All, I'm using on the host system (7.0-BETA2): #sysctl kern.pts.enable kern.pts.enable: 1 I have no problem at all. The jail is also 7.0-BETA2 The problem is inside the jail openpty() can not allocate the pty: === cut here === debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. 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_new: init debug1: session_new: session 0 openpty: No such file or directory session_pty_req: session 0 alloc failed 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 === and here === the ssh session just hangs. (no pty ?) I did not forget to mount devfs inside the jail. The jail is configured in rc.conf: === cut here === jail_enable=YES jail_list=test jail_test_hostname=test.mydomain.org jail_test_rootdir=/jails/test jail_test_interface=bge0 jail_test_devfs_enable=YES jail_test_ip=192.168.10.2 jail_set_hostname_allow=NO jail_sysvipc_allow=NO jail_socket_unixiproute_only=YES === and here === I think the problem is related to restrictions imposed by the jail. Please advise. Gepu This is because you haven't been allocated a pty inside your jail. Enable sshd inside your jail, ssh to your jail (which will allocate you a pty). Then from inside your jail, you can use any pty-using application you wish. I am presuming you are doing something like 'jexec 1 /bin/csh' or similar, and I'm only really repeating Xin Li's advice to me[1]. Cheers Tom [1] http://lists.freebsd.org/pipermail/freebsd-jail/2007-October/000106.html I'm chiming in to signal a possibly related problem. Logging in and out via sshd behaves normally (ie: the ptys are cleaned up accordingly) but opening virtual consoles in screen and then closing them does not, thus leading to starvation. -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
openpty() and jail in RELENG_7
Hi All, I'm using on the host system (7.0-BETA2): #sysctl kern.pts.enable kern.pts.enable: 1 I have no problem at all. The jail is also 7.0-BETA2 The problem is inside the jail openpty() can not allocate the pty: === cut here === debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. 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_new: init debug1: session_new: session 0 openpty: No such file or directory session_pty_req: session 0 alloc failed 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 === and here === the ssh session just hangs. (no pty ?) I did not forget to mount devfs inside the jail. The jail is configured in rc.conf: === cut here === jail_enable=YES jail_list=test jail_test_hostname=test.mydomain.org jail_test_rootdir=/jails/test jail_test_interface=bge0 jail_test_devfs_enable=YES jail_test_ip=192.168.10.2 jail_set_hostname_allow=NO jail_sysvipc_allow=NO jail_socket_unixiproute_only=YES === and here === I think the problem is related to restrictions imposed by the jail. Please advise. Gepu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
