public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	Overseers mailing list <overseers@sourceware.org>,
	gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: sign_and_send_pubkey: signing failed: agent refused operation
Date: Mon, 1 Jun 2020 13:46:53 -0600	[thread overview]
Message-ID: <fb03dcec-95d8-eda4-729f-3743db896a93@gmail.com> (raw)
In-Reply-To: <CAH6eHdSkkP1JjL+4JfRzZmkKyY4OaJro-CmjrCmA6+CgUcW4TQ@mail.gmail.com>

On 6/1/20 1:25 PM, Jonathan Wakely wrote:
> On Mon, 1 Jun 2020 at 20:16, Martin Sebor via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> On 6/1/20 12:10 PM, Frank Ch. Eigler wrote:
>>> Hi -
>>>
>>>> git pull from the GCC and Glibc repos is failing for me with the error
>>>> below.  It worked fine last week and I haven't made any changes to my
>>>> ssh keys.
>>>
>>> And are you logging in from the same workstation with access to the same
>>> set of ssh private keys?
>>
>> Yes.
>>
>>>
>>>> Is this a transient glitch or has something changed recently that I
>>>> need to make some adjustments for?
>>>
>>> I know of nothing relevant that has changed on the sourceware side.
>>>
>>>> sign_and_send_pubkey: signing failed: agent refused operation
>>>> msebor@gcc.gnu.org: Permission denied (publickey).
>>>> fatal: Could not read from remote repository.
>>>
>>> The usual advice is to run       % ssh -vv gcc.gnu.org alive
>>> and report the ssh level error.
>>>
>>> "agent refused operation" sounds like a problem on the client end.
>>
>> Until last week, when I ran git pull from the GCC or Glibc repo
>> I'd get prompted for my password.  I'd either type it in or hit
>> ctrl-C, enter ssh-add, and start over.
>>
>> After deleting ~/.ssh/known_hosts to resolve the problem I asked
>> about last week (Re: ssh key conflicts), I'm no longer prompted
>> for my password.  Instead, I get the error above.
> 
> Is ~/.ssh/known_hosts no longer present? Is ~/.ssh writable by your
> user? The ssh client (or the agent) will try to create
> ~/.ssh/known_hosts if it doesn't exist, to add the host key. If ~/.ssh
> is not writable that will fail.

~/.ssh/known_hosts exists and ~/.ssh is rwx only by the owner.
Everything works fine if I add my key by running ssh-add.  What's
not so great is the errors I get when I forget to do that: "agent
refused operation?"

> 
>> Both of this is new (I think since the recent server changes).  Now
> 
> The host key did change after the server upgrade, that's expected. The
> other problem is not caused by the server.
> 
>> that I've seen it and know what to expect I can adjust to it but it
>> seems like things have gotten worse.  Certainly the errors I got
>> in both instances (i.e., last week as well as today) are not helpful.
> 
> SSH errors usually aren't.
> 
>> I captured the ssh -vv gcc.gnu.org output below for a successful
>> invocation and a failed one if that sheds more light on why it's
>> failing in (to me) a mysterious way.
> 
> The failed attempt shows that your public key is offered to the
> server, and the server says it will accept it (meaning it matches a
> ~/.ssh/authorized_keys entry on the server) but then your client
> refuses to use that key.
> 
> Check your ~/.ssh and ~/.ssh/id_rsa* permissions.

They're all rw by the owner only.  Nothing has changed on my end
(except that I removed/recreated ~/.ssh/known_hosts to avoid some
mysterious problems last week).

I have it working now so I don't want to use up too much of anyone
else's time trying to debug things.  It just feels like too much
of a coincidence that I started having these problems only after
the recent server upgrade.  If something jumps out at someone as
a problem or missing setting on the server end, tweaking that to
improve things going forward that would be great.  Otherwise,
let's just chalk it up to the usual joys of upgrading to "new
and improved" versions of software.

Martin

  reply	other threads:[~2020-06-01 19:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-01 17:43 Martin Sebor
2020-06-01 18:10 ` Frank Ch. Eigler
2020-06-01 19:12   ` Jonathan Wakely
2020-06-02 20:26     ` Martin Sebor
2020-06-02 20:43       ` Jonathan Wakely
2020-06-02 21:52         ` Martin Sebor
2020-06-01 19:14   ` Martin Sebor
2020-06-01 19:25     ` Jonathan Wakely
2020-06-01 19:46       ` Martin Sebor [this message]
2020-06-01 19:53         ` Frank Ch. Eigler
2020-06-01 22:33           ` Martin Sebor
2020-06-02 20:00             ` Jim Wilson
2020-06-01 22:30         ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fb03dcec-95d8-eda4-729f-3743db896a93@gmail.com \
    --to=msebor@gmail.com \
    --cc=fche@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=overseers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).