Re: Cannot export SSH public key

2023-11-22 Thread Stephan Verbücheln via Gnupg-users
Another convenient way is to use “~/.config/ssh”. This allows different
configurations per host without changing your global environment.

Example:

Host gitlab.com
HostName gitlab.com
User git
IdentityAgent ${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh

Regards
Stephan


signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Cannot export SSH public key

2023-11-22 Thread Felix E. Klee
On Wed, Nov 22, 2023 at 8:57 PM Werner Koch  wrote:
> Here is the snippet from by ~/.bashrc

I have a similar config. Thank you for the detailed explanation!

Only the following line does not work right after autologin (default
with Ubuntu / WSL2), seems like something is not ready yet.

gpg-connect-agent updatestartuptty /bye

> What is in your ~/.gnupg/sshcontrol file?

It’s empty, with only comments at the top. I left it that way, and
proceeded as follows:

> Instead of putting this into sshcontrol you may also put them into the
> private-keys-v1.d/.key file with a line:
>
>   Use-for-ssh: yes

I added that to 0E67508AC6866D82ABB95E0B53CF5D18DC48A786.key, which is
my master key.  But it still doesn’t work, see below.

Should I add a file with the authentication key instead?

>   gpg --export-ssh-key
>
> Adds a comment with the keyid - is that one correct?  Does it match what
> you see with
>
>   ssh-add -L

Output:

$ gpg -k --with-keygrip yubi...@f76.eu
pub   rsa4096 2023-06-29 [SC]
  7A0FE73DDB744F0F97341DA71BE349D11B6ED589
  Keygrip = 0E67508AC6866D82ABB95E0B53CF5D18DC48A786
uid   [ultimate] Felix E. Klee (YubiKey) 
sub   rsa4096 2023-06-29 [E]
  Keygrip = 07D6164F019D2EDF59C650992CF93776B2DD17F2
sub   rsa4096 2023-11-22 [A]
  Keygrip = 9C67E5BBB72EF0BF2625792F8F134CE4FD961FF5
$ gpg --export-ssh-key yubi...@f76.eu
ssh-rsa B3NzaC1yc2EDAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF
rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ
vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe
o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2
Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP
XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh
H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK
ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB
KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4
ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv
FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== openpgp:0x877CC64B
$ ssh-add -L
ssh-rsa B3NzaC1yc2EDAQABAAACAQCpsX4nQnLh3SJDdIDkdX0DFY4c2uFu
6QJRPrXyub32Ae5SX+3rQnhj/7U8PGFG5LbRT8NVHMyxmoXAHda3wZ1Za3mTC8oWUPSz
dIlSgB7HrVNvmP0fvk0b1V9BOkBJrV6RMMNLEssiD9PCiI95z1+uEbxr9tZAJO/lDYnU
jhEK6PykBhQiJISHpWnWmE0qj+84wQ+/cEPJYnt4tgqLuFH+COFGBVuN6DDi6ubbDlCy
693UqQjWSNi1A34JmUKFOw5Kt0It3Qj3nNVdm8/hRiVZ84qPVbF1Vvp0gZ9k1sFg+3O9
LZYo0vZ73gLMx6AjO1A+Cqcef/e6O+aT+CVgINQ6oaDMyKtHkD7caflg8nPrmiVASxTe
nn51W3Uiu1wksrtEH2HCUcLXpMWKNTjjwpUUTSmMy4m069K5SENsjzsMsHiN2cTxdNu5
CufP1Q3XtGI4VCdW5ql0vgZMCPHIuXHLyFpz9scc2I68B8YnoMzzH0CDyLpjudBRlup+
BZD1g2xlCWB9f+43Oy+Ibf5wAW8/gjk5ly6fhQwB712GTHXNKpPl2ymXgtP2v0K48TE7
OsIfR0sBk2LbwuXr2tLB1WYgrNYs8YY83u/HC6RWHskrcIRq75ahcdeTu8Ukdz1VhAdL
sk25F529lMjW0CgshB9xvFxCwFzcGMmHniuMjoFN6Q== cardno:18 698 015
$ ssh-add -l
4096 SHA256:Pun8mwtl04HFOK8Z1LbCRZ/oQLgZDpkgNHU5/E1MM8I cardno:18 69
8 015 (RSA)

As you see, the public keys are different. `ssh-add -L` does not add the
key ID. So I’ve no idea what is going on.

The key exported by `ssh-add -L` works. I get asked for the PIN, the
Yubikey blinks, and then I’m in:

$ ssh u...@example.com
[user@example ~]$

The key exported by `gpg --export-ssh-key yubi...@f76.eu` does not work:

$ ssh u...@example.com
u...@example.com: Permission denied (publickey).

As it works with the key exported with `ssh-add -L`, maybe I should not
complain. However what confuses me is that the output of `ssh-add -L`
does not change after I replaced the authentication subkey.

Can you explain why the output of `ssh-add -L` did not change? Also why
is it not the same as the output from `gpg --export-ssh-key
yubi...@f76.eu`?

(Background: I replaced the authentication subkey because the first time
I added it, I forgot to make a backup of the updated secret key.)

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Cannot export SSH public key

2023-11-22 Thread Felix E. Klee via Gnupg-users
On Tue, Nov 21, 2023 at 12:38 AM Ingo Klöcker  wrote:
> $ gpg --export-ssh-key 1B6ED589

Thanks, this worked! I then added the key on the remote system to:

~/.ssh/authorized_keys

However, I could not log in.  SSH reports:

Permission denied (publickey).

I then tried exporting the key using `ssh-add`:

ssh-add -L >~/.ssh/id_rsa.pub

If I add this key to `authorized_keys`, I can log in, after unlocking my
Yubikey with a PIN. Great! Or not, read on.

Now it gets a bit weird: Apparently the key exported by `ssh-add` is not
tied to my authentication key! I noticed this because I replaced the
authentication key. They key exported by `ssh-add` did not change. I can
still log in using that key. So I assume that key is based on the my
signature key `1B6ED589`:

$ gpg --list-keys --keyid-format SHORT yubi...@f76.eu
pub   rsa4096/1B6ED589 2023-06-29 [SC]
  7A0FE73DDB744F0F97341DA71BE349D11B6ED589
uid [ultimate] Felix E. Klee (YubiKey) 
sub   rsa4096/D2E31736 2023-06-29 [E]
sub   rsa4096/877CC64B 2023-11-22 [A]

Should I better use the authentication key exported by GPG for SSH? But
how to make that work?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Cannot export SSH public key

2023-11-22 Thread Werner Koch via Gnupg-users
On Wed, 22 Nov 2023 19:39, Felix E. Klee said:

> However, I could not log in.  SSH reports:
>
> Permission denied (publickey).

You need to make sure that the gpg-agent is running and the
SSH_AUTH_SOCK envvar is set correctly.  Here is the snippet from by
~/.bashrc

--8<---cut here---start->8---
# Setup information required by GnuPG and ssh.  We use the
# standard socket in GnuPG's homedir, thus there is no need for an
# environment variable.  We reset any left over envvar.
# SSH_AGENT_PID should not be set either because it is only used
# to kill ssh-agent (option -k) but we don't want this to kill
# gpg-agent.  Because ssh does not know about GnuPG's homedir we
# need to set its envvar to the standard gpg-agent.  GPG_TTY needs
# to be set to the current TTY.  The extra test is used to avoid
# setting SSH_AUTH_SOCK if gpg-agent has been started with a
# shell on the command line (often used for testing).
unset GPG_AGENT_INFO
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi
export GPG_TTY=$(tty)
--8<---cut here---end--->8---

In case you are switching to a different X server etc, you may need to
run

  gpg-connect-agent updatestartuptty /bye

once.  This will also make sure that the agent is launched.

Although gpg-agent by default creates the socket for the ssh-agent
protocol, some distros have a pecularity that they look into
~/.gnupg/gpg-agent.conf and check whether there is a
"enable-ssh-support" option set.  If not they don't set the envvar (as
above) or do their necessary systemd stuff to create the socket.

> I then tried exporting the key using `ssh-add`:
>
> ssh-add -L >~/.ssh/id_rsa.pub

ssh-add should have connected to gpg-agent and exported the ssh public
keys it knows.  You don't need to put this into id_rsa.pub.  I use 

> Now it gets a bit weird: Apparently the key exported by `ssh-add` is not
> tied to my authentication key! I noticed this because I replaced the
> authentication key. They key exported by `ssh-add` did not change. I can

What is in your ~/.gnupg/sshcontrol file?  It should list the keygrips
of the keys to be used for ssh.

  gpg -k --with-keygrip yubi...@f76.eu

Instead of putting this into sshcontrol you may also put them into the
private-keys-v1.d/.key file with a line:

  Use-for-ssh: yes

FWIW, you may also use

  Label: My pink token

to have a nicer prompt.

> Should I better use the authentication key exported by GPG for SSH? But
> how to make that work?

  gpg --export-ssh-key

Adds a comment with the keyid - is that one correct?  Does it match what
you see with

  ssh-add -L

(or ssh-add -l)?


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Cannot export SSH public key

2023-11-22 Thread Felix E. Klee
On Tue, Nov 21, 2023 at 12:38 AM Ingo Klöcker  wrote:
> $ gpg --export-ssh-key 1B6ED589

Thanks, this worked! I then added the key on the remote system to:

~/.ssh/authorized_keys

However, I could not log in.  SSH reports:

Permission denied (publickey).

I then tried exporting the key using `ssh-add`:

ssh-add -L >~/.ssh/id_rsa.pub

If I add this key to `authorized_keys`, I can log in, after unlocking my
Yubikey with a PIN. Great! Or not, read on.

Now it gets a bit weird: Apparently the key exported by `ssh-add` is not
tied to my authentication key! I noticed this because I replaced the
authentication key. They key exported by `ssh-add` did not change. I can
still log in using that key. So I assume that key is based on the my
signature key `1B6ED589`:

$ gpg --list-keys --keyid-format SHORT yubi...@f76.eu
pub   rsa4096/1B6ED589 2023-06-29 [SC]
  7A0FE73DDB744F0F97341DA71BE349D11B6ED589
uid [ultimate] Felix E. Klee (YubiKey) 
sub   rsa4096/D2E31736 2023-06-29 [E]
sub   rsa4096/877CC64B 2023-11-22 [A]

Should I better use the authentication key exported by GPG for SSH? But
how to make that work?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: NO_SECKEY difference between 2.2 and 2.3

2023-11-22 Thread Bernhard Reiter
Am Dienstag 21 November 2023 15:28:46 schrieb Aleksander Machniak:
> >> - v2.3 outputs two NO_SECKEY lines referring both recipient's and
> >> sender's keys.

Potentially the sender has encrypted the message for themselves, this would 
explain why there are two potential decryption keys that you both do not 
have. Try an additional -v to see more about the message structure.

Maybe v2.3 is just more informative here.


-- 
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users