"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.

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?

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

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?

X11 session tunnelling via SSH: no longer working!

Hi!
Graphical access to a Solaris 9 or 10 server via X11 tunneled thru an SSH session used to work fine until recently. In other worlds, you would connect with a
ssh -X [email protected] your workstation running an appropriate X11 server, the remote SSHD would set up the DISPLAY variable pointing back to itself and everything would work as expected. Run a graphical app, and it would happily pop up in your display.
However, recently this has stopped working on two different servers I use, one with Solaris 9 and the other with the latest Solaris 10. The ssh session works normally, but the DISPLAY variable does not get set and the following error pops up in the console:
Aug 26 13:58:46 sunserver sshd[2251]: [ID 800047 auth.error] error: Failed to allocate internet-domain X11 display socket.Both servers were patched with the latest security and recommended patches. Tried by connecting from a MacOS X 10.5 portable (using the included X11 server), a Knoppix 5.3.1 host and an OpenSolaris host, all with the same failed results. However, on an older Solaris 9 server that has not been recently patched, the tunnelling works as usual, so it seems to be a server-side problem. And, like I mentioned, this all used to work on the failing servers, before the patching orgy this summer.
Since the tunnelling no longer works, the only way to run graphical apps is by manually doing the insecure xhost +client / DISPLAY=server:0.0; export DISPLAY routine.
Has anyone run across this problem and know which patch messed things up? Is there a solution or, at least, a workaround?
TIA for your help.
J. Courcoul

There was a posted six hour service window for this web site yesterday. Your initial posting should have happened just
before the service windows opened and after the service windows expired half of the world was still asleep and then you
complain the next morning about the dearth of responses. Talk about underwhelming.Guess my anxiety due to user pressure was showing... :D HOWEVER, I did get a perfectly good response on comp.sys.sun.admin about four hours after posting, even though slashdot and others have been crowing about the death of Usenet.
Usually X forwarding breaks when there is nothing to connect back to but your messages seems to suggest that a patch
has caused the problems. For the life of me I can't figure out why adding an IPv6 loopback address would fix this but
an actually Sun employee would know better than I.Precisely why I don't want to mark the question as answered yet. Heck, when I read the trick, it made me think that I had completely misunderstood how the tunnelling mechanism works.
You might try going through the list of patches that were applied and see if any of them contain files related somehow
to SSH and then file a bug report against that patch to Sun so it can be fixed, again.Yes, cause there was an ssh/sshd patch that came out in the June/July timeframe which may have a bearing. However, I recall there was at least one or maybe two patches for tcp that may also have been a cause. Time to put on the Sherlock Holmes cap...

Can't forward X over ssh anymore

I'm not really getting any error messages, it only says "can't open display" when I try to lauch an app. Everything seems okay using -vv to get info:
debug1: Requesting X11 forwarding with authentication spoofing.
then it just logs in without any error.
I moved the ~/.Xauthority on the client machine, and then got this error - i wonder if has something to do with the .Xauthority?
Warning: No xauth data; using fake authentication data for X11 forwarding.
I can ssh into a fedora box and launch apps, but not arch. Anyone have a suggestion of where I can start looking? Xorg.log is also giving absolutely nothing.

sinister99 wrote:
slackhack wrote:
I think I got it. Add this line (or uncomment) to /etc/ssh/sshd_config, and restart the daemon:
X11UseLocalhost yes
Didn't work for me; are you connecting to another box, or are you on the same computer?
i'm on my laptop, connecting to my desktop. uncomment the line on the server box and restart the daemon, if that's not what you did.
also do echo $DISPLAY on the client (i think it should be something like :0.0), and on the server when you log in with X forwarded (should be a higher number, like :10.0).
also, make sure to run ssh with -vv flags to see if you get any error messages.

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.

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.

[Solved]Can't forward X in ssh with "X11Forwarding yes" set

Hi friends,
I can't forward X in ssh, even with "X11Forwarding yes" set. After I ssh -X into the server, it prompts every time when I try to run a graphic app:
Error: no display specified
Could you please give me a hint? My sshd_config of the server is attached:
# $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 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 change a
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require 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
# 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 yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#RSAAuthentication yes
#PubkeyAuthentication yes
#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 no
#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 no
PrintLastLog no
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/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
Thank you very much!
Last edited by Wen (2010-01-16 23:18:12)

Ashren wrote:
Have you set:
ForwardX11 yes
on the client side?
Unfortunately, yes .
This is ssh_config file
# $OpenBSD: ssh_config,v 1.21 2005/12/06 22:38:27 reyk Exp $
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
# Host *
# ForwardAgent no
ForwardX11 yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
Host *
GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
ForwardX11Trusted yes
# Send locale-related environment variables
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL

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.

X11 forwarding

I want to enable X11 forwarding on my machine can anybody help me

Im assuming you're talking about through ssh. If so, edit your sshd.config file and uncomment the X11 tunneling options. It should look something like:
# X11 tunneling options
X11Forwarding yes
X11DsiaplayOffset 10
X11UserLocalhost yes
The restart your sshd.
Hope this helps.

"X11 forward" feature of ssh

Similar Messages

Maybe you are looking for