| Summary: | sys-auth/pambase[ssh] spawns unwanted instances of ssh-agent with su / sudo | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tavin Cole <tavin.cole> |
| Component: | [OLD] Core system | Assignee: | PAM Gentoo Team (OBSOLETE) <pam-bugs+disabled> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | CC: | alexander, caster |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 490473 | ||
I'll see to work on this for the new pambase, although it gets quite messy, there is space for running this only for interactive logins… please retry with 20150213-r2 |
try this a few times: # sudo ls /tmp and watch the ssh-XXX directories pile up in /tmp. apparently each sudo invocation spawns an ssh-agent, and somehow they get left behind even though the ssh-agent process is being killed. now try something like this: # su -c 'ls /tmp' and you'll see the ssh-XXX directory created by the spawned ssh-agent, but at least it gets cleaned up properly afterwards. imho, ssh-agent should not be spawned at all in such cases. it seems to result from the pam_ssh.so session line in /etc/pam.d/system-auth, which is included by /etc/pam.d/{su,sudo}. perhaps /etc/pam.d should be cleaned up so that the pam_ssh.so session behavior is not in system-auth but is only present for primary logins e.g. from the console.