I didn’t discover the method myself, but I was on the right track, which led me to this Ubuntu bug report, which contains a successful workaround:

# in ~/.profile
if [ -n "$GNOME_KEYRING_PID" ]; then
    eval $(gnome-keyring-daemon --start)
    export SSH_AUTH_SOCK
fi

The bug report goes into detail, but basically the issue seems to stem from some out of order initialization of ssh-agent, ~/.profile, and the GKD, perhaps with e17′s lack of support for xdg autostart directives.

I was able to search out the bug report after a lot of comparing the output of ps xa and export while logged in via e17 and comparing it to the same from within GNOME. The output of the latter showed two different SSH_AUTH_SOCK formats:

# gnome
SSH_AUTH_SOCK="/tmp/keyring-HvW1Yb/socket.ssh"
# e17
SSH_AUTH_SOCK="/tmp/ssh-RMKCQa4949/agent.4949"

This gave me a hunch that my SSH_AUTH_SOCK was coming from ssh-agent, rather than from GKD. A google search for the terms “pam SSH_AUTH_SOCK” then turned up the bug report above.

In comment #8 of said bug report, Mikel Ward mentions that in xfce4, it’s possible that the GKD’s SSH_AUTH_SOCK is being overwritten by an incorrectly guarded call to ssh-agent in /etc/xdg/xfce4/xinitrc. e17 doesn’t have any such initialization (of which I’m aware), so I presume that my SSH_AUTH_SOCK stems from ssh-agent being called as part of /etc/X11/Xsession.d/90x11-common_ssh-agent, though admittedly I’ve done no work to confirm this hypothesis.