Thank you very much, Tomás. to...@tuxteam.de: > On Fri, Sep 23, 2016 at 12:31:00PM +0000, Stephan Beck wrote: >> Hi >> to...@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
