After a recent update, keychain stopped working properly. I got the same error as reported in Bug #53436; I had neither x11-ssh-askpass nor gtk2-ssh-askpass installed: ssh_askpass: exec(/usr/lib/misc/ssh-askpass): No such file or directory ssh_askpass: exec(/usr/lib/misc/ssh-askpass): No such file or directory Permission denied, please try again. After emerging gtk2-ssh-askpass and restarting, the gtk2-ssh-askpass screen up immediately after logging into gdm, however I had the --nogui specified in my keychain startup (and keychain in a console would hang). I thought this was due to tha above missing symlink, however, after replacing gtk2-ssh-askpass with x11-ssh-askpass, both console and xterm shells both failed. It appears that the symlink trick does not work for non-X askpass, and keychain requires some sort of console-compatible ssh-askpass that actually works. Reproducible: Always Steps to Reproduce: 1. update udev, keychain, ssh 2. remove x11 and gtk2-ssh-askpass and watch keychain fail 3. install one of the above and still have keychain fail in a console Expected Results: keychain should work as before or have an RDEPEND on a working ssh-askpass Portage 2.0.50-r8 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.6) ================================================================= System uname: 2.6.6 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=i686 -mcpu=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=i686 -mcpu=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache cvs distcc sandbox userpriv usersandbox" GENTOO_MIRRORS="http://megatron.arnolds.bogus/gentoo/" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://megatron.arnolds.bogus/gentoo-portage" USE="3dnow X aalib acl acpi alsa apm arts avi bonobo cdr crypt cups dga directfb dvd emacs encode esd evo f77 fam fbcon flac foomaticdb freetype freetype2 gb gcj gd gdbm gif gnome gpm gtk gtk2 gtkhtml imap imlib ipv6 java jpeg junit kde lame lcms ldap libg++ libwww mad mikmod mmx motif mozilla mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pda pdflib perl plotutils png python qt quicktime readline samba sasl sdl slang slp spell sse ssl tcltk tcpd tetex tiff truetype v4l v4l2 video_cards_radeon vorbis x86 xml xml2 xmms xv zeo zlib" * net-misc/openssh Latest version available: 3.8_p1 Latest version installed: 3.8_p1 * net-misc/keychain Latest version available: 2.3.0 Latest version installed: 2.3.0 * sys-fs/udev Latest version available: 026-r1 Latest version installed: 026-r1 * net-misc/x11-ssh-askpass Latest version available: 1.2.2-r1 Latest version installed: 1.2.2-r1 * net-misc/gtk2-ssh-askpass Latest version available: 0.3 Latest version installed: [ Not Installed ]
The ask pass *looks* likes the error, I encountered the same problem with Linux From Scratch earlier, but never with Gentoo. Since I reinstalled my main PC with gentoo, sat-sun I noticed this error too (and I was searching for the bug you report it). So what IS the problem. SSH goes in the ask-pass IF-THEN-ELSE mode if he can't get a terminal. The primary reason for this to happen is that the program has no rights to do so. So what would resolve this *until* your box reboots. chmod 666 /dev/tty this is the old style permantent solution. I just found out that this has something to do with console.perms and console.apps in /dev/security. By reading the nVIDIA documentation with obviously have the same problem with /dev/nvidia* be root accesible only. I'm tried to add ssh/scp in the required directory, but SSH now gives the correct message (premission denied), nice to see but still not resolved.
update udev-026 -> udev-027 udev/permissions.d/50-udev.permissions > tty:root:tty:0666 does the trick after updating
Please re-open if you believe this is not a duplicate *** This bug has been marked as a duplicate of 53292 ***
fixed in keychain-2.3.2 ... the problem was that ssh-add attempts to call SSH_ASKPASS even when stdin is open. The solution is to unset SSK_ASKPASS prior to calling ssh-add when --nogui is specified (or DISPLAY is unset) Thanks!
Actually I think I have found the problem with this relating to udev and it has to do with /etc/udev/udev.conf, the line: default_mode="0660" should read: default_mode="0666" Did this, rebooted, and worked fine. Also googled for this and seems to be only Gentoo-related. This is on a fresh install of Gentoo, i.e.: cat /proc/version reads: Gentoo Base System version 1.4.16
Also verified on an earlier install of udev on another machine, udev.conf reads, per that line: default_mode="0666" So this must have been somtime changed, causing breakage.
Lance, that was mentioned in comment #2, thanks. There were a couple problems fixed as part of this bug
