Re: apt-key says deprecated, but not saying what else to use

[Marco Möller]

On 20.06.21 17:36, Brad Rogers wrote:

On Sat, 19 Jun 2021 22:07:35 +0200
Marco Möller  wrote:

Hello Marco,


Command apt-key and its man page say that apt-key is deprecated, but do


Coincidentally, I recently got notification of a pertinent blog post by
Julian Andres Klode.  See;
https://blog.jak-linux.org/2021/06/20/migrating-away-apt-key/

I'm sure it'll prove useful to you.  It expands on (some of) what's
already been said in this thread.



This indeed is a very helpful blog post!
Always feeling intimidated to bother you experts with my stupid 
questions, I now found the topic also being picked by the German spoken 
"linuxnews.de" site, where they updated a related older post from April 
with the information from Klose's new blog post. Seems as if my question 
was not so stupid but was touching a problem which more people found 
worth to comment on.

Marco.

Re: apt-key says deprecated, but not saying what else to use

[Marco Möller]

On 20.06.21 14:11, Darac Marjal wrote:


On 19/06/2021 21:07, Marco Möller wrote:


Hello,
Command apt-key and its man page say that apt-key is deprecated, but
do not suggest an instead recommended tool. It is only mentioned that
keys would now be organized in /etc/apt/trusted.gpg.d/  . But how
should I manage the keys saved there, for instance how to update them,
or what tool of the Debian distribution is managing them there for the
apt functionality of the Debian OS?
Guiding me to a properly up-to-date documentation about this topic
would be welcome!
Marco.


For some time, I've been using /etc/apt/trusted.gpg.d rather than using
apt-key. As I understand it, keys in apt-key are trusted to sign *any*
repository you pull from. That is, if you add a suspicious repository
and somehow they were able to push packages signed with their key to the
main debian repo servers, then you'd not be able to distinguish between
"signed by Debian" and "signed by attacker".

Instead, the preferred method is to put binary GPG keys into
/etc/apt/trusted.gpg.d (that is, you might need to run "gpg --dearmor"
if you download an ascii-armoured key). Files there can have any name
it's purely up to the system administrator what the names are, but it
makes sense that they indicate the repository they sign. Then, in
/etc/apt/sources.list.d/*.list, you need to write:

deb [signed-by=/etc/apt/trusted.gpg.d/somekey.gpg]
https://repo.attacker.com/ stable main

Now, only this repository trusts that key. If packages there are signed
by another key, verification fails. Similarly, if packages in another
repository are signed by that key, verification fails.

You ask about updating them. There is, as far as I know, no automatic
method for updating these keys, nor for automatically adding them right
now. That's because it's generally considered good practice to add the
key manually. You need to actively state that you trust this repository
on your system. So, for most repositories, that involves a web page
somewhere that says "This is our 'deb ... ' line and this is a link to
our public key." The key will usually be valid for several years, but if
it does start to fail, apt tools *will* tell you that the key has
expired, and that's time to go back and revisit the original site, and
see if they have a new key available.


Thanks a lot, this is quite helpful information!

I now understand that these gpg keys in the /etc/apt/trusted.gpg.d/ 
sub-directory are managed by apt after simply having placed manually the 
files there, each file containing a binary formatted key. These keys are 
automatically trusted by apt and hence the "trusted.gpg.d" label for 
that sub-directory. Keys at this location are not related to the openPGP 
key management which as a user is usually done with the explicit use of 
the gpg command. Because of apt internally managing these keys and these 
keys not intended to become manipulated manually with the gpg command by 
the system administrating user, the gpg command --refresh-keys cannot be 
used as a replacement for the deprecated "apt-key update" command.

Please correct me if I would have got it wrong.
Thanks a lot! Marco.

Re: apt-key says deprecated, but not saying what else to use

[Jonathan Dowland]

On Sun, Jun 20, 2021 at 10:21:52AM -0400, Dan Ritter wrote:

This is ssh key management, not apt key management. apt key
things are for trusting package repositories.

...

Here's what you should do:


Kindly change the Subject: when you change the subject.

--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: apt-key says deprecated, but not saying what else to use

[Dan Ritter]

Greg Wooledge wrote: 
> On Sun, Jun 20, 2021 at 03:00:20PM -0400, Dan Ritter wrote:
> > The directory can just be created, and then the perms need to be
> > 
> > chmod 600 ~/.ssh
> 
> 700, sir.

Thank you.

-dsr-

Re: apt-key says deprecated, but not saying what else to use

[Greg Wooledge]

On Sun, Jun 20, 2021 at 03:00:20PM -0400, Dan Ritter wrote:
> The directory can just be created, and then the perms need to be
> 
> chmod 600 ~/.ssh

700, sir.

Re: apt-key says deprecated, but not saying what else to use

[Dan Ritter]

Gene Heskett wrote: 
> On Sunday 20 June 2021 10:21:52 Dan Ritter wrote:
> 
> > Gene Heskett wrote:
> > > I'd like to pleaed for a new apt-key, one that would survey the
> > > existing list, and on finding a key that is expired or is no longer
> > > associated, offer the option of removing it, or refreshiing it.
> > >
> > > I have up to 7 machines on my local network, usually accessed by
> > > some ssh/sshfs variation, but my current keyring since I'm first
> > > user, probably has 30 some keys, many of which are useless as the
> > > target machine has been changed by a new machine and a new bare
> > > metal install.
> >
> > This is ssh key management, not apt key management. apt key
> > things are for trusting package repositories.
> 
> okay, but
> >
> > Here's what you should do:
> >
> > 1. create a new ssh keypair on your main machine:
> > ssh-keygen -t rsa -b 4096 -f gene2021
> 
> Done. generated /home/gene/gene2021 and /home/gene/gene2021.pub
> 
> > 2. for each $targetmachine in your 7 machines, do this:
> > - ssh $targetmachine
> > - mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old
> 
> 4 of the 6 machines have no .ssh directory in /home/gene. ssh may have 
> had to be installed after the bare metal install of debian 10 using the 
> linuxcnc install cd. sshfs and its deps sure had to be after the first 
> reboot. I'll go bug the LinuxCNC install spinners, been meaning to do it 
> for months.
> 
> Is it sufficient to create that directory, and 
> touch .ssh/authorized_keys?

The directory can just be created, and then the perms need to be

chmod 600 ~/.ssh

authorized_keys will be created by ssh-copy-id.

> Also, the main machine, this one is still on stretch. With 310 gb used of 

All of these commands work on stretch and later.

-dsr-

Re: apt-key says deprecated, but not saying what else to use

[tomas]

On Sun, Jun 20, 2021 at 12:57:10PM -0400, Gene Heskett wrote:

[...]

> Is it sufficient to create that directory, and 
> touch .ssh/authorized_keys?

Creating the directory should be enough: ssh-copy-id will
take care of making (or overwriting) the file.

You'll want to make sure the SSH server package is installed:
openssh-server.

Cheers
 - t


signature.asc
Description: Digital signature

Re: apt-key says deprecated, but not saying what else to use

[Gene Heskett]

On Sunday 20 June 2021 10:21:52 Dan Ritter wrote:

> Gene Heskett wrote:
> > I'd like to pleaed for a new apt-key, one that would survey the
> > existing list, and on finding a key that is expired or is no longer
> > associated, offer the option of removing it, or refreshiing it.
> >
> > I have up to 7 machines on my local network, usually accessed by
> > some ssh/sshfs variation, but my current keyring since I'm first
> > user, probably has 30 some keys, many of which are useless as the
> > target machine has been changed by a new machine and a new bare
> > metal install.
>
> This is ssh key management, not apt key management. apt key
> things are for trusting package repositories.

okay, but
>
> Here's what you should do:
>
> 1. create a new ssh keypair on your main machine:
> ssh-keygen -t rsa -b 4096 -f gene2021

Done. generated /home/gene/gene2021 and /home/gene/gene2021.pub

> 2. for each $targetmachine in your 7 machines, do this:
> - ssh $targetmachine
> - mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old

4 of the 6 machines have no .ssh directory in /home/gene. ssh may have 
had to be installed after the bare metal install of debian 10 using the 
linuxcnc install cd. sshfs and its deps sure had to be after the first 
reboot. I'll go bug the LinuxCNC install spinners, been meaning to do it 
for months.

Is it sufficient to create that directory, and 
touch .ssh/authorized_keys?

Also, the main machine, this one is still on stretch. With 310 gb used of 
a 2T spinning rust drive as /. I have a 500 gb samsung SSD, but haven't 
found a round-tuit cuz I'd probably wear out the SSD until I get at 
least a 1T SSD I can afford.  Thats getting closer though. But it will 
not happen when I am in the middle of designing and building a new, 
smaller harmonic drive for one of my cnc machines.

> - don't close that terminal
> - open a new terminal and make sure you can ssh in by
>   password, then
> - ssh-copy-id gene2021 $targetmachine
> - make sure you can ssh in with the gene2021 key:
>   ssh -i gene2021 $targetmachine
> - if it's good, close both terminals and go on to the next
>   $targetmachine
>
> 3. clean up: remove keys in ~/.ssh/  that aren't gene2021 and
>aren't useful otherwise.
>
> Now you have one known good keypair that lets you in to all
> seven machines without a password, and you can use a password as
> fallback.
>
> -dsr-


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: apt-key says deprecated, but not saying what else to use

[Brad Rogers]

On Sat, 19 Jun 2021 22:07:35 +0200
Marco Möller  wrote:

Hello Marco,

>Command apt-key and its man page say that apt-key is deprecated, but do 

Coincidentally, I recently got notification of a pertinent blog post by
Julian Andres Klode.  See;
https://blog.jak-linux.org/2021/06/20/migrating-away-apt-key/

I'm sure it'll prove useful to you.  It expands on (some of) what's
already been said in this thread.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
My body's an oasis to drink from as you please
Mirage - Siouxsie & The Banshees


pgpe4_np0aazj.pgp
Description: OpenPGP digital signature

Re: apt-key says deprecated, but not saying what else to use

[Gene Heskett]

On Sunday 20 June 2021 10:21:52 Dan Ritter wrote:

> Gene Heskett wrote:
> > I'd like to pleaed for a new apt-key, one that would survey the
> > existing list, and on finding a key that is expired or is no longer
> > associated, offer the option of removing it, or refreshiing it.
> >
> > I have up to 7 machines on my local network, usually accessed by
> > some ssh/sshfs variation, but my current keyring since I'm first
> > user, probably has 30 some keys, many of which are useless as the
> > target machine has been changed by a new machine and a new bare
> > metal install.
>
> This is ssh key management, not apt key management. apt key
> things are for trusting package repositories.
>
> > I consider those "dead" keys to be security risks. But at present,
> > there is not a means to identify and remove them that I am aware of.
> >
> > So I would plead for an apt-key replacement that would automate that
> > process. At the present state, my connection scripts to
> > re-establlish my local network after a reboot or power failure
> > recovery, are all blocked because of machine replacements/reinstalls
> > using the same ip address yadda yadda, so I must answer yes, then
> > supply my first user password for that machine because I do want to
> > continue connecting to that machine. That can rapidly turn into a
> > PITA.
>
> Here's what you should do:
>
> 1. create a new ssh keypair on your main machine:
> ssh-keygen -t rsa -b 4096 -f gene2021
>
> 2. for each $targetmachine in your 7 machines, do this:
> - ssh $targetmachine
> - mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old
> - don't close that terminal
> - open a new terminal and make sure you can ssh in by
>   password, then
> - ssh-copy-id gene2021 $targetmachine
> - make sure you can ssh in with the gene2021 key:
>   ssh -i gene2021 $targetmachine
> - if it's good, close both terminals and go on to the next
>   $targetmachine
>
> 3. clean up: remove keys in ~/.ssh/  that aren't gene2021 and
>aren't useful otherwise.
>
> Now you have one known good keypair that lets you in to all
> seven machines without a password, and you can use a password as
> fallback.
>
> Now, it sounds like you also have a problem with machines
> getting randomly assigned IP addresses. In a network of size 7,
> I would strongly advise you to stop using DHCP and just put in
> static IP assignments for each machine in
> /etc/network/interfaces.
>
> -dsr-
I haven't used dhcp in 23 years, don't even run a server in my dd-wrt 
router.  Used a hosts file on my first install in 1998, never saw an 
advantage to changing.

Sometimes a new machine gets added while the old one is still live and 
eventually gets renamed/readdressed when the old one has supplied its 
data to the new one and is turned off for good, but those keys remain.

Case in point, demoing side effects, I had a pair of ark shoeboxes 
running cnc machines in the garage and they started to fail a year ago 
so I bought 4 off-lease dell 7010's with 4 core i5's and 4 gigs of ram 
as thats a great plenty to run LinuxCNC. No drives, no winders licence. 
Cheap that way.

The old ark's with d525mw mobos were so noisy I had to be within 10 feet 
of the garage door motor to run it with a pocket pad.  After replacing 
the old arks with the dells, all with SSD's now, I found my pocket pad 
could run it from 80+ feet away.  The Dells were that much quieter. But 
they run 24/7 and I am seeing a rise in my electric bill from all those 
old i5's. But one got dedicated to running a 3d printer so got its dram 
filled up and its been shut down and rebooted a couple hundred times 
since with no problems in its SDD so I may start shutting them down but 
then when do I turn amanda loose to back them up? She doesn't like her 
schedule to be disturbed.

If I live long enough, I'm 86 now, I may convert them all to being run 
with rpi4's. Draws about 25 watts with its monitor, but runs a 4kw 
machine when LinuxCNC is running as the machines power is 100% 
controlled by LinuxCNC. And the rpi4 has more than enough giddyup to run 
LinuxCNC well. An rpi3 can do it too, but its being pushed. Part of that 
holdup is the cost of the interfacing to the pi's, over $200 a copy. 4 
mesa cards involved per copy.

Thanks for the instructs Dan, recipe printed, I'll see about doing the 
cleanup one machine at a time.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: apt-key says deprecated, but not saying what else to use

[Charles Curley]

On Sun, 20 Jun 2021 10:21:52 -0400
Dan Ritter  wrote:

> Now, it sounds like you also have a problem with machines
> getting randomly assigned IP addresses. In a network of size 7,
> I would strongly advise you to stop using DHCP and just put in 
> static IP assignments for each machine in
> /etc/network/interfaces.

That certainly will work. Since Gene already has dhcp up and running,
he can also use it to assign fixed ip addresses, e.g.:

host orca   # Lenovo T61

{
   option host-name "orca";
   hardware ethernet 00:13:8E:BA:7E:59;
   fixed-address 192.168.101.18;
   ddns-hostname orca;
}


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: apt-key says deprecated, but not saying what else to use

[Dan Ritter]

Gene Heskett wrote: 
> I'd like to pleaed for a new apt-key, one that would survey the existing 
> list, and on finding a key that is expired or is no longer associated, 
> offer the option of removing it, or refreshiing it.
> 
> I have up to 7 machines on my local network, usually accessed by some 
> ssh/sshfs variation, but my current keyring since I'm first user, 
> probably has 30 some keys, many of which are useless as the target 
> machine has been changed by a new machine and a new bare metal install.

This is ssh key management, not apt key management. apt key
things are for trusting package repositories.

> I consider those "dead" keys to be security risks. But at present, there 
> is not a means to identify and remove them that I am aware of.
> 
> So I would plead for an apt-key replacement that would automate that 
> process. At the present state, my connection scripts to re-establlish my 
> local network after a reboot or power failure recovery, are all blocked 
> because of machine replacements/reinstalls using the same ip address 
> yadda yadda, so I must answer yes, then supply my first user password 
> for that machine because I do want to continue connecting to that 
> machine. That can rapidly turn into a PITA.

Here's what you should do:

1. create a new ssh keypair on your main machine:
ssh-keygen -t rsa -b 4096 -f gene2021

2. for each $targetmachine in your 7 machines, do this:
- ssh $targetmachine
- mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old
- don't close that terminal 
- open a new terminal and make sure you can ssh in by
  password, then
- ssh-copy-id gene2021 $targetmachine
- make sure you can ssh in with the gene2021 key:
  ssh -i gene2021 $targetmachine
- if it's good, close both terminals and go on to the next
  $targetmachine

3. clean up: remove keys in ~/.ssh/  that aren't gene2021 and
   aren't useful otherwise.

Now you have one known good keypair that lets you in to all
seven machines without a password, and you can use a password as
fallback.

Now, it sounds like you also have a problem with machines
getting randomly assigned IP addresses. In a network of size 7,
I would strongly advise you to stop using DHCP and just put in 
static IP assignments for each machine in
/etc/network/interfaces.

-dsr-

Re: apt-key says deprecated, but not saying what else to use

[Gene Heskett]

On Sunday 20 June 2021 08:11:45 Darac Marjal wrote:

> On 19/06/2021 21:07, Marco Möller wrote:
> > Hello,
> > Command apt-key and its man page say that apt-key is deprecated, but
> > do not suggest an instead recommended tool. It is only mentioned
> > that keys would now be organized in /etc/apt/trusted.gpg.d/  . But
> > how should I manage the keys saved there, for instance how to update
> > them, or what tool of the Debian distribution is managing them there
> > for the apt functionality of the Debian OS?
> > Guiding me to a properly up-to-date documentation about this topic
> > would be welcome!
> > Marco.
>
> For some time, I've been using /etc/apt/trusted.gpg.d rather than
> using apt-key. As I understand it, keys in apt-key are trusted to sign
> *any* repository you pull from. That is, if you add a suspicious
> repository and somehow they were able to push packages signed with
> their key to the main debian repo servers, then you'd not be able to
> distinguish between "signed by Debian" and "signed by attacker".
>
> Instead, the preferred method is to put binary GPG keys into
> /etc/apt/trusted.gpg.d (that is, you might need to run "gpg --dearmor"
> if you download an ascii-armoured key). Files there can have any name
> it's purely up to the system administrator what the names are, but it
> makes sense that they indicate the repository they sign. Then, in
> /etc/apt/sources.list.d/*.list, you need to write:
>
> deb [signed-by=/etc/apt/trusted.gpg.d/somekey.gpg]
> https://repo.attacker.com/ stable main
>
> Now, only this repository trusts that key. If packages there are
> signed by another key, verification fails. Similarly, if packages in
> another repository are signed by that key, verification fails.
>
> You ask about updating them. There is, as far as I know, no automatic
> method for updating these keys, nor for automatically adding them
> right now. That's because it's generally considered good practice to
> add the key manually. You need to actively state that you trust this
> repository on your system. So, for most repositories, that involves a
> web page somewhere that says "This is our 'deb ... ' line and this is
> a link to our public key." The key will usually be valid for several
> years, but if it does start to fail, apt tools *will* tell you that
> the key has expired, and that's time to go back and revisit the
> original site, and see if they have a new key available.

I'd like to pleaed for a new apt-key, one that would survey the existing 
list, and on finding a key that is expired or is no longer associated, 
offer the option of removing it, or refreshiing it.

I have up to 7 machines on my local network, usually accessed by some 
ssh/sshfs variation, but my current keyring since I'm first user, 
probably has 30 some keys, many of which are useless as the target 
machine has been changed by a new machine and a new bare metal install.

I consider those "dead" keys to be security risks. But at present, there 
is not a means to identify and remove them that I am aware of.

So I would plead for an apt-key replacement that would automate that 
process. At the present state, my connection scripts to re-establlish my 
local network after a reboot or power failure recovery, are all blocked 
because of machine replacements/reinstalls using the same ip address 
yadda yadda, so I must answer yes, then supply my first user password 
for that machine because I do want to continue connecting to that 
machine. That can rapidly turn into a PITA.

Thanks for this thread.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: apt-key says deprecated, but not saying what else to use

[Darac Marjal]

On 19/06/2021 21:07, Marco Möller wrote:
>
> Hello,
> Command apt-key and its man page say that apt-key is deprecated, but
> do not suggest an instead recommended tool. It is only mentioned that
> keys would now be organized in /etc/apt/trusted.gpg.d/  . But how
> should I manage the keys saved there, for instance how to update them,
> or what tool of the Debian distribution is managing them there for the
> apt functionality of the Debian OS?
> Guiding me to a properly up-to-date documentation about this topic
> would be welcome!
> Marco.

For some time, I've been using /etc/apt/trusted.gpg.d rather than using
apt-key. As I understand it, keys in apt-key are trusted to sign *any*
repository you pull from. That is, if you add a suspicious repository
and somehow they were able to push packages signed with their key to the
main debian repo servers, then you'd not be able to distinguish between
"signed by Debian" and "signed by attacker".

Instead, the preferred method is to put binary GPG keys into
/etc/apt/trusted.gpg.d (that is, you might need to run "gpg --dearmor"
if you download an ascii-armoured key). Files there can have any name
it's purely up to the system administrator what the names are, but it
makes sense that they indicate the repository they sign. Then, in
/etc/apt/sources.list.d/*.list, you need to write:

deb [signed-by=/etc/apt/trusted.gpg.d/somekey.gpg]
https://repo.attacker.com/ stable main

Now, only this repository trusts that key. If packages there are signed
by another key, verification fails. Similarly, if packages in another
repository are signed by that key, verification fails.

You ask about updating them. There is, as far as I know, no automatic
method for updating these keys, nor for automatically adding them right
now. That's because it's generally considered good practice to add the
key manually. You need to actively state that you trust this repository
on your system. So, for most repositories, that involves a web page
somewhere that says "This is our 'deb ... ' line and this is a link to
our public key." The key will usually be valid for several years, but if
it does start to fail, apt tools *will* tell you that the key has
expired, and that's time to go back and revisit the original site, and
see if they have a new key available.





OpenPGP_signature
Description: OpenPGP digital signature