Send Break to terminal server
Scott Burch
scott.burch at camberwind.com
Sat Jan 10 03:29:10 EST 2004
Hi,
What model sun server do you have? If you have a box with lom or alom
then get to the sc> prompt by typing #. and then type break -y to send a
break. (This works on some Netras, V440S, V240s, etc.)
-Scott
On Fri, 2004-01-09 at 09:28, Avis wrote:
> Darren, thanks.
> I did try all combinations of '~b', '~B', '~<ctrl-B>', and even '~<alt-B>'.
> With the debug, it's obvious that you were right, '~B' was the one that
> triggered the request break.
> However, nothing happen in the request break function.
> Is there something I need to set in the compilation?
> Is there a library that I am missing?
>
> Done.| ssh -vv sunfire1-ts
> OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
> debug1: Reading configuration data /home/Avis/.ssh/config
> debug1: Applying options for sunfire1-ts
> debug1: Reading configuration data /usr/local/etc/ssh_config
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to sts222 [172.16.24.222] port 2322.
> debug1: Connection established.
> debug1: identity file /home/Avis/.ssh/identity type -1
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug2: key_type_from_name: unknown key type '-----END'
> debug1: identity file /home/Avis/.ssh/id_rsa type 1
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug2: key_type_from_name: unknown key type '-----END'
> debug1: identity file /home/Avis/.ssh/id_dsa type 2
> debug1: Remote protocol version 1.99, remote software version LXSSH_3.6.1
> debug1: no match: LXSSH_3.6.1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
> 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,r
> ijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
> ijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
> ac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
> ac-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,r
> ijndael-cbc at lysator.liu.se
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r
> ijndael-cbc at lysator.liu.se
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
> ac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm
> ac-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: server->client aes128-cbc hmac-md5 none
> debug2: mac_init: found hmac-md5
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug2: dh_gen_key: priv key bits set: 119/256
> debug2: bits set: 1585/3191
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'sts222' is known and matches the RSA host key.
> debug1: Found key in /home/Avis/.ssh/known_hosts:29
> debug2: bits set: 1571/3191
> debug1: ssh_rsa_verify: signature correct
> debug2: kex_derive_keys
> 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: SSH2_MSG_SERVICE_REQUEST sent
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug2: key: /home/Avis/.ssh/identity (0x0)
> debug2: key: /home/Avis/.ssh/id_rsa (0x100f9508)
> debug2: key: /home/Avis/.ssh/id_dsa (0x100f9520)
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/Avis/.ssh/identity
> debug1: Offering public key: /home/Avis/.ssh/id_rsa
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Offering public key: /home/Avis/.ssh/id_dsa
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug2: we did not send a packet, disable method
> debug1: Next authentication method: keyboard-interactive
> debug2: userauth_kbdint
> debug2: we sent a keyboard-interactive packet, wait for reply
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug2: we did not send a packet, disable method
> debug1: Next authentication method: password
> InReach at sts222's password:
> debug2: we sent a password packet, wait for reply
> debug1: Authentication succeeded (password).
> debug1: channel 0: new [client-session]
> debug2: channel 0: send open
> debug1: Entering interactive session.
> debug2: callback start
> debug2: ssh_session2_setup: id 0
> debug2: channel 0: request pty-req
> debug2: channel 0: request shell
> debug2: fd 4 setting TCP_NODELAY
> debug2: callback done
> debug2: channel 0: open confirm rwindow 0 rmax 32768
> debug2: channel 0: rcvd adjust 131072
>
> bash-2.03# debug2: channel 0: request break
> ~B
> debug2: channel 0: written 4 to efd 7
>
> bash-2.03# debug2: channel 0: request break
> ~B
> debug2: channel 0: written 4 to efd 7
>
> bash-2.03#
>
> -----Original Message-----
> From: Darren Tucker [mailto:dtucker at zip.com.au]
> Sent: Thursday, January 08, 2004 6:58 PM
> To: Avis
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Send Break to terminal server
>
> Avis wrote:
> > Using ssh via cygwin, I tried to do '~ ctrl-B', but it will not drop to
> 'ok
> > prompt'.
>
> You don't need the CTRL.
>
> $ ~?
> Supported escape sequences:
> ~. - terminate connection
> ~B - send a BREAK to the remote system
> [snip]
>
> > Are the workarounds? (other than using Tera Term Pro?)
> Use less fingers :-)
>
> If that doesn't work, please post a debug trace, eg:
>
> ssh -vvv terminalserver
> [CR]~B
>
> Note that it's a capital B, so use shift not ctrl, and you must start
> the sequence with a carraige return. You should see something like this
> in the output:
> debug2: channel 0: request break
> debug2: channel 0: written 4 to efd 6
--
Scott Burch <scott.burch at camberwind.com>
More information about the openssh-unix-dev
mailing list