X11 forwarding with putty

Hi all,
I am using windows XP OS and I have installed oracle 10g release 2 on RHEL4 running on Vmware.Now I want to get the graphical interface from putty.Is it possible.I have tried forwarding X11 adding server through xhost+.However I am not quite sure that I am doing everything right.Please suggest.

Hi,
I think that is not possible ... Why don't you try [url http://www.linuxforums.org/forum/linux-tutorials-howtos-reference-material/971-installing-running-vnc-redhat-rpm-linux.html]vncserver? In addition, TightVNC and VNC both have excellent documentation on their respective webpages ...
Cheers
Legatti

Similar Messages

X11 Forwarding with SSH not working [SOLVED]

I'm trying to follow the X11 forwarding guide on the wiki but to no avail.
I'm using Putty and Xming from a Windows machine to SSH into the ArchLinux machine over my home network.
When I log in through SSH with X11 forwarding enabled, my display variable is set to "localhost:10.0". Running xclock gives me the following error: "Error: Can't open display: localhost:10.0".
I'm pretty sure Xming isn't the problem, since if I manually change the DISPLAY variable to "[my windows machine IP]:0.0", I can run xclock and see it appear.
From what I can see, it should be working.
Complete sshd_config below:
# $OpenBSD: sshd_config,v 1.87 2012/07/10 02:19:15 djm Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# The default requires explicit activation of protocol 1
#Protocol 2
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#RSAAuthentication yes
#PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedPrincipalsFile none
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /run/sshd.pid
#MaxStartups 10
PermitTunnel yes
#ChrootDirectory none
#VersionAddendum none
# no default banner path
Banner /etc/issue
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
Last edited by gixr (2013-01-11 22:37:35)

It's easy.
Start Xming.
Configure SSH (here's my confg):
# $OpenBSD: sshd_config,v 1.84 2011/05/23 03:30:07 djm Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# The default requires explicit activation of protocol 1
#Protocol 2
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#RSAAuthentication yes
#PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
Putty setting: http://i.ztjuh.tk/20130111075624803.png
Click on Open and run your program
Last edited by Ztjuh (2013-01-11 08:01:00)

Ssh X11 forwarding takes too long to start any app. remotely

Hi,
I have a bizzare problem with %subject% for some time already.
Affected are all my Arch linux installations (all with: systemd, openbox (without Display Manager), and latest updates):
1. home desktop (core 2 duo, 2.4GHz, 3GB RAM).
2. one testing desktop in virtualbox on the desktop from prev. point.
3. work laptop (Intel Core i5, 4GB RAM).
All of these are connected via cable to the same home network 100MB router (using openwrt on asus wl-500g).
Normal ssh transmissions, like entering commands, or transfer of data via scp (even large amount of data for testing purposes because of this) works quick like expected.
The problem is, that if I try to start app. remotely via ssh X forwarding from and to any of these (affected also bidirectional), it takes always aprox. 2 minutes to start the app.
Afterwards, it works fast and fine.
Doesn't change anything, whether the X server is running on the server's side or not.
Have been testing it with some lightweight apps too, but makes no difference if it's e.g. mousepad, gedit, thunderbird, always the same 2 min. delay at their start.
Also, some time ago, I had an older (more than 10 years) laptop, also with Arch installed, using LXDE, and connected via wifi to this same router, which worked perfectly without any delay. Also the same time ago, I was yet running Ubuntu on the home desktop, when I installed Arch to the virtualbox mentioned in point 2, and the problem was already present on the virtual pc, but not on the Ubuntu or the older laptop with Arch I had before.
Later, when I switched home desktop to Arch (or I got new laptop in the work), the issue appeared instantly on the new Arch installations.
The sshd configuration is the basic from the package, with X forwarding enabled of course, thus no strange changes of mine.
I monitored the ssh communications with tcpdump, not to read the encrypted data itself , but to see whether the data is flowing, and there are flow outages (absolute quiet except of below mentioned exceptions) in the mentioned 2 minutes duration till app. startup:
- after ssh authentication, there is about 1 minute silence, when after this 1st minute some few data is flowing
- next, there is another 1 minute silence, after which the app. finally starts
I've also gathered ssh debugging informations, from both, server (where I'm connecting and trying to start app. remotely) and client, with description when waiting has been detected.
server:
/usr/sbin/sshd -ddd
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 501
debug2: parse_server_config: config /etc/ssh/sshd_config len 501
debug3: /etc/ssh/sshd_config:15 setting ListenAddress 0.0.0.0
debug3: /etc/ssh/sshd_config:16 setting ListenAddress ::
debug3: /etc/ssh/sshd_config:35 setting LogLevel INFO
debug3: /etc/ssh/sshd_config:42 setting PermitRootLogin no
debug3: /etc/ssh/sshd_config:52 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: /etc/ssh/sshd_config:68 setting PermitEmptyPasswords no
debug3: /etc/ssh/sshd_config:71 setting ChallengeResponseAuthentication no
debug3: /etc/ssh/sshd_config:92 setting UsePAM yes
debug3: /etc/ssh/sshd_config:94 setting AllowAgentForwarding yes
debug3: /etc/ssh/sshd_config:95 setting AllowTcpForwarding yes
debug3: /etc/ssh/sshd_config:97 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:98 setting X11DisplayOffset 10
debug3: /etc/ssh/sshd_config:99 setting X11UseLocalhost yes
debug3: /etc/ssh/sshd_config:104 setting UsePrivilegeSeparation sandbox
debug3: /etc/ssh/sshd_config:106 setting Compression delayed
debug3: /etc/ssh/sshd_config:109 setting UseDNS no
debug3: /etc/ssh/sshd_config:120 setting Subsystem sftp /usr/lib/ssh/sftp-server
debug1: sshd version OpenSSH_6.1p1
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug3: oom_adjust_setup
Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 3 IPV6_V6ONLY
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 501
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from CLIENT_IP port 43333
debug1: Client protocol version 2.0; client software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 6379
debug3: preauth child monitor started
debug3: privsep user:group 99:99 [preauth]
debug1: permanently_set_uid: 99/99 [preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] [preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] [preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
debug2: kex_parse_kexinit: none,[email protected] [preauth]
debug2: kex_parse_kexinit: none,[email protected] [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
debug2: kex_parse_kexinit: reserved 0 [preauth]
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss [preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] [preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] [preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
debug2: kex_parse_kexinit: none,[email protected],zlib [preauth]
debug2: kex_parse_kexinit: none,[email protected],zlib [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
debug2: kex_parse_kexinit: reserved 0 [preauth]
debug2: mac_setup: found hmac-md5 [preauth]
debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
debug2: mac_setup: found hmac-md5 [preauth]
debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug3: mm_key_sign entering [preauth]
debug3: mm_request_send entering: type 4 [preauth]
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
debug3: mm_request_receive_expect entering: type 5 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 0x13e3f80(100)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug2: kex_derive_keys [preauth]
debug2: set_newkeys: mode 1 [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug2: set_newkeys: mode 0 [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user USERNAME service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug3: mm_getpwnamallow entering [preauth]
debug3: mm_request_send entering: type 6 [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug2: parse_server_config: config reprocess config len 501
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]
debug3: mm_request_receive_expect entering: type 7 [preauth]
debug3: mm_request_receive entering [preauth]
debug2: input_userauth_request: setting up authctxt for USERNAME [preauth]
debug3: mm_start_pam entering [preauth]
debug3: mm_request_send entering: type 45 [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 45
debug1: PAM: initializing for "USERNAME"
debug1: PAM: setting PAM_RHOST to "CLIENT_IP"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: monitor_read: 45 used once, disabling now
debug3: mm_inform_authserv entering [preauth]
debug3: mm_request_send entering: type 3 [preauth]
debug2: input_userauth_request: try method none [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug1: userauth-request for user USERNAME service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug2: input_userauth_request: try method publickey [preauth]
debug1: test whether pkalg/pkblob are acceptable [preauth]
debug3: mm_key_allowed entering [preauth]
debug3: mm_request_send entering: type 20 [preauth]
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]
debug3: mm_request_receive_expect entering: type 21 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x13e1e20
debug1: temporarily_use_uid: 1000/100 (e=0/0)
debug1: trying public key file /home/USERNAME/.ssh/authorized_keys
debug1: Could not open authorized keys '/home/USERNAME/.ssh/authorized_keys': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for USERNAME from CLIENT_IP port 43333 ssh2
debug3: mm_answer_keyallowed: key 0x13e1e20 is not allowed
debug3: mm_request_send entering: type 21
debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss [preauth]
debug1: userauth-request for user USERNAME service ssh-connection method password [preauth]
debug1: attempt 2 failures 1 [preauth]
debug2: input_userauth_request: try method password [preauth]
debug3: mm_auth_password entering [preauth]
debug3: mm_request_send entering: type 10 [preauth]
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD [preauth]
debug3: mm_request_receive_expect entering: type 11 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: PAM: sshpam_passwd_conv called with 1 messages
debug1: PAM: password authentication accepted for USERNAME
debug3: mm_answer_authpassword: sending result 1
debug3: mm_request_send entering: type 11
debug3: mm_request_receive_expect entering: type 46
debug3: mm_request_receive entering
debug1: do_pam_account: called
debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success)
debug3: mm_request_send entering: type 47
Accepted password for USERNAME from CLIENT_IP port 43333 ssh2
debug3: mm_auth_password: user authenticated [preauth]
debug3: mm_do_pam_account entering [preauth]
debug3: mm_request_send entering: type 46 [preauth]
debug3: mm_request_receive_expect entering: type 47 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_do_pam_account returning 1 [preauth]
debug3: mm_send_keystate: Sending new keys: 0x13e1c40 0x13e34c0 [preauth]
debug3: mm_newkeys_to_blob: converting 0x13e1c40 [preauth]
debug3: mm_newkeys_to_blob: converting 0x13e34c0 [preauth]
debug3: mm_send_keystate: New keys have been sent [preauth]
debug3: mm_send_keystate: Sending compression state [preauth]
debug3: mm_request_send entering: type 24 [preauth]
debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: monitor_child_preauth: USERNAME has been authenticated by privileged process
debug3: mm_get_keystate: Waiting for new keys
debug3: mm_request_receive_expect entering: type 24
debug3: mm_request_receive entering
debug3: mm_newkeys_from_blob: 0x13f3b20(122)
debug2: mac_setup: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 0x13f3b20(122)
debug2: mac_setup: 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
debug3: ssh_sandbox_parent_finish: finished
debug1: PAM: establishing credentials
debug3: PAM: opening session
User child is on pid 6387
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1000/100
debug2: set_newkeys: mode 0
debug2: set_newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug2: fd 7 setting O_NONBLOCK
debug2: fd 9 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug2: session_new: allocate (allocated 0 max 10)
debug3: session_unused: session id 0 unused
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_global_request: rtype [email protected] want_reply 0
debug1: server_input_channel_req: channel 0 request x11-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug3: sock_set_v6only: set socket 10 IPV6_V6ONLY
debug2: fd 10 setting O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
debug1: channel 1: new [X11 inet listener]
debug2: fd 11 setting O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug1: channel 2: new [X11 inet listener]
debug1: server_input_channel_req: channel 0 request exec reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req exec
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: fd 14 setting O_NONBLOCK
debug2: fd 13 setting O_NONBLOCK
debug2: fd 16 setting O_NONBLOCK
debug2: channel 0: read 210 from efd 16
debug2: channel 0: rwin 2097152 elen 210 euse 1
debug2: channel 0: sent ext data 210
debug2: channel 0: read 380 from efd 16
debug2: channel 0: rwin 2096942 elen 380 euse 1
debug2: channel 0: sent ext data 380
debug2: channel 0: read 121 from efd 16
debug2: channel 0: rwin 2096562 elen 121 euse 1
debug2: channel 0: sent ext data 121
### Here started the waiting on the server's side, and continued later till the start of app.:
debug1: X11 connection requested.
debug2: fd 12 setting TCP_NODELAY
debug2: fd 12 setting O_NONBLOCK
debug3: fd 12 is O_NONBLOCK
debug1: channel 3: new [X11 connection from 127.0.0.1 port 46968]
debug2: channel 3: open confirm rwindow 2097152 rmax 16384
debug2: channel 0: read 62 from efd 16
debug2: channel 0: rwin 2096441 elen 62 euse 1
debug2: channel 0: sent ext data 62
debug1: X11 connection requested.
debug2: fd 15 setting TCP_NODELAY
debug2: fd 15 setting O_NONBLOCK
debug3: fd 15 is O_NONBLOCK
debug1: channel 4: new [X11 connection from 127.0.0.1 port 46972]
debug2: channel 4: open confirm rwindow 2097152 rmax 16384
debug2: channel 3: rcvd adjust 51268
debug2: channel 3: rcvd adjust 65536
debug2: channel 3: rcvd adjust 65536
debug2: channel 3: rcvd adjust 65536
debug2: channel 3: rcvd adjust 65536
debug2: channel 3: rcvd adjust 32768
debug2: channel 3: rcvd adjust 147456
debug2: channel 3: rcvd adjust 55788
debug2: channel 3: window 32740 sent adjust 32796
client:
ssh -Xvvv USERNAME@SERVER_IP mousepad
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to SERVER_IP [SERVER_IP] port 22.
debug1: Connection established.
debug1: identity file /home/USERNAME/.ssh/id_rsa type -1
debug1: identity file /home/USERNAME/.ssh/id_rsa-cert type -1
debug1: identity file /home/USERNAME/.ssh/id_dsa type 2
debug1: identity file /home/USERNAME/.ssh/id_dsa-cert type -1
debug1: identity file /home/USERNAME/.ssh/id_ecdsa type -1
debug1: identity file /home/USERNAME/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "SERVER_IP" from file "/home/USERNAME/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/USERNAME/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ABC123...
debug3: load_hostkeys: loading entries for host "SERVER_IP" from file "/home/USERNAME/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/USERNAME/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'SERVER_IP' is known and matches the ECDSA host key.
debug1: Found key in /home/USERNAME/.ssh/known_hosts:4
debug1: ssh_ecdsa_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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/USERNAME/.ssh/id_rsa ((nil))
debug2: key: /home/USERNAME/.ssh/id_dsa (0x)
debug2: key: /home/USERNAME/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/USERNAME/.ssh/id_rsa
debug3: no such identity: /home/USERNAME/.ssh/id_rsa
debug1: Offering DSA public key: /home/USERNAME/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/USERNAME/.ssh/id_ecdsa
debug3: no such identity: /home/USERNAME/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
USERNAME@SERVER_IP's password:
debug3: packet_send2: adding 48 (len 68 padlen 12 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to SERVER_IP ([SERVER_IP]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-mHE6faU7YJF2/xauthfile generate :0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-mHE6faU7YJF2/xauthfile list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug1: Sending command: mousepad
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: X11 forwarding request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
### After successful authentication, here above started the first waiting, where after first 1 min. continued with:
debug2: channel 0: rcvd ext data 210
debug2: channel 0: rcvd ext data 380
debug2: channel 0: rcvd ext data 121
debug3: Copy environment: XDG_SESSION_COOKIE=0d937ee20c7e42bdbf828421a30eaa2f-1357144247.348263-1841400888
debug3: Copy environment: XDG_SESSION_ID=5
debug3: Copy environment: XDG_RUNTIME_DIR=/run/user/1000
debug2: channel 0: written 711 to efd 6
### After another 1 min. continued with + started the app.
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 46968
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 0: rcvd ext data 62
Xlib: extension "RANDR" missing on display "localhost:10.0".
debug2: channel 0: written 62 to efd 6
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 46972
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: channel 2: new [x11]
debug1: confirm x11
debug2: channel 1: window 2045884 sent adjust 51268
debug2: channel 1: window 2031616 sent adjust 65536
debug2: channel 1: window 2031616 sent adjust 65536
debug2: channel 1: window 2031616 sent adjust 65536
debug2: channel 1: window 2031616 sent adjust 65536
debug2: channel 1: window 2031616 sent adjust 32768
debug2: channel 1: window 1949696 sent adjust 147456
debug2: channel 1: window 2041364 sent adjust 55788
debug2: channel 1: rcvd adjust 32796
debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 46974
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [x11]
debug1: confirm x11
debug2: channel 1: rcvd adjust 32800
It's quite strange, as I have no more ideas what to check next.
Any ideas pls?
thx in advance.

Have finally found a solution for this problem: http://serverfault.com/questions/490352 … w-to-start
Now the applications do start immediately via SSH X11 forwarding as expected.
The following three lines helped:
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
ip6tables -A FORWARD -i lo -o lo -j ACCEPT
While until now, all ip6 traffic has been forbidden (to drop all ip6 traffic) at the start of the system of course.
Nevertheless, I don't understand it, why the ip6 localhost has to be granted this way even if the /etc/ssh/sshd_config is configured for ip4 only "AddressFamily inet"?
I thought, that this way the sshd will be using ip4 protocol only (including for the X11 forwarding), then why does it still need the ip6?

JSPM window does not appear with X11 forwarding

Hello guys,
I am using the putty with ssh-2 and X11 forwarding enabled, but the window from the JSPM does't appear or is damaged.
Is it not possible to use the JSPM with X11 forwarding? Do you have any other suggestions, like real X?
Thanks
Stefan Gutsche

I tried to access the Mixer from both the drop down menu below the right side panel and top of the interface on 8.0. Then I loaded 9.0. Same test same result first time around.
Then I read your note and tried both places again and the top of the interface worked in 9.0! Now both locations work in both versions. Weird.
Thanks very much for the response.

X11 forwarding from mac to windows laptop doesn't work

Hi,
I ssh into my mac computer from my windows laptop. However, the x11 forwarding is not working (ie, the x window is not forwarded to my laptop). I'm pretty sure this is a problem with the mac and not my laptop, because if I ssh into a unix machine the x window forwarding to my laptop works fine. Does anyone know how to get the x11 forwarding to work?
thanks
Beth

beth23 wrote:
I'm trying to forward the windows from xemacs and gnuplot.
What happens when you try to run them? Do you get any kind of error message? Have you tried just xterm?
Is it possible you have DISPLAY set to something on the Mac side?
Currently I am using putty to connect to the mac via ssh (and have the enable X windows forwarding box checked), and I have Xming running on my laptop to display the x windows. This setup works fine for connecting to unix machines, but it doesn't work for connecting to the mac.
Does the Mac have the firewall turned on?

Bug between JRockit and X11 forwarding via ssh

I have encountered what appears to be a bug in the interaction of JRockit with X11 ssh forwarding.
When running any Java GUI application on a remote machine using X11 forwarding via ssh, a variety of problems occur. For example:
--- cut here ---
% mitrion-ide
The program '' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
(Details: serial 189 error_code 5 request_code 20 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
--- cut here ---That's the good case. When running the rmmlite application (available at https://rmml.dev.java.net/servlets/ProjectDocumentList?folderID=437&expandFolder=437&folderID=438 ), I experience what appears to be a near-lockup of my local workstation.
Neither of these problems occur if I set my DISPLAY to not use ssh X11 forwarding. Likewise, non-Java applications work just fine with ssh X11 forwarding. Therefore the problem seems to be limited to the Java + ssh X11 forwarding combination.
I have a suitable workaround (i.e. setting the DISPLAY variable to avoid ssh X11 forwarding), but I thought this was worth bringing to BEA's attention. I'd also be curious to know if others have run into similar difficulties.
Here are the configuration details:
Remote X11 client (where applications are hosted)
=================================================
% java -version
java version "1.4.2_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
BEA JRockit(R) (build R27.1.0-109-73164-1.4.2_12-20061129-1418-linux-ia32, compiled mode)
% uname -a
Linux earthling 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 athlon i386 GNU/Linux
% rpm -qa | grep openssh-server
openssh-server-3.9p1-8.RHEL4.12
This is a vanilla RedHat Linux RHEL 4 Update 3 system, with all other versions of Java removed.
Local workstation (i.e. X11 server)
===================================
% uname -a
FreeBSD somewhere.sgi.com 6.2-RELEASE FreeBSD 6.2-RELEASE #5: Mon Jan 15 08:41:01 CST 2007 [email protected]:/usr/obj/usr/src/sys/somewhere i386
% ssh -v
OpenSSH_4.5p1 FreeBSD-20061110, OpenSSL 0.9.7e-p1 25 Oct 2004
% pkg_info -Ix xorg-server
xorg-server-6.9.0_3 X.Org X server and related programs
Thank you,
Brent Casavant

Brent,
it would be nice to know if this problem is specific to the JRockit JDK or
if you also can reproduce it using the corresponding Sun JDK 1.4.2. Please
do also try with a later version such as latest JRockit JDK 5.0.
Thanks
/Robert
<Brent Casavant> wrote in message news:[email protected]...
I have encountered what appears to be a bug in the interaction of JRockit
with X11 ssh forwarding.
When running any Java GUI application on a remote machine using X11
forwarding via ssh, a variety of problems occur. For example:
--- cut here ---
% mitrion-ide
The program '' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
(Details: serial 189 error_code 5 request_code 20 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
--- cut here ---That's the good case. When running the rmmlite application (available at
https://rmml.dev.java.net/servlets/ProjectDocumentList?folderID=437&expandFolder=437&folderID=438 )
, I experience what appears to be a near-lockup of my local workstation.
Neither of these problems occur if I set my DISPLAY to not use ssh X11
forwarding. Likewise, non-Java applications work just fine with ssh X11
forwarding. Therefore the problem seems to be limited to the Java + ssh X11
forwarding combination.
I have a suitable workaround (i.e. setting the DISPLAY variable to avoid ssh
X11 forwarding), but I thought this was worth bringing to BEA's attention.
I'd also be curious to know if others have run into similar difficulties.
Here are the configuration details:
Remote X11 client (where applications are hosted)
=================================================
% java -version
java version "1.4.2_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
BEA JRockit(R) (build R27.1.0-109-73164-1.4.2_12-20061129-1418-linux-ia32,
compiled mode)
% uname -a
Linux earthling 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686
athlon i386 GNU/Linux
% rpm -qa | grep openssh-server
openssh-server-3.9p1-8.RHEL4.12
This is a vanilla RedHat Linux RHEL 4 Update 3 system, with all other
versions of Java removed.
Local workstation (i.e. X11 server)
===================================
% uname -a
FreeBSD somewhere.sgi.com 6.2-RELEASE FreeBSD 6.2-RELEASE #5: Mon Jan 15
08:41:01 CST 2007
[email protected]:/usr/obj/usr/src/sys/somewhere i386
% ssh -v
OpenSSH_4.5p1 FreeBSD-20061110, OpenSSL 0.9.7e-p1 25 Oct 2004
% pkg_info -Ix xorg-server
xorg-server-6.9.0_3 X.Org X server and related programs
Thank you,
Brent Casavant

Warning: untrusted X11 forwarding setup failed: xauth key data not generate

Upon connecting to a RedHat Enterprise Linux server via ssh -X I get the following:
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
I have previously (as in last week, ending 11/1/2008) been able to use x11 forwarding from the machine I'm trying to connect to. This problem also occurs with other servers, meaning it must be a problem with my local machine. Any suggestions are welcome.

I get that if I use
ssh -Y ...
but NOT with -X.
Do you have a $HOME/.ssh/config or /etc/ssh_config file that is specifying ForwardX11Trusted?
Mostly I ignore the message when I get it as, my X11 forwarding works OK, AND I'm in an environment where my fellow employees could do much naster things to me (and get fired for it), than spoofing my X11 sessions.

X11 Forwarding to my 10.4.3 Desktop Doesn't work

It seems to be that I can forward an X11 session to my 10.4.3 machine from a Linux or SGI machine using the -Y flag, but forwarding from 10.4.x Mac to 10.4.3 Mac, this does not work. Neither does -X or no flag at all. Forwarding to a 10.4.2 machine from a Mac DOES work (no flag, -X, AND -Y). ARGH!! X11 Forwarding used to be so simple!

hi Chris.
One thing I've noticed fairly recently is that in order for forwarding to work, the shell you are issuing the ssh -Y [email protected] from must first have the DISPLAY variable set to (say) .0. In other words, in a Terminal.app window, this works:
export DISPLAY='.0'
ssh -Y [email protected]
and this doesn't:
export DISPLAY=""
ssh -Y [email protected]
Of course, both machines have to be given permissions to allow x-forwarding in /etc/ssh_config and /etc/hostconfigure.
It works for me with every combination of SGI, Linux, Mac and Sun I can think of.
G5 2x2.5 GHZ and a few others Mac OS X (10.4.3)

[SOLVED] x11 forwarding no keyboard and more

When I ssh into a server using X11 forwarding and run Kwrite, everything works fine. Kwrite opens normally and I can write in it. However, when I run Matlab, the Matlab IDE opens (apparently as normal), but I can't type in it. I can minimize, maximize, and resize the IDE window as well as select things with the mouse, but I can't type in it. Everything I type shows up in the terminal window. What is more strange is when I have the Xfce Compositor turned on and inactive window transparency enabled, the Matlab IDE opens in an inactive (transparent) window.
I've searched around for the cause of this issue, but I'm stuck. The inactive window and text going to the terminal seem to be a hint to the problem, but I don't know where to look to track it down.
Any suggestions? Ideas?
Thanks in advance!
- tlawren
Last edited by tlawren (2012-03-02 19:18:35)

Problem has been resolved. ssh'ing with the -Y instead of the -X option fixed the issue.
Research into the difference between the two options is in store!

X11 forwarding doesn't work

Hi
I bought a Macbook Pro a few weeks ago with SL preinstalled and I need to access a SSH server with X11 forwarding but I can't get it to work. Whenever I run "ssh username@host -X" it allows me to enter the password but then it just hangs.
Any ideas what might be wrong?
// Andreas

luuse wrote:
Sorry, was a bit short earlier. Was in a bit of a hurry but wanted you and anyone else to know that it didn't work. I'm not a complete beginner with unix although troubleshooting X11 on my own is kinda daunting, thereby the lack of details .
I wasn't saying anything about you. I was just ranting about 10.6. And to make things even more embarrassing, I was completely wrong! I didn't check my facts enough and was all too ready to blame 10.6.
What kind of machine are you connecting to? On MacOS X, X11 forwarding is turned off on the server side by default. You have to turn it on manually: http://developer.apple.com/mac/library/qa/qa2004/qa1383.html
I did this and I could ssh -X from my 10.6.1 machine into my production 10.5.8 machine. I hadn't bothered to check logging into my Linux server or I would have had a better answer to begin with.
It sounds like your problem has nothing to do with my little rant. Try running "ssh -X -v -v username@host" to see if there are any descriptive error messages.

X11 forwarding stops working

I'm not sure if this is a client or server side problem, but when I ssh (with -X) into a remote host (running debian) X11 forwarding initially works, but after some time (15 minutes?) it stops. Then I get errors like, e.g., "gv: Unable to open the display."
I never used to have this problem, so something must have changed somewhere. Anyone else experienced something similar?
Thanks!

I've been using X11 from my iMac since just before Christmas '09 talking to RedHat EL4, EL5, as well as Solaris and AIX systems.
However, I use -Y instead of -X, otherwise I've had X-Windows up for weeks on end without any problems.

Supdate caused X11 forwarding apps to Flash (ATY Radeon X1600)

Launching an app with X11 forwarding on any MacBookPro with ATY Radeon X1600 results in the app Flashing. View<stereo can get it to stop flashing mostly except the edges, but then it is stuck in stereo mode and moving images then results in ghosting.
Was not a problem until 10.5.7 update? I'm guessing that is about the time frame. Began about 4 months ago.
Not a problem with newer Macbooks on site or desktop macs (Did not check iMacs)

Nope. Minecraft seems to run fine, albeit quite slowly:
https://dl.dropbox.com/u/7122698/bbs_ar … pyface.png
Cinnamon screenshot: https://dl.dropbox.com/u/7122698/bbs_ar … adface.png
The rendering errors at the bottom border of the "Cinnamon Settings" window and the white boxes between the chromium tabs. These are more or less permanent, they stay there until the window is destroyed, and reappear quickly after the window is first rendered. The white noise looking things on the chromium window stay there until the window repaints itself. Moving the chromium window causes the white noise to start flickering.
The screen froze when I opened a nautilus window and tried to resize it. Xorg.0.log doesn't mention any errors.
This doesn't happen in Cinnamon 2D, so I assume it has something to do with the OpenGL implementation.
Forcing 7600M by adding
BusID "PCI:1:0:0"
to
/etc/X11/xorg.conf.d/20-radeon.cfg
causes Xorg to not even start.
I'm thinking that I've managed to improperly configure the drivers, although I don't see how.
Screenshot from aur/doomsday running doom shareware: https://dl.dropbox.com/u/7122698/bbs_ar … s_good.png
The .wad (data file containing all the game's assets) isn't corrupted. The engine itself might be, as the sprites are always corrupted in the same way. Note the barrel on the right side that has parts of a lower resolution version of itself (mipmapping) and blue armour, the light thingy in the middle that contains a lower resolution of itself and a shotgun ammo, and the pillar in the other room that is just not nice to look at. Moving away or towards the sprite (which effectively changes the mipmap level rendered) might make the sprite look as it is supposed to be.

X11 forwarding very slow

I'm trying to display images remotely (if there are any IRAF users out there, I'm using IRAF to display images in DS9) by X11 forwarding. If I use any other Linux system, the display is fine, but when I use X11 forwarding in OS X, the images load so slowly. My connection isn't the problem, so I'm wondering if there's something in OS X?

What kind of network(s) are you dealing with astronoman?
Give us a detailed description.
Also, do you use Macs only or are there other *nix machines on your network as well?
Where does the XSrever run from (networked or from each machine)?
X11 forwarding requires decent bandwidth + decent cpu/xserver resources
Macs running 9.x, Macs running 10.4.x, SGI workstations running Irix 6.5.x

"X11 forward" feature of ssh

I wanted to use the "X11 forward" feature of ssh so that if I run any GUI tool on the remote server, it will automatically be relinked to my local desktop. So, from the DB server ssh, I gave the command but it seems that it is giving problems as below.
[oracle@jispdb oracle]$ ssh -X oracle@jispdb
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
The RSA host key for jispdb has changed,
and the key for the according IP address 10.10.10.26
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
f9:81:fc:f5:bc:ab:29:19:11:72:62:f3:68:67:e6:a9.
Please contact your system administrator.
Add correct host key in /home/oracle/.ssh/known_hosts to get rid of this message.
Offending key in /home/oracle/.ssh/known_hosts:3
RSA host key for jispdb has changed and you have requested strict checking.
Host key verification failed.
[oracle@jispdb oracle]$
The hostname of the DB server is 'jispdb' as given in the example below and there is a oracle user in the linux OS installed in this server.
I hope, my question is clear.
Please, help in solving the doubt.
regards

I agree with DBA in Scotland.
If you're ssh'ing from one server to another, probably within the same corporate network behind one or more firewalls, then the most likely cause is that the server you're ssh'ing to has changed IP addresses or new hardware with a new IP was installed in place of older hardware for a host (happens often here), or just some network reorganizing, etc.
Just delete the old key from ~/.ssh/known_hosts (i believe its line 3 of the known_hosts file in your example) or you can even create a new key/entry by ssh'ing to either the IP address of the server or ssh using the FQDN for the host you're ssh'ing to.

VISA troubleshooting with puTTY

I am attempting to talk to a device through USB but it acts as a COM port/ serial connection through a driver.
I am writing commands to the device, and the the bytes in port vi shows that bytes are being written to the device, yet the device does not respond at all.
I can easily operate the device through putty though. I know the device works as I have confirmed it through an oscilloscope. What else should I troubleshoot? Or, are there other easier ways to write/read to a serial port other than VISA
I've attached a standard writing VI I have also tried with no luck. Should I try to continue to use VISA, or can I emulate puTTY on labVIEW?
Solved!
Go to Solution.
Attachments:
basic_serial_write_and_read.vi ‏23 KB
Write_test2vi.jpg ‏198 KB

What termination characters are you using with putty? CR, LF, both? You have to send the same with VISA.
I'm not sure why you would attach an example that comes with LabVIEW. If you would read any of the hundreds of posts on this subject, you would know the example's string control is set for '\' Codes Display. Use \r and \n as needed.

X11 forwarding with putty

Similar Messages

Maybe you are looking for