Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 270834 - net-misc/nxclient connection-error after glibc-2.10.1 upgrade
Summary: net-misc/nxclient connection-error after glibc-2.10.1 upgrade
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: NX Server Herd
Depends on:
Reported: 2009-05-22 14:44 UTC by Harris Landgarten
Modified: 2015-03-26 16:32 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Harris Landgarten 2009-05-22 14:44:24 UTC
nxclient will no longer connect to any nxserver after glibc-2.10.1 was installed. The connection fails with connection-error and shows too many authenication errors in the detail box. Manually connecting as the NX user with the default key works so the error is in nxclient itself. My adm64 workstation was having this problem after the glibc update. My 32 bit notebook was connecting before the glibc update but fails now after the update.

The server side sees the connection attempt but does not see the connection failure.

Reproducible: Always
Comment 1 Sebastian Luther (few) 2009-05-22 19:21:40 UTC
emerge --info and maybe some error messages please.
Comment 2 Harris Landgarten 2009-05-22 22:35:18 UTC
I am connecting to nxserver-freeedition-

The error detail is:
NX> 203 NXSSH running with pid: 3925
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: on port: 22
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
Received disconnect from 2: Too many authentication failures for nx

The server side logs do not show a failed login. I can see that an ssh session is attempted from the server side.

See if you can reproduce this.
Comment 3 Bernard Cafarelli gentoo-dev 2009-05-27 12:18:18 UTC
I have 64bit nxclient -> 32bit nxserver-freenx and 32bit nxclient -> 64bit nxserver-freeedition working here (all ~arch, and glibc 2.10.1).

I'll check if this problem has been reported in other systems, can you post emerge --info? both server and client, is server on glibc 2.10.1 too?
Comment 4 Harris Landgarten 2009-05-27 12:29:44 UTC
I have tried two different servers, one on 2.10.1 and one not. It does not seem to be a server issue. The client seems to give up key negotiation and fail. There is no guarantee this is a glibc issue. Another package could be at falt as glibc was installed on both client systems along with other packages.

Here is emerge --info for one the the clients:

Portage (default/linux/amd64/2008.0/desktop, gcc-4.3.3, glibc-2.10.1-r0, 2.6.29-gentoo-r5 x86_64)
System uname: Linux-2.6.29-gentoo-r5-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9550_@_2.83GHz-with-gentoo-2.0.1
Timestamp of tree: Tue, 26 May 2009 22:00:01 +0000
app-shells/bash:     4.0_p24
dev-java/java-config: 2.1.8
dev-lang/python:     2.4.4-r15, 2.5.4-r3, 2.6.2
dev-python/pycrypto: 2.0.1-r8
dev-util/cmake:      2.6.4
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.4.3-r2
sys-apps/sandbox:    1.9
sys-devel/autoconf:  2.13, 2.63-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2
sys-devel/binutils:  2.19.1-r1
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6a
virtual/os-headers:  2.6.29
ACCEPT_KEYWORDS="amd64 ~amd64"
CFLAGS="-march=core2 -O2 -msse4.1 -pipe"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=core2 -O2 -msse4.1 -pipe"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/xeffects /usr/portage/local/layman/gentoo-china /usr/portage/local/layman/vmware /usr/local/overlays"
USE="X acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde ldap libnotify mad midi mikmod mmx mp3 mpeg mudflap multilib ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype unicode usb vorbis xml xorg xulrunner xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="vesa nv fbdev nvidia"
Comment 5 Bernard Cafarelli gentoo-dev 2009-06-03 10:53:31 UTC
OK, let's try to narrow the suspects list: nxclient uses its own ssh client to connect, called nxssh. Can you try connecting as nx user with nxssh instead of ssh?
The syntax is identical, so something like "nxssh -v -i nx.key nx@server" will do the trick
Comment 6 Harris Landgarten 2009-06-03 11:25:44 UTC
Lots more info. It seems that either ssh or nxssh can connect with the nxkey but only if there are no other keys in the ssh agent cache. If the agent is populated by keys with ssh-add then the following happens:

ssh -v -i nxkey
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /home/user/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file nxkey type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '' is known and matches the RSA host key.
debug1: Found key in /home/harrisl/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: userkey1
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: userkey2
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: id_dsa.1
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: userkey3
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: id_dsa.2
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: userkey4
Received disconnect from 2: Too many authentication failures for nx

if ssh-add -D is run then nx connects with no problem.

I had the same results with nxssh but it gave no debug output.

What could have changed that would cause this behaviour
Comment 7 Harris Landgarten 2009-06-03 11:37:50 UTC
I can see what is happening. If no other keys are in the agent cache then nxssh connects using the key on the command line. If other keys are in the cache, then nxssh tries all of those keys before trying the one on the command line and if there are too many in the cache it never gets to the one specified on the command line. This appears to be a bug in ssh and not in nxclient at all. ssh is trying keys in the wrong order when the key is specified on the command line.
Comment 8 Bernard Cafarelli gentoo-dev 2009-06-03 13:42:24 UTC
Did this setup work before (with the same number of keys loaded in the agent)? It seems unlikely a glibc update would trigger this behavior in openssh. Maybe you updated openssh in the same batch and sshd config (or defaults) got updated?

Also cc-ing base-system (openssh maintainers) for advice, I did not find an existing bugreport on this (see comment #7)
Comment 9 Harris Landgarten 2009-06-03 14:07:47 UTC
I have about 9 or 10 keys in my .ssh and gnome-keyring picks them all up so they were all there when it worked. This seems like a more general bug,
Comment 10 Harris Landgarten 2009-06-03 18:33:14 UTC
I did some more testing. I tried the following with an ssh-agent cache full of keys. ssh -v -i nxkey
OS                                 ssh-version        result
gentoo ~x86 gnome 2.26             5.2_p1-r2          fails to connect
gentoo ~amd64 gnome 2.26           5.2_p1-r2          fails to connect
gentoo x86 gnome 2.24              5.2_p1-r1          fails to connect
gentoo x86 no x                    4.7_p1-r3          connects
ubuntu 9.04 gnome 2.26             5.1p1-5ubuntu1     fails to connect

In all cases all the keys in the cache were tried first. Openssh-4.7_p1-r3 tried the key on the command line after and succeeded while all the others errors out without trying the key on the command line.
Comment 11 Harris Landgarten 2009-06-03 20:14:53 UTC
more testing shows that the error happens after 4 keys are added to the cache. It doesn't matter whether the keys are added with ssh-add or via agent forwarding.

We can eliminate glibc as a possible cause now. This is probably an ssh bug or possible causes by a dependency.
Comment 12 Harris Landgarten 2009-06-04 21:51:50 UTC
If someone can verify my findings we should rename this bug to something referencing ssh
Comment 13 Bernard Cafarelli gentoo-dev 2015-03-26 16:32:41 UTC
Last rites in progress in bug #537774