If I have PasswordAuthentication enabled on a remote host (tested on MacOS and FreeBSD so far), I can log in to them without any problem. However, if I have passwords disabled, but have an RSA key on the Plan 9 host and the corresponding pub key in authorized_keys on those remote hosts, I'm failing to log in with the error message: ssh: auth: no key matches proto=rsa service=ssh role=client Presumably, this means I haven't set something up somewhere. Currently, I do not have an auth server - I'm doing everything from a terminal, slowly working my way up to a full world. Is there a way to make this work in such an environment, without jumping through more hoops than getting an auth server going would take? Thanks. Dworkin ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-M41815fdb9ca0d8fb85abfa9a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Dworkin Muller <dlm-9fans@weaselfish.com>: > If I have PasswordAuthentication enabled on a remote host (tested on > MacOS and FreeBSD so far), I can log in to them without any problem. > However, if I have passwords disabled, but have an RSA key on the Plan 9 > host and the corresponding pub key in authorized_keys on those remote > hosts, I'm failing to log in with the error message: > > ssh: auth: no key matches proto=rsa service=ssh role=client > > Presumably, this means I haven't set something up somewhere. > Currently, I do not have an auth server - I'm doing everything from a > terminal, slowly working my way up to a full world. Is there a way to > make this work in such an environment, without jumping through more > hoops than getting an auth server going would take? > > Thanks. > > Dworkin there's an example in the rsa(8) manpage. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-M07ee0b71cb7faf20cff1fe30 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Sun, 24 Jan 2021 22:33:59 -0800, ori@eigenstate.org wrote: ori> Quoth Dworkin Muller <dlm-9fans@weaselfish.com>: ori> > If I have PasswordAuthentication enabled on a remote host (tested on ori> > MacOS and FreeBSD so far), I can log in to them without any problem. ori> > However, if I have passwords disabled, but have an RSA key on the Plan 9 ori> > host and the corresponding pub key in authorized_keys on those remote ori> > hosts, I'm failing to log in with the error message: ori> > ori> > ssh: auth: no key matches proto=rsa service=ssh role=client ori> > ori> > Presumably, this means I haven't set something up somewhere. ori> > Currently, I do not have an auth server - I'm doing everything from a ori> > terminal, slowly working my way up to a full world. Is there a way to ori> > make this work in such an environment, without jumping through more ori> > hoops than getting an auth server going would take? ori> > ori> > Thanks. ori> > ori> > Dworkin ori> ori> there's an example in the rsa(8) manpage. That's what I thought I'd been doing, and doing it again just now gives the same results. ``cat /mnt/factotum/ctl'' gives two lines, one starting ``key proto=pass server=lethe service=ssh ...'' and the other ``key proto=rsa service=ssh ...''. I've triple checked that what's in .authorized_keys on the remote host (lethe) matches the output of auth/rsa2ssh. I've also verified that the proto=rsa line in factotum matches my lib/ssh/rsa file. Thus my confusion. Thanks. Dworkin ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-M877d35325ba8c613afebac3c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> there's an example in the rsa(8) manpage There's a different example in the ssh2(1) man page, which is what works for me. Note the use of rsa2ssh2 instead of auth/rsa2ssh. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-M9a9c0c8258ae602fb6eabb30 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Dworkin Muller <dlm-9fans@weaselfish.com>: > On Sun, 24 Jan 2021 22:33:59 -0800, ori@eigenstate.org wrote: > ori> Quoth Dworkin Muller <dlm-9fans@weaselfish.com>: > ori> > If I have PasswordAuthentication enabled on a remote host (tested on > ori> > MacOS and FreeBSD so far), I can log in to them without any problem. > ori> > However, if I have passwords disabled, but have an RSA key on the Plan 9 > ori> > host and the corresponding pub key in authorized_keys on those remote > ori> > hosts, I'm failing to log in with the error message: > ori> > > ori> > ssh: auth: no key matches proto=rsa service=ssh role=client > ori> > > ori> > Presumably, this means I haven't set something up somewhere. > ori> > Currently, I do not have an auth server - I'm doing everything from a > ori> > terminal, slowly working my way up to a full world. Is there a way to > ori> > make this work in such an environment, without jumping through more > ori> > hoops than getting an auth server going would take? > ori> > > ori> > Thanks. > ori> > > ori> > Dworkin > ori> > ori> there's an example in the rsa(8) manpage. > > That's what I thought I'd been doing, and doing it again just now > gives the same results. ``cat /mnt/factotum/ctl'' gives two lines, > one starting ``key proto=pass server=lethe service=ssh ...'' and the > other ``key proto=rsa service=ssh ...''. I've triple checked that > what's in .authorized_keys on the remote host (lethe) matches the > output of auth/rsa2ssh. I've also verified that the proto=rsa line in > factotum matches my lib/ssh/rsa file. Thus my confusion. > > Thanks. > > Dworkin First off, sanity check: are you running ssh in the same namespace as the factotum? Are you using a drawterm factotum, or are you using one started from within your session? you redacted a lot of the factotum value -- does the value in factotum have all of these fields? key proto=rsa service=ssh size=2048 ek=10001 n=... !dk? !p? !q? !kp? !kq? !c2? finally, can you paste the output of 'ssh -d yoursystem'? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-M13aa5c5d2052fc3c2bd0c8ac Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Mon, 25 Jan 2021 12:14:01 +0000, Richard Miller <9fans@hamnavoe.com> wrote: 9fans> There's a different example in the ssh2(1) man page, which 9fans> is what works for me. Note the use of rsa2ssh2 instead of 9fans> auth/rsa2ssh. Hmm. This may be part of my confusion. There is nothing with ``ssh2'' in the name on my system (du -a / | grep ssh2). This is a stock 9front install from roughly a week ago. It's entirely possible I fumbled something doing the install, of course: term% du -a [36]* [a-c]* dist env [l-n]* pow* [r-u]* | grep ssh2 du: n/other/usr/glenda/tmp: 'n/other/usr/glenda/tmp' access permission denied (the obnoxious inclusion list is because du seemed to hang in /dev) I'll be sending an update per Ori's request soon. Thanks. Dworkin ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-Ma61cb084b4c440cd967378c3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Dworkin Muller <dlm-9fans@weaselfish.com>: > On Mon, 25 Jan 2021 12:14:01 +0000, Richard Miller <9fans@hamnavoe.com> wrote: > 9fans> There's a different example in the ssh2(1) man page, which > 9fans> is what works for me. Note the use of rsa2ssh2 instead of > 9fans> auth/rsa2ssh. > > Hmm. This may be part of my confusion. There is nothing with > ``ssh2'' in the name on my system (du -a / | grep ssh2). This is a > stock 9front install from roughly a week ago. It's entirely possible > I fumbled something doing the install, of course: 9front's /sys/src/cmd/ssh.c does ssh2 (and only ssh2, only with new cipher suites). There's no ssh2 any more. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-Mc39f7c596d1a42e5e82384e0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Mon, 25 Jan 2021 07:52:42 -0800, ori@eigenstate.org wrote: ori> First off, sanity check: are you running ssh in the same ori> namespace as the factotum? ori> ori> Are you using a drawterm factotum, or are you using one ori> started from within your session? ori> ori> you redacted a lot of the factotum value -- does the value in factotum ori> have all of these fields? ori> ori> key proto=rsa service=ssh size=2048 ek=10001 n=... !dk? !p? !q? !kp? !kq? !c2? ori> ori> finally, can you paste the output of 'ssh -d yoursystem'? Apologies for the lack of detail in previous messages. It's kind of awkward to get transcripts when the machine doesn't want to talk to anything else. I've managed to get password-based ssh to work, so now I dump to a file and transfer it over via "cat ... | ssh sh -c 'cat > output'". The need at this point is to get it working without requiring password authentication enabled on the remote systems. Taking these in order, my interpretation of what I'm doing/seeing is (raw data is included afterwards): - Booting as a terminal. /env/service says ``terminal'', and I've not knowingly set up anything other than a terminal. - Using the factotum started at boot. - The terminal's running as a VM under VMware Fusion, and I'm using the console window provided by Fusion. As an aside, I noticed that the original Plan 9 distribution knew how to play with Fusion to allow cut/paste, etc, but 9front doesn't; not sure how to get that to work - that's a problem for another time, though. - What's in factotum appears to have all the fields you mention. - The ssh transcript is attached. I can do an "ssh -d -d" if you prefer, as well provide the public host keys and my public key if that would help. I'd rather not give the private key, but generating a new one's not that hard and the machines involved aren't externally accessible, so I can do that too if it would help. I used pstree(1) just to cover all the bases regarding inheritance. help. The middle of "n" from /mnt/factotum/ctl was elided simply for readability. Thanks much for looking at this stupid newby problem. Dworkin term% pstree > foo 1 ├bootrc /bin/bootrc 3 │├pager 4 │├mouse 6 │├alarm 96 │└/amd64/init -t 295 │ └rc -c '. /rc/bin/termrc; home=/usr/$user; cd && . ./lib/profile' 455 │ └rio -i riostart 458 │ ├rio [mouseproc] 459 │ ├rio [kbdproc] 460 │ ├rio [TIMERPROC] 461 │ ├rio [WCTLPROC] 462 │ └rio [FILSYSPROC] 8 ├paqfs 10 ├mntgen 14 ├mntgen 17 ├mntgen 28 ├aoesweep 33 ├rxmitproc 35 ├#l0lproc 36 ├#l0rproc 62 ├kbdfs 63 │└kbdfs [ctlproc] 64 │ ├kbdfs [mctlproc] 65 │ ├kbdfs [scanproc] 66 │ └kbdfs [intrproc] 216 ├factotum 725 │└factotum 264 ├cwfs64x [srvo] 265 ├cwfs64x [srvi stdio] 266 ├cwfs64x [srvo] 267 ├cwfs64x [srvi #s/cwfs] 268 ├cwfs64x [con] 269 ├cwfs64x [rah] 270 ├cwfs64x [srv] 271 ├cwfs64x [srv] 272 ├cwfs64x [srv] 273 ├cwfs64x [srv] 274 ├cwfs64x [srv] 275 ├cwfs64x [srv] 276 ├cwfs64x [srv] 277 ├cwfs64x [srv] 278 ├cwfs64x [srv] 279 ├cwfs64x [srv] 280 ├cwfs64x [srv] 281 ├cwfs64x [srv] 282 ├cwfs64x [srv] 283 ├cwfs64x [srv] 284 ├cwfs64x [srv] 286 ├cwfs64x [wcp] 287 ├cwfs64x [scp] 325 ├cs [/net] 359 ├etherread4 360 ├etherread6 361 ├recvarpproc 370 ├ipconfig [dhcpwatch on /net/ether0] 376 ├dns [/net] 380 ├timesync 385 ├realemu 386 │└realemu [cpuproc] 445 ├webcookies 448 ├webfs 451 ├plumber 452 │└plumber 471 ├stats -lmisce 501 │├stats 502 │├stats 503 │└stats 483 ├rc -c '/bin/window -x cat /dev/kprint ' 485 │└cat /dev/kprint 486 ├rc -c '/bin/window -x acme ' 488 │└acme 497 │ ├acme [timerproc] 498 │ ├acme [mouseproc] 499 │ ├acme [kbdproc] 500 │ ├acme [plumbproc] 504 │ ├acme 505 │ └acme [acmeerrorproc] 508 ├rc -i 1418 │└pstree 514 ├#I0ilack 516 ├#I0tcpack 1417 └closeproc 1419 └closeproc term% cat /mnt/factotum/ctl >> foo key proto=rsa service=ssh size=2048 ek=10001 n=8DA505[...]46A9D02F !dk? !p? !q? !kp? !kq? !c2? term% ssh -d lethe >> foo server verison: SSH-2.0-OpenSSH_7.9 FreeBSD-20200214 kexalgs: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 hostalgs: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 cipher1: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc cipher2: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc mac1: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 mac2: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 zip1: none,zlib@openssh.com zip2: none,zlib@openssh.com lang1: lang2: host fingerprint: GaqQLmeZje1D03tR8B78KvJOtoUJiL5Anhi3BXWXWwQ userauth none ok userauth none failed: partial=0, next=publickey userauth none skipped userauth publickey ok userauth publickey failed: partial=0, next=publickey userauth publickey ok userauth password skipped userauth keyboard-interactive skipped ssh: auth: no key matches proto=rsa service=ssh role=client ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-M967fce2ff51931fcd1718dca Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
You're missing the 'role=client' tuple. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-M6e96e6354356366203ac231b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Tue, 26 Jan 2021 12:24:35 +1030, Alex Musolino <alex@musolino.id.au> wrote: alex> You're missing the 'role=client' tuple. You are exactly correct. Looks like rsa(8) has a bug in its example for generating and installing a fresh key for a remote Unix system, in that it says to use: auth/rsagen -t 'service=ssh' >key auth/rsa2ssh key | ssh unix 'cat >>.ssh/authorized_keys' cat key >/mnt/factotum/ctl ssh unix Inferring from the example generating a tinc host key, it appears that the first line should instead be: auth/rsagen -t 'service=ssh role=client' >key Thank you *very* much for catching that. Dworkin ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-Mf0b3a263a2410234686cf460 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Nevermind. It doesn't matter. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-M7475d1a41736a02e67e3842c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> You are exactly correct. Looks like rsa(8) has a bug in its example > for generating and installing a fresh key for a remote Unix system, in > that it says to use: > > auth/rsagen -t 'service=ssh' >key > auth/rsa2ssh key | ssh unix 'cat >>.ssh/authorized_keys' > cat key >/mnt/factotum/ctl > ssh unix I'm confused. You're already using ssh to send the new key across. How do you know this new key is actually working? It's probably just using the same authentication mechanism (password?) that allowed the first invocation to succeed. As I said in a follow up email, I was wrong about the role=client tuple. Factotum ignores this when looking up entries. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-Mce4d4e49b801bbe9b645e7a1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Tue, 26 Jan 2021 13:19:07 +1030, Alex Musolino <alex@musolino.id.au> wrote: alex> I'm confused. You're already using ssh to send the new key across. alex> How do you know this new key is actually working? It's probably just alex> using the same authentication mechanism (password?) that allowed the alex> first invocation to succeed. As I said in a follow up email, I was alex> wrong about the role=client tuple. Factotum ignores this when looking alex> up entries. The first ssh was done using password. I then deleted the password item in factotum's store and disabled it on the receiving machine. The addition of role=client does seem to have fixed it, although my understanding had also been that that was an unnecessary field. However, I'm perfectly willing to believe in gremlins at this point, now that it's working ;-) Dworkin ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-Md2908e195e29e983234f2301 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Dworkin Muller <dlm-9fans@weaselfish.com>: > On Tue, 26 Jan 2021 12:24:35 +1030, Alex Musolino <alex@musolino.id.au> wrote: > alex> You're missing the 'role=client' tuple. > > You are exactly correct. Looks like rsa(8) has a bug in its example > for generating and installing a fresh key for a remote Unix system, in > that it says to use: > > auth/rsagen -t 'service=ssh' >key > auth/rsa2ssh key | ssh unix 'cat >>.ssh/authorized_keys' > cat key >/mnt/factotum/ctl > ssh unix > > Inferring from the example generating a tinc host key, it appears that > the first line should instead be: > > auth/rsagen -t 'service=ssh role=client' >key > > Thank you *very* much for catching that. > > Dworkin Now, I'm confused. The example just works for me -- and I use ssh to get into my linux and openbsd machines on a daily basis. I also just spun up a FreeBSD 12.1 vm on vultr to test, and it just worked out of the box for me. (I assume you're on 12.2, but that wasn't an option -- the update is currently running) ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-Mf20b55b72d8ec45320e81836 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Mon, 25 Jan 2021 19:08:43 -0800, ori@eigenstate.org wrote: ori> Now, I'm confused. The example just works for me -- and ori> I use ssh to get into my linux and openbsd machines on ori> a daily basis. ori> ori> I also just spun up a FreeBSD 12.1 vm on vultr to test, ori> and it just worked out of the box for me. (I assume you're ori> on 12.2, but that wasn't an option -- the update is ori> currently running) I suppose it's possible that the authorized_keys file on the remote machine (which is, indeed, 12.2) got corrupted somehow after my early attempts despite my reviewing it a few times. I'd've expected diff to show it, but given the number of keys already there and the number of scenarios I ran through, I could've missed something. If that was the case, then last run through of the example (which required removing the previous copy of the public key) would likely have gotten an uncorrupted version of the public key in there and then things would, of course, started working. This is the sort of situation where I wish for an auto-versioning filesystem, which FreeBSD doesn't have. For that matter, I don't think I've seen one since TOPS-20 (and maybe VMS, didn't use it nearly as much). In any case, at this point there's no way to look at how the contents of the key file changed over time. *sigh* Thanks again, everybody. Dworkin ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td072863a97c9d3e9-Ma136754121814399768e0d9f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription