Bug 1091992 - ssh-agent passwords do not timeout properly
Summary: ssh-agent passwords do not timeout properly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Lautrbach
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-28 13:06 UTC by john.haxby@oracle.com
Modified: 2014-05-21 23:23 UTC (History)
4 users (show)

Fixed In Version: openssh-6.4p1-4.fc20
Clone Of:
Environment:
Last Closed: 2014-05-21 23:23:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Proposed patch, slightly re-worked from upstream in line with comments there. (757 bytes, patch)
2014-04-28 13:06 UTC, john.haxby@oracle.com
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
OpenSSH Project 2228 0 None None None Never

Description john.haxby@oracle.com 2014-04-28 13:06:05 UTC
Created attachment 890469 [details]
Proposed patch, slightly re-worked from upstream in line with comments there.

Description of problem:

I habitually run "ssh-add -t10h" when I open up my laptop in the morning and then suspend it at the end of the working day, usually a little while before the lifetime of the identities expires.

Recently, however, this hasn't worked because the agent still has the identities the following morning.

Version-Release number of selected component (if applicable):
   openssh-6.4p1-3.fc20


How reproducible: Every time.


Steps to Reproduce:
1. Load private key into ssh-agent with, say, ssh-agent -t1h
2. Suspend machine (eg close lid) for a little longer than the timeout
3. Wake machine, run ssh-add -L

Actual results: key(s) still reported loaded


Expected results: no keys loaded.




Additional info:


I believe that this is because monotime() uses CLOCK_MONOTONIC but in recent kernels this has changed slightly.  From clock_gettime(2):

    CLOCK_MONOTONIC
           Clock that cannot be set and  represents  monotonic  time
           since some unspecified starting point.  This clock is not
           affected by discontinuous jumps in the system time (e.g.,
           if  the system administrator manually changes the clock),
           but is affected by the incremental adjustments  performed
           by adjtime(3) and NTP.

    CLOCK_BOOTTIME (since Linux 2.6.39; Linux-specific)
           Identical to CLOCK_MONOTONIC, except it also includes any
           time  that the system is suspended.  This allows applica‐
           tions to get a suspend-aware monotonic clock without hav‐
           ing  to  deal  with  the complications of CLOCK_REALTIME,
           which may have discontinuities if  the  time  is  changed
           using settimeofday(2).

The attached patch seems to fix this: if CLOCK_MONOTONIC is available then additionally check for CLOCK_BOOTTIME.  CLOCK_BOOTTIME is Linux specific and will never be defined unless CLOCK_MONOTONIC is also defined.

Comment 1 Fedora Update System 2014-05-15 14:02:06 UTC
openssh-6.4p1-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openssh-6.4p1-4.fc20

Comment 2 Fedora Update System 2014-05-16 10:03:11 UTC
Package openssh-6.4p1-4.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-6.4p1-4.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-6380/openssh-6.4p1-4.fc20
then log in and leave karma (feedback).

Comment 3 Fedora Update System 2014-05-21 23:23:33 UTC
openssh-6.4p1-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.