experchange > linux.security

JimR (11-21-15, 08:01 PM)
I'm trying to better understand ssh.

User foo on machine bar generates a keypair, and provides the public key
to remote user dokes on machine shme . foo connects to dokes account
at shme, and everything is happy.

Then user foo also has an account on machine baz. He takes the private
key he generated on machine bar, and copies it to machine baz. Can he
connect to dokes on shme? My limited testing suggests that it works.
Is that a universal truth?

Next, foo passes his private key to unrelated user thud on machine
grunt. thud installs the private key owned by foo. Can thud now
connect to user dokes on machine shme?

Next, replace the above ssh keys with PGP keys. Do the same answers apply?

Thanks,
JimR
William Unruh (11-21-15, 08:13 PM)
On 2015-11-21, JimR <NotReally> wrote:
> I'm trying to better understand ssh.
> User foo on machine bar generates a keypair, and provides the public key
> to remote user dokes on machine shme . foo connects to dokes account
> at shme, and everything is happy.
> Then user foo also has an account on machine baz. He takes the private
> key he generated on machine bar, and copies it to machine baz. Can he
> connect to dokes on shme? My limited testing suggests that it works.
> Is that a universal truth?


Yes
> Next, foo passes his private key to unrelated user thud on machine
> grunt. thud installs the private key owned by foo. Can thud now
> connect to user dokes on machine shme? Yes-- but a really really bad idea.


> Next, replace the above ssh keys with PGP keys. Do the same answers apply?


You think there is some sort of dna test that gets done? How in the
world wound anything know who is using the key?
Richard Kettlewell (11-22-15, 04:09 PM)
JimR <NotReally> writes:
[..]
> Next, foo passes his private key to unrelated user thud on machine
> grunt. thud installs the private key owned by foo. Can thud now
> connect to user dokes on machine shme?


The keys are not ‘tied’ to anything. When you permit access to a public
key (in .ssh/authorized_keys), any holder of the corresponding private
key can authenticate.

Copying private keys around is not a great strategy. Consider what
happens when one of the accounts holding the private key is compromised.
Your response to this situation is to remove the corresponding key from
all .ssh/authorized_keys files; i.e. to revoke all access from that key
to anything. If you have the same private key on multiple machines then
the effect is to revoke access from all those machines, even if only one
of them was compromised.

I’d suggest that the only good reason to do this is if there is some
difficulty with having multiple entries in (the equivalent of)
..ssh/authorized_keys.

In short although the keys are not physically connected to user or host,
it’s probably best to treat them as if they were.

> Next, replace the above ssh keys with PGP keys. Do the same answers
> apply?


The same is true of PGP. Any holder of a private key can create
signatures or decrypt received messages (assuming it is a
signature-capable or decryption-capable key, respectively).
jc091966 (06-04-18, 04:25 AM)
On Saturday, November 21, 2015 at 1:10:09 PM UTC-5, JimR wrote:
[..]
> Next, replace the above ssh keys with PGP keys. Do the same answers apply?
> Thanks,
> JimR


I just read your post. How about some appropriate names so we all don't have to keep track of whether "shit" refers to a machine or user.
Hopefully someone else responded to this crap, coz I'm ticked off with the extra work deciphering your questions
William Unruh (06-04-18, 10:40 AM)
On 2018-06-04, jc091966 <jc091966> wrote:
> On Saturday, November 21, 2015 at 1:10:09 PM UTC-5, JimR wrote:


Yes.
Note that there are two keys, a machine key pair, and a personal key pair. The
machine keys are to ensure that you actually connect to the machine you claim
to be connecting to. (the public keys of those machines are stored in
your local machine. It you have never connected to it before, it asks if you
ae sure that you are connecting to the right machine, and if you assure the program you
are it stores the other side's public key on your machine, so you do not have
to give that assurance again) The personal private key is used for the other side to make sure that it
is actually you loggin in (your machine uses the private key to sign a message
which the other side decodes to make sure it is you).
>> Next, foo passes his private key to unrelated user thud on machine
>> grunt. thud installs the private key owned by foo. Can thud now
>> connect to user dokes on machine shme?


Very very stupid move.
>> Next, replace the above ssh keys with PGP keys. Do the same answers apply?


What has PGP to do here? It is not used for connecting to machines. But yes,
your key pair is yours, and if anyone else gets ahold of it, then can reay any
mail you have or ever will encrypt with that key pair. Again a totally stupid
thing to do to let anyone get your private key. Anyone, including your
wife/lover/boss/National security agency.
[..]
Carlos E.R. (06-04-18, 11:35 AM)
On 2018-06-04 04:25, jc091966 wrote:
> On Saturday, November 21, 2015 at 1:10:09 PM UTC-5, JimR wrote:
> I just read your post. How about some appropriate names so we all don't have to keep track of whether "shit" refers to a machine or user.
> Hopefully someone else responded to this crap, coz I'm ticked off with the extra work deciphering your questions


Who cares?

You are replying to a post from 2015. There is no point on asking or
saying anything now.
Aragorn (06-04-18, 12:24 PM)
On Monday 04 June 2018 11:35, Carlos E.R. conveyed the following to
comp.os.linux.security...

> On 2018-06-04 04:25, jc091966 wrote:
> Who cares?
> You are replying to a post from 2015. There is no point on asking or
> saying anything now.


That seems to happen quite a lot with people who use Google Groups as an
interface to Usenet. It is one of the reasons ─ albeit not the only
reason ─ why I've decided to start filtering out anything coming in
through Google Groups. ;)
Carlos E.R. (06-04-18, 01:15 PM)
On 2018-06-04 12:24, Aragorn wrote:
> On Monday 04 June 2018 11:35, Carlos E.R. conveyed the following to
> comp.os.linux.security...
> That seems to happen quite a lot with people who use Google Groups as an
> interface to Usenet. It is one of the reasons ─ albeit not the only
> reason ─ why I've decided to start filtering out anything coming in
> through Google Groups. ;)


I don't filter them out - but I do mark them in different colour ;-)