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
emerge --info and maybe some error messages please.
I am connecting to nxserver-freeedition-3.3.0.22 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: 69.114.78.112 on port: 22 NX> 202 Authenticating user: nx NX> 208 Using auth method: publickey Received disconnect from 69.114.78.112: 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.
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?
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 2.1.6.13 (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" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -msse4.1 -pipe" CHOST="x86_64-pc-linux-gnu" 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" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="C" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j7" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" 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" SYNC="rsync://rsync.gentoo.org/gentoo-portage" 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" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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
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 nx@nxserver.com 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 nxserver.com [111.111.111.111] 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 'nxserver.com' 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_REQUEST sent 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 111.111.111.111: 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
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.
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)
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,
I did some more testing. I tried the following with an ssh-agent cache full of keys. ssh -v -i nxkey nx@nxserver.com 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.
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.
If someone can verify my findings we should rename this bug to something referencing ssh
Last rites in progress in bug #537774
