Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial
Thank you very much, Tomás.
tomas@tuxteam.de:
> On Fri, Sep 23, 2016 at 12:31:00PM +0000, Stephan Beck wrote:
>> Hi
>> tomas@tuxteam.de:
>>> On Thu, Sep 22, 2016 at 03:35:00PM +0000, Stephan Beck wrote:
[...]
>> I have created a new user account with
>> adduser --disabled-password
>> What do I want to do?
>> I'd like to login to this account "test" from my normal user account by
>> ssh via pubkey authentication. My (normal) user account has its keys
>> generated and properly deposited on localhost. I logged into the account
>> "test" via su - test, creating a keypair. Fine.
>
> Hang on: your new account (test( doesn't need a keypair. It's your regular
> account which needs one (and has one already). You want to log in *from*
> your regular account (let's call it "seph" for now) *to* test, right?
There are two things here: I had in mind to login from my user account
via ssh to the test account (just to be able to (completely) ssh inside
my machine [for training purposes] and, on the other hand, to ssh
towards the outside (see next sentence) as well. As to the "outside"
part, from the test account I want to login as client to a remote server
and because of that this test account needs a key pair, too. Yes, I know
it has to be deposited on that server, but, again, at the moment of this
thread I still am with (setting up) sshing inside my machine.
>
> Then it's *steph* who has to have a keypair and *test* who has to have
> *steph*'s public key included in its ~/.ssh/authorized_keys:
>
>
> *steph* *test*
> .ssh/ .ssh/
> id_rsa authorized_keys
> id_rsa.pub ^
> \ |
> ------ add -------´
>
>
> The background is that now *steph* can prove to *test* that he has the
> right secret key (without disclosing it).
OK, I got it, concerning sshing inside my machine. I got confused here
as I remembered that when I had a normal user account (with wheezy) and
a chroot environment (with debian sid installed) on the same machine I
could login from one to the other and vice versa via localhost using ssh
(well, if I remember correctly). It's different, for sure, but it
confused me.
>
[...]
> You cannot log into test without superpowers, but you have to modify its
> ~/.ssh/authorized_keys. That means you *need* superpowers. For example
>
> sudo -s # or similar
> cat ~steph/.ssh/id_rsa.pub >> ~/test/.ssh/authorized_keys
> chown test:test ~/test/.ssh/authorized_keys
> exit
But once my user's (in your terminology, steph's) public key is in the
test account's authorized_keys file, user steph can login without
superpowers, by presenting the private part of the key (well ssh-agent
does it, if I understand things correctly), can't I?
My great mistake was to think that localhost, although being on the same
machine, acts as a somewhat separated server and for that reason the
public keys of all users have to be deposited physically, in a sort of
directory structure within localhost (not in the user's directory),as it
is the case on a remote server. But, as Greg made very clear, I'm
already on the same machine. That was the conceptual mistake I made.
>
> (the chown just in case authorized_keys didn't exist before).
Well, I have, i.e. had created an authorized_keys with the dd command.
It's there and it contains the public key.
>
[,,,]
> Either you give this new user a password (temporarily) or you have to
> be able to write to its .ssh directory by other means. One of those
> means is by becoming root (as sketched above). There are others, like
>
> - adding yourself to this new user's group and making sure
> its ~/.ssh/authorized_keys is group writable (feels somewhat
> uncomfortable, though)
Uuuuuh! No way.
>
> - creating the user's home directory from a prepared skeleton
> already containing an "authorized_keys" as you need it
Ah, that would be fine, but I guess, this time it has to be the hard
way, by typing, without prepared skeletons.
I have to make a break and then I will try to get it done.
Thanks again.
Stephan
Reply to: