Summary: | keychain needs ssh-askpass | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Steve Arnold <nerdboy> |
Component: | Current packages | Assignee: | Aron Griffis (RETIRED) <agriffis> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Steve Arnold
2004-06-13 14:51:44 UTC
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 |