Hi all,
The truss command gets very very long/complicated.
I've executed the perl monitor component from both the SO ( where it works perfectly ) and within the mon with the verbose mode activated on the ssh client.
The results:
** From within the "mon" daemon ( Not working)
OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Connecting to ukbhu032t [192.168.0.115] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/1
debug1: identity file /.ssh/identity type 0
debug1: identity file /.ssh/id_rsa type 1
debug1: identity file /.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.0.1
debug1: match: Sun_SSH_1.0.1 pat Sun_SSH_1.0*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'ukbhu032t' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:16
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: /usr/bin/true
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1
** From the command line ( executing the same mon component code, using bash as root ).
OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Connecting to ukbhu032t [192.168.0.115] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/1
debug1: identity file /.ssh/identity type 0
debug1: identity file /.ssh/id_rsa type 1
debug1: identity file /.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.0.1
debug1: match: Sun_SSH_1.0.1 pat Sun_SSH_1.0*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'ukbhu032t' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:16
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: /usr/bin/true
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0
Any clues??
The command /usr/bin/true is being executed in both ocations and it returns 0 always.
Any help would be highly appreciated.
Best regards,
Kenneth Modrego
UNIX Systems Administrator
Europe & Africa Region
Toyota Financial Services (UK) PLC
Tel: +44 (0)1737 365509
Fax: +44 (0)1737 365520
mailto:[EMAIL PROTECTED]
| Alexander Piavka <[EMAIL PROTECTED]>
01/02/2005 09:21 |
|
run the truss comand with -f flag to trace the forked child
also try to mix the strace with debugging like:
>truss -f mon -c /etc/mon/mon.cf -d
On Fri, 28 Jan 2005, Kenneth Modrego wrote:
> Hi,
>
> I've done the truss leaving only the ssh alarm to that specific serveron
> the mon.cf,
> This is the output I get from a truss -p to the mon process
>
> stat64("/usr/local/mon/mon.d/ssh.monitor", 0x000EEE90) = 0
> pipe() = 8 [9]
> fork() = 23082
> close(9) = 0
> fcntl(8, F_SETFD, 0x00000001) = 0
> time() = 1106898684
> fcntl(8, F_GETFL, 0x0048F820) = 2
> fstat64(8, 0xFFBEF860) = 0
> fstat64(8, 0xFFBEF860) = 0
> fcntl(8, F_SETFL, 0x00000080) = 0
> fcntl(8, F_GETFD, 0x00000000) = 1
> fcntl(8, F_SETFD, 0x00000001) = 0
> time() = 1106898684
> poll(0xFFBEF910, 1, 0) = 0
> time() = 1106898684
> waitid(P_ALL, 0, 0xFFBEF8D8, WEXITED|WTRAPPED|WNOHANG) = 0
> poll(0xFFBEF950, 2, 1000) (sleeping...)
> poll(0xFFBEF950, 2, 1000) = 0
> time() = 1106898685
> time() = 1106898685
> poll(0xFFBEF910, 1, 0) = 1
> read(8, " u k b h u 0 3 2 t\n u k".., 8192) = 175
> read(8, 0x004B3008, 8192) = 0
> time() = 1106898685
> waitid(P_ALL, 0, 0xFFBEF8D8, WEXITED|WTRAPPED|WNOHANG) = 0
> read(8, 0x004B7008, 8192) = 0
> send(7, " < 2 6 > m o n [ 1 0 7 6".., 60, 0) = 60
> time() = 1106898685
> time() = 1106898685
> llseek(8, 0, SEEK_CUR) Err#29 ESPIPE
> close(8) = 0
> sigaction(SIGHUP, 0xFFBEF778, 0xFFBEF8D0) = 0
> sigaction(SIGINT, 0xFFBEF778, 0xFFBEF8B0) = 0
> sigaction(SIGQUIT, 0xFFBEF778, 0xFFBEF890) = 0
> waitid(P_PID, 23082, 0xFFBEF728, WEXITED|WTRAPPED) Err#10 ECHILD
> sigaction(SIGHUP, 0xFFBEF798, 0x00000000) = 0
> sigaction(SIGINT, 0xFFBEF798, 0x00000000) = 0
> sigaction(SIGQUIT, 0xFFBEF798, 0x00000000) = 0
> getcontext(0xFFBEF5A0)
> getcontext(0xFFBEF440)
> waitid(P_ALL, 0, 0xFFBEF8D8, WEXITED|WTRAPPED|WNOHANG) Err#10 ECHILD
>
>
> I cannot see anything wrong here.
> The thing that puzzles me is that the same exact perl module.
> "/usr/local/mon/mon.d/ssh.monitor", if I run it from the command line as
> root, it works fine.
> I cannot see what difference can it make running it from inside the
> process "mon".
>
> Best regards,
>
> Kenneth Modrego
> UNIX Systems Administrator
> Europe & Africa Region
> Toyota Financial Services (UK) PLC
> Tel: +44 (0)1737 365509
> Fax: +44 (0)1737 365520
> mailto:[EMAIL PROTECTED]
>
> Ed Ravin <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 28/01/2005 03:44
>
> To
> Kenneth Modrego <[EMAIL PROTECTED]>
> cc
> [email protected]
> Subject
> Re: SSH agent problem.
>
>
>
>
>
>
> On Wed, Jan 26, 2005 at 04:00:53PM +0000, Kenneth Modrego wrote:
> > I've got a Mon configuration (mon-0-99-2.6 ) with ssh and some other
> > agents that work perfectly with Solaris 8 clients/server.
> > The problem has appeared when I've installed a new Solaris 9 box, I'm
> > trying to get my mon server to check the ssh,
> > but it always comes back with an error 65280.
> > The strange thing is that when I try to execute the same command within
> > the shell, it returns a "0"
>
> Try using truss on Mon to see what syscalls are made when your monitor
> is run. I suspect the ssh command is balking because it can't
> find your home directory or some other config file it wants.
>
> _______________________________________________
> mon mailing list
> [email protected]
> http://linux.kernel.org/mailman/listinfo/mon
>
>
> This correspondence is for the intended recipient only. It may contain
> confidential or legally privileged information or both. No
> confidentiality or privilege is waived or lost by any mistransmission
> or unauthorised alteration during transmission.
>
> If you are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on
> it, is prohibited and may be unlawful. If you receive this
> correspondence in error, please immediately delete it from your system
> and notify the sender.
>
> Any views expressed in this message are those of the individual sender,
> except where the sender expressly, and with authority, states them to
> be the views of Toyota.
>
> This message has been checked for viruses but the recipient is strongly
> advised to rescan the message before opening any attachments or
> attached executable files.
This correspondence is for the intended recipient only. It may contain confidential or legally privileged information or both. No confidentiality or privilege is waived or lost by any mistransmission or unauthorised alteration during transmission. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Toyota. This message has been checked for viruses but the recipient is strongly advised to rescan the message before opening any attachments or attached executable files.
_______________________________________________ mon mailing list [email protected] http://linux.kernel.org/mailman/listinfo/mon
