On 10.01.25 18:27, Corey Hickey wrote:
On 2025-01-10 01:35, Jochen Bern wrote:Please don't. If you want to ever get people to load their privkeys into the agent *with a limited lifetime*, having a trivial, *universal* way to check whether they have expired by now is an asset.With my patch v2, that would need to be: > alias ssh='ssh-add -l | grep -q . || sshadd ; ssh'
Which admittedly would still be "trivial", but there's a reason why I stressed "universal". (I'm sort of the SSH/tunneling/crypto-parms guru here and my SSH configs/templates tend to percolate throughout the IT and support dpt.s, whatever their local OpenSSH version happens to be.)
Of course, if OpenSSH executables could output further (version-dependent) Best Current Practices on their own usage in a shell (script), like "ssh-agent -s" does ... ;-)
...though the message "The agent has no identities." would be printed to stderr, for better or for worse. Perhaps that should require a higher log_level (via -v).
(Nothing a "2>&1" or "2>/dev/null" on top couldn't fix, FWIW.)
That said, I do think the current behavior is not optimal. In a general sense, when listing something, an empty list is a valid outcome. If the listing tool returns an error status after _successfully_ determining that the list is empty, then the caller cannot easily know whether the tool succeeded or was unable to determine the list.
I can see that, but I wouldn't consider it good enough a reason on its own to break backwards compatibility ...
(FWIW, "grep" is technically not outputting a list, but a list of lists - one list of matches for every file named in the params - and offers condensing this into a plain list again, think "grep -l $USER /etc/*". I'd guess that further condensing that into a single exit status made sense in a "someone *will* find this useful" way. Which raises the question whether the currently *plain* list output by "ssh-add -l" might see subcategories in the future - say, per providers or constraints ...)
On 10.01.25 18:57, Jim Knoble wrote:
When Damien wrote:Adding a new exit status for the no-keys-in-agent case would be acceptable too I think.I interpreted that as "make ssh-add exit with status 2 or 3 or 99, for example, as opposed to 1". That is differentiate between: - There is an agent, and it has keys, and ssh-add listed them (exit status 0). - There is no agent, or there is a problem communicating with the agent (exit status 1). - There is an agent, but it has no keys (exit status 2, for example).
Agreed - with the minor caveat that IIUC higher values tend to get assigned to the *more* severe failure.
Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
