Discussion:
[9fans] SSHv2
(too old to reply)
andrey mirtchovski
2012-03-30 02:14:04 UTC
Permalink
you rule!
c***@gmx.de
2012-03-30 01:26:11 UTC
Permalink
congratulations! :)

--
cinap
Bruce Ellis
2012-03-30 03:15:23 UTC
Permalink
ha ha, the bunny shakes his tail. i don't want daily updates - like
openssl or NO SALE.

seriously, someone had to do it and not a gsoc kid thank dog.

brucee
Post by c***@gmx.de
congratulations! :)
--
cinap
--
Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)
Lucio De Re
2012-03-30 04:21:47 UTC
Permalink
Thanks to the support of Coraid, I am pleased to announce
that a native SSHv2 implementation is now available in
contrib.
That is marvellous. Thank you, and thanks to Coraid.

Lucio.
Lucio De Re
2012-03-30 04:49:37 UTC
Permalink
contrib/quanstro/root/sys/src/cmd/auth/factotum
There's a "start" member to "struct Srv" that doesn't seem to exist in
</sys/include/9p.h>

I don't mind putting the extra effort into sorting this out, but at
this point there are others who know more than I do. Please feel free
to point me in the right direction if you need the extra eyes or
hands.

++L
David du Colombier
2012-03-30 06:07:40 UTC
Permalink
Post by Lucio De Re
There's a "start" member to "struct Srv" that doesn't
seem to exist in </sys/include/9p.h>
You should apply this patch (from plan9port):

--- /n/sources/plan9/sys/include/9p.h
+++ /sys/include/9p.h
@@ -176,6 +176,7 @@
Tree* tree;
void (*destroyfid)(Fid*);
void (*destroyreq)(Req*);
+ void (*start)(Srv*);
void (*end)(Srv*);
void* aux;

--- /n/sources/plan9/sys/src/lib9p/srv.c
+++ /sys/src/lib9p/srv.c
@@ -702,6 +702,9 @@
srv->fpool->srv = srv;
srv->rpool->srv = srv;

+ if(srv->start)
+ srv->start(srv);
+
while(r = getreq(srv)){
if(r->error){
respond(r, r->error);
--
David du Colombier
Lucio De Re
2012-03-30 08:11:41 UTC
Permalink
Post by Lucio De Re
There's a "start" member to "struct Srv" that doesn't
seem to exist in </sys/include/9p.h>
Thanks, David, that seems to have worked so far.

++L
erik quanstrom
2012-03-30 13:32:34 UTC
Permalink
Post by Lucio De Re
There's a "start" member to "struct Srv" that doesn't
seem to exist in </sys/include/9p.h>
[...]

this should no longer be necessary. as a temporary measure,
i've added the change to lib9p, and the .a's to the factotum
contrib package.

i apoligize for making this difficult. the reason for the change
in lib9p is that we needed start() to happen in the fs thread,
and there was some flush behavior that was otherwise not fixable.

i'll try to fix this problem going forward.

- erik
Jeff Sickel
2012-03-30 05:48:01 UTC
Permalink
Excellent news.
contrib/quanstro/root/sys/src/cmd/auth/factotum
small hint, you'll need to backport 9p.h to build this factotum

-jas
steve
2012-03-30 08:10:52 UTC
Permalink
superb!
Thanks to the support of Coraid, I am pleased to announce
that a native SSHv2 implementation is now available in
contrib/blstuart/ssh
contrib/quanstro/root/sys/src/cmd/auth/factotum
Although not strictly necessary it's also helpful to add ssh
{ "ssh", iplookup, iptrans, 1 },
There's a man page that will hopefully help to get anyone
started who wants to play with it.
No doubt, there are still some rough edges. But we've been
using it at Coraid for a while now so at least a few of the
rough edges should be polished. Also there are some parts
of the code that are a little ugly, and I plan to clean them up.
But lest it live in a perpetual state of "just one more thing I
need to clean up" here it is.
Good luck and enjoy,
BLS
Richard Miller
2012-03-30 09:19:39 UTC
Permalink
contrib/quanstro/root/sys/src/cmd/auth/factotum
How big is the dependency on p9p factotum? Is it just syntactic or
is there some needed functionality in p9p factotum which the sources
version doesn't provide?
Yaroslav
2012-03-30 10:43:01 UTC
Permalink
How big is the dependency on p9p factotum?  Is it just syntactic or
is there some needed functionality in p9p factotum which the sources
version doesn't provide?
It's a strong one: it implements DSA sign/verify.

BTW, without patching ndb/cs as mentioned before one won't be able to
connect by DNS names.
b***@bellsouth.net
2012-03-30 12:48:39 UTC
Permalink
Post by Richard Miller
contrib/quanstro/root/sys/src/cmd/auth/factotum
How big is the dependency on p9p factotum? Is it just syntactic or
is there some needed functionality in p9p factotum which the sources
version doesn't provide?
Quite big. Actually, ssh is the reason we backported p9p
factotum at Coraid.

BLS
erik quanstrom
2012-03-30 12:56:17 UTC
Permalink
Post by b***@bellsouth.net
Post by Richard Miller
contrib/quanstro/root/sys/src/cmd/auth/factotum
How big is the dependency on p9p factotum? Is it just syntactic or
is there some needed functionality in p9p factotum which the sources
version doesn't provide?
Quite big. Actually, ssh is the reason we backported p9p
factotum at Coraid.
also, you'll find that the old factotum doesn't handle things like
flushes (prime example: del at passwd prompt to cancel) very well.

- erik
Richard Miller
2012-04-02 20:50:40 UTC
Permalink
Post by erik quanstrom
also, you'll find that the old factotum doesn't handle things like
flushes (prime example: del at passwd prompt to cancel) very well.
I've never noticed this - can you give a simple example scenario
where it goes wrong?
Richard Miller
2012-04-02 20:08:01 UTC
Permalink
Post by b***@bellsouth.net
Post by Richard Miller
How big is the dependency on p9p factotum? Is it just syntactic or
is there some needed functionality in p9p factotum which the sources
version doesn't provide?
Quite big. Actually, ssh is the reason we backported p9p
factotum at Coraid.
I think sshv2 is a Great Leap Forward (thank you!), but I'm not quite
ready for the upheaval of nfactoum and a non-standard lib9p.

I've attempted a minimal conservative addition to standard factotum
to make it useable with ssh2, and that seems to work for me. If anyone else
wants to try it, just replace /sys/src/cmd/auth/factotum/rsa.c with
/n/sources/contrib/miller/factotum/rsa.c and rebuild.
Lyndon Nerenberg
2012-04-03 02:27:41 UTC
Permalink
Post by Richard Miller
I've attempted a minimal conservative addition to standard factotum
to make it useable with ssh2, and that seems to work for me. If anyone else
wants to try it, just replace /sys/src/cmd/auth/factotum/rsa.c with
/n/sources/contrib/miller/factotum/rsa.c and rebuild.
It's working on my terminal, using both password and rsa auth. I haven't tried genning up a CPU kernel with the new factotum yet.


I notice the new ssh doesn't seem to get along with srv -e. I tried various permutations of -m, -r, -i, and -I, to no avail (trying to u9fs mount a FreeBSD machine). It gets as far as starting u9fs, but the communication channel between srv and ssh isn't happy. In particular, after running

srv -e 'ssh foo u9fs -na none -u me' foo

the post message appears and the shell prompt comes up, but the underlying ssh still has the terminal window in raw mode. At this point you can type and run blind commands, but any attempts to mount /srv/foo will give you a mount that just generates cloning errors. I'm guessing ssh might need a flag to force it to do its I/O on fds 0 and 1 rather than /dev/cons ... ?
Lyndon Nerenberg
2012-04-03 02:31:58 UTC
Permalink
Post by Lyndon Nerenberg
I haven't tried genning up a CPU kernel with the new factotum yet.
Sorry, I meant to say "with Richard's patched original factotum."
rhoyerboat
2012-04-23 08:40:04 UTC
Permalink
Post by Lyndon Nerenberg
Post by Lyndon Nerenberg
I haven't tried genning up a CPU kernel with the new factotum yet.
Sorry, I meant to say "with Richard's patched original factotum."
I haven't tried building a new pccpuf kernel yet either, but on
rebooting with factotum and ssh binaries built from from blstuart/ssh
and on miller/factotum I get to "auth Authentication failed"

I am not sure if there is something else I have configured wrong, any
thoughts/suggestions/other debugging tools?

Here is some output from acid -l truss on my plan9 client, and the
sshd -d logs from my gentoo sshd host


/*acid -l truss /bin/ssh */
acid: new()
acid: truss()
fd2path(0, 0xdfffdeb0, 64)
return value: 0
data: "/dev/cons"
brk_(0x0000fd60)
return value: 0
stat("/net/ssh", 0x0000ede4, 115)
return value: -1
rfork(0x00000038)
return value: 7629
await(0xdfffdcec, 511, 511)
return value: 38
data: "7629 0 10 10 'sshtun 7629: threadmain'"
rfork(0x00000074)
return value: 7632
notify(0x0000405c)
return value: 0
open("/net/cs", 2)
return value: 4
pwrite(4, "ssh!192.168.1.10!22", 19, 4294967295)
return value: 19
seek(0x0000e754, 4, 0, 0)
return value: 0
pread(4, 0xdfffdcb0, 127, 4294967295)
return value: 30
data: "/net/ssh/clone 192.168.1.10!22"
open("/net/ssh/clone", 2)
return value: 7
pread(7, 0xdfffd880, 255, 4294967295)
return value: 1
data: "0"
pwrite(7, "connect 192.168.1.10!22", 23, 4294967295)
return value: 23
open("/net/ssh/0/data", 2)
return value: 10
close(4)
return value: 0
errstr(0xdfffda08, 128, 128)
return value: 0
data: "'/net/ssh' dns: file does not exist"
seek(0x0000e754, 7, 0, 0)
return value: 0
pread(7, 0xdfffdf1c, 10, 4294967295)
return value: 1
data: "0"
open("/dev/cons", 2)
return value: 4
open("/dev/consctl", 1)
return value: 11
pwrite(11, "rawon", 5, 4294967295)
return value: 5
pwrite(7, "ssh-userauth K rhoyerboat", 18, 4294967295)
return value: -1
open("/mnt/factotum/rpc", 2)
return value: 12
brk_(0x00011de8)
return value: 0
pwrite(12, "start proto=pass service=ssh server=192.168.1.10
user=rhoyerboat", 57, 4294967295)
return value: 57
pread(12, 0x0000ed6c, 4096, 4294967295)
return value: 2
data: "ok"
pwrite(12, "read ", 5, 4294967295)
return value: 5
pread(12, 0x0000ed6c, 4096, 4294967295)
return value: 21
data: "ok rhoyerboat XXXX12345"
close(12)
return value: 0
pwrite(7, "ssh-userauth k rhoyerboat XXXX12345", 33, 4294967295)
return value: -1
errstr(0xdfffdbe0, 128, 128)
return value: 0
data: "Authentication failed"
errstr(0xdfffdbe0, 128, 128)
return value: 0
data: "(null)"
pwrite(2, "auth Authentication failed
", 27, 4294967295)
auth Authentication failed
return value: 27
pwrite(11, "rawoff", 6, 4294967295)
return value: 6
close(11)
return value: 0
close(4)
return value: 0
pwrite(0, "close", 5, 4294967295)
return value: -1
close(0)
return value: 0
close(0)
return value: -1
close(10)
return value: 0
close(0)
return value: -1
close(7)
return value: 0
pwrite(0, "kill", 4, 4294967295)
return value: -1
close(0)
return value: -1
open("#c/pid", 0)
return value: 0
pread(0, 0xdfffdec0, 20, 4294967295)
return value: 12
data: " 7628 "
close(0)
return value: 0
7628: breakpoint _exits+0x5 INTB $0x40


/* sshd -d logs */

Connection from 192.168.1.9 port 41598
debug1: HPN Disabled: 0, HPN Buffer Size: 87380
debug1: Client protocol version 2.0; client software version Plan9
SSH: Server;Ltype: Version;Remote: 192.168.1.9-41598;Protocol:
2.0;Client: Plan9
debug1: no match: Plan9
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v10
debug1: permanently_set_uid: 22/22
debug1: MYFLAG IS 1
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-cbc'
debug1: kex: client->server aes128-cbc hmac-sha1 none
SSH: Server;Ltype: Kex;Remote: 192.168.1.9-41598;Enc: aes128-cbc;MAC:
hmac-sha1;Comp: none
debug1: REQUESTED ENC.NAME is 'aes128-cbc'
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: expecting SSH2_MSG_KEXDH_INIT
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user rhoyerboat service ssh-connection
method password
SSH: Server;Ltype: Authname;Remote: 192.168.1.9-41598;Name: rhoyerboat
debug1: attempt 0 failures 0
debug1: Config token is loglevel
debug1: Config token is permitrootlogin
debug1: Config token is rsaauthentication
debug1: Config token is pubkeyauthentication
debug1: Config token is authorizedkeysfile
debug1: Config token is passwordauthentication
debug1: Config token is usepam
debug1: Config token is printmotd
debug1: Config token is printlastlog
debug1: Config token is subsystem
debug1: PAM: initializing for rhoyerboat
debug1: PAM: setting PAM_RHOST to 192.168.1.9
debug1: PAM: setting PAM_TTY to ssh
Read from socket failed: Connection reset by peer
debug1: do_cleanup
debug1: do_cleanup
debug1: PAM: cleanup
Richard Miller
2012-04-23 20:55:57 UTC
Permalink
Post by andy zerger
Post by Lyndon Nerenberg
Post by Lyndon Nerenberg
I haven't tried genning up a CPU kernel with the new factotum yet.
Sorry, I meant to say "with Richard's patched original factotum."
Patching no longer necessary - it's now in the standard auth/factotum
on sources.
Post by andy zerger
I haven't tried building a new pccpuf kernel yet either, but on
rebooting with factotum and ssh binaries built from from blstuart/ssh
and on miller/factotum I get to "auth Authentication failed"
What authentication methods are permitted in sshd_config on your host?
I find that if I enable only ChallengeResponseAuthentication, passwd
doesn't work, but if I enable PasswordAuthentication it does.
David Leimbach
2012-04-25 12:47:42 UTC
Permalink
Post by Richard Miller
Post by andy zerger
Post by Lyndon Nerenberg
Post by Lyndon Nerenberg
I haven't tried genning up a CPU kernel with the new factotum yet.
Sorry, I meant to say "with Richard's patched original factotum."
Patching no longer necessary - it's now in the standard auth/factotum
on sources.
Sounds like its time spin up a new instance of plan 9
Post by Richard Miller
Post by andy zerger
I haven't tried building a new pccpuf kernel yet either, but on
rebooting with factotum and ssh binaries built from from blstuart/ssh
and on miller/factotum I get to "auth Authentication failed"
What authentication methods are permitted in sshd_config on your host?
I find that if I enable only ChallengeResponseAuthentication, passwd
doesn't work, but if I enable PasswordAuthentication it does.
andy zerger
2012-04-25 15:25:10 UTC
Permalink
Post by Richard Miller
What authentication methods are permitted in sshd_config on your host?
I find that if I enable only ChallengeResponseAuthentication, passwd
doesn't work, but if I enable PasswordAuthentication it does.
Thats what we discovered, gentoo's opensshd installation had passsword auth
method disabled by default

Yaroslav
2012-03-30 10:48:00 UTC
Permalink
contrib/quanstro/root/sys/src/cmd/auth/factotum
Nfactotum misses proto=mschap which is used by cifs(4) for doing NTLM.
Lucio De Re
2012-03-30 11:00:37 UTC
Permalink
Post by Yaroslav
contrib/quanstro/root/sys/src/cmd/auth/factotum
Nfactotum misses proto=mschap which is used by cifs(4) for doing NTLM.
1. Is Nfactotum the back port of factotum from p9p?

2. Any chance that these different branches could be brought together?

I note that the "9p.h" extension is trivial, I see no reason for the
Plan 9 distribution not to include it. But the differences between
factotums are in a league of their own. Now I appreciate the Go
authors aiming to minimise the quantity as well as the impact of
changes.

++L
erik quanstrom
2012-03-30 13:03:28 UTC
Permalink
Post by Lucio De Re
1. Is Nfactotum the back port of factotum from p9p?
2. Any chance that these different branches could be brought together?
no. this is a rewrite.
Post by Lucio De Re
I note that the "9p.h" extension is trivial, I see no reason for the
Plan 9 distribution not to include it. But the differences between
factotums are in a league of their own. Now I appreciate the Go
authors aiming to minimise the quantity as well as the impact of
changes.
the new version of factotum is a different approach. the old factotum
essentially stack-ripped the protocol steps, and was a real pain in the neck.
to work with. there's no fixing it without a rewrite.

so russ i think with input from charles, rewrote factotum so that the
protocols proceed in a single thread.

here are the cavets of the new version to the best of my knowledge
1. there's no vnc authentication. please send a patch, if you'd like
to fix this.

2. old versions of drawterm have broken p9any negotiation. the old
factotum accepted broken negotiation because it was missing some framing.
since it seemed impossible to be bug-for-bug compatabile with broken
framing, it just got fixed. this means old dt clients need updating.

a patch was sent in to russ about 2 years ago for this.

- erik
Charles Forsyth
2012-03-30 14:19:47 UTC
Permalink
Not that I remember: I think we independently rewrote it in a concurrent
style,
in Limbo in my case, a little differently although I studied p9p's when it
was available.
Post by erik quanstrom
so russ i think with input from charles, rewrote factotum so that the
protocols proceed in a single thread.
b***@bellsouth.net
2012-03-30 12:50:26 UTC
Permalink
Post by Yaroslav
contrib/quanstro/root/sys/src/cmd/auth/factotum
Nfactotum misses proto=mschap which is used by cifs(4) for doing NTLM.
Isn't mschap implemented in
contrib/quanstro/root/sys/src/cmd/auth/factotum/chap.c?
There's a Proto structure for it at the bottom of the file.

BLS
Yaroslav
2012-03-30 10:49:28 UTC
Permalink
contrib/blstuart/ssh
It's great! All thumbs up!

Would it be hard to add cooked mode (-C)?
--
- Yaroslav
Yaroslav
2012-03-30 11:17:05 UTC
Permalink
Post by Yaroslav
Would it be hard to add cooked mode (-C)?
never mind: it's easy to simulate by binding /dev/nul over /dev/consctl.
b***@bellsouth.net
2012-03-30 13:01:21 UTC
Permalink
Post by Yaroslav
Post by Yaroslav
Would it be hard to add cooked mode (-C)?
never mind: it's easy to simulate by binding /dev/nul over /dev/consctl.
The other thing I've noticed is that when I'm connecting
from Plan 9 to a UNIX system, running ssh in vt is
handy. It makes all the stuff like readline and color
ls happy, plus there's a cooked/raw menu control
in vt.

But if a cooked mode is something that would useful,
I don't think it would be too hard to add. It would also
be a good thing to add to the ^\ command set.

BLS
erik quanstrom
2012-03-30 12:54:16 UTC
Permalink
Post by Yaroslav
contrib/quanstro/root/sys/src/cmd/auth/factotum
Nfactotum misses proto=mschap which is used by cifs(4) for doing NTLM.
what's the basis for this claim? it might be broken, since we don't use it
much, but it's not missing.

- erik


; cd ofactotum
; g mschap
chap.c:45: uchar secret[16]; /* for mschap */
chap.c:93: s->protoname = "mschap";
chap.c:353: Proto mschap = {
chap.c:354: .name= "mschap",
dat.h:232: extern Proto chap, mschap; /* chap.c */
fs.c:33: &mschap,
; cd ../factotum
; g mschap
chap.c:29: extern Proto chap, mschap;
chap.c:139: }else if(c->proto == &mschap)
chap.c:250: else if(c->proto == &mschap)
chap.c:420: Proto mschap = {
chap.c:421: "mschap",
proto.c:9: extern Proto mschap; /* chap.c */
proto.c:24: &mschap,
erik quanstrom
2012-03-30 13:36:50 UTC
Permalink
contrib/quanstro/root/sys/src/cmd/auth/factotum
contrib/install quanstro/nfactotum. move your old factotum out of the way
first.

- erik
Lucio De Re
2012-03-30 13:59:29 UTC
Permalink
Post by erik quanstrom
contrib/install quanstro/nfactotum. move your old factotum out of the way
first.
Is it safe to use the new factotum as a kernel module? Is it standard
in 9atom?

++L
Lucio De Re
2012-03-30 13:59:36 UTC
Permalink
Post by erik quanstrom
contrib/install quanstro/nfactotum. move your old factotum out of the way
first.
Is it safe to use the new factotum as a kernel module? Is it standard
in 9atom?

++L
erik quanstrom
2012-03-30 14:44:40 UTC
Permalink
Post by Lucio De Re
Post by erik quanstrom
contrib/install quanstro/nfactotum. move your old factotum out of the way
first.
Is it safe to use the new factotum as a kernel module? Is it standard
in 9atom?
if you mean, is it safe to build into /boot, the answers are yes. and yes.

we run this version of factotum on our authentication server.

- erik
Yaroslav
2012-03-30 13:55:29 UTC
Permalink
contrib/quanstro/root/sys/src/cmd/auth/factotum
contrib/install quanstro/nfactotum.  move your old factotum out of the way
first.
here's how one may work out contrib/install conflicts:

% contrib/install quanstro/nfactotum # may report conflicts
% replica/pull -v -s/ /dist/replica/nfactotum # resolves the conflicts
erik quanstrom
2012-04-02 14:29:46 UTC
Permalink
After patching ndb/cs and running nfactotum, I'm still having
some trouble getting the new ssh to successfully login to a
term% ssh2 openbsd
ek=10001 n=DA58E23128A865ABF57DCEEBB31529854F0EFBB0D50ADC5D930F29D7B5592724E9C8A1D74D01140736B72E17EC2F9EFE130AC59BE7F23A4768F748217012B99AA5F508F963D01BE1D939B450F19B1F7CAF6CAA4A5C1AAD817170654045E4981CA380B1975FD87F60BCF38652CAD44CCE13171E0115733E8085BAB151E4C79621AC186D9A51F3B7325FCC5CAC9A64FD5108509D275F93D48AD4B4E8A774C43A07337135D82A01DA529CCEB6107913A20CD4D576BB9FB2C85E0233E9745BE6092A0E1EAAA5596DF2166B0B0A9845F51AF1121613DE9AB241C00416E9C2B39B1C0394A914C5414D838CE8FF4D62170774E0707CC628E495E210F4 30BA465BF9B2A7
Add this key? (yes, no, session) yes
ssh2: dial: handshake failed
term% ssh2 -d openbsd
Key verification dialog failed
ssh2: dial: handshake failed
term% ssh2 -d -k openbsd
Key verification dialog failed
ssh2: dial: handshake failed
we're working on it.

- erik
erik quanstrom
2012-04-02 14:39:11 UTC
Permalink
Post by erik quanstrom
After patching ndb/cs and running nfactotum, I'm still having
some trouble getting the new ssh to successfully login to a
[...]
Post by erik quanstrom
we're working on it.
i should say this works for me, and nearly everybody, but we
have seen one similar case. but everyone else on the system
has success.

so the current thinking is tht there's something in the environment
that's broken. in fact, i'd recommend moving your keyrings and
other files accessed by ssh or the tunnel out of the way and trying
again.

thanks!

- erik
s***@9front.org
2012-04-02 14:27:21 UTC
Permalink
After patching ndb/cs and running nfactotum, I'm still having
some trouble getting the new ssh to successfully login to a
remote system:

term% ssh2 openbsd
The following key has been offered by the server:
ek=10001 n=DA58E23128A865ABF57DCEEBB31529854F0EFBB0D50ADC5D930F29D7B5592724E9C8A1D74D01140736B72E17EC2F9EFE130AC59BE7F23A4768F748217012B99AA5F508F963D01BE1D939B450F19B1F7CAF6CAA4A5C1AAD817170654045E4981CA380B1975FD87F60BCF38652CAD44CCE13171E0115733E8085BAB151E4C79621AC186D9A51F3B7325FCC5CAC9A64FD5108509D275F93D48AD4B4E8A774C43A07337135D82A01DA529CCEB6107913A20CD4D576BB9FB2C85E0233E9745BE6092A0E1EAAA5596DF2166B0B0A9845F51AF1121613DE9AB241C00416E9C2B39B1C0394A914C5414D838CE8FF4D62170774E0707CC628E495E210F430 BA465BF9B2A7

Add this key? (yes, no, session) yes
ssh2: dial: handshake failed
term% ssh2 -d openbsd
Key verification dialog failed
ssh2: dial: handshake failed
term% ssh2 -d -k openbsd
Key verification dialog failed
ssh2: dial: handshake failed

term% ssh2 osx
The following key has been offered by the server:
ek=23 n=C2787370C86F65343730ECC3CE8B58B789A652BDC64982CDA51E780801C545C8B1C1DA108DE8B938032C7AB9A1DB23225128BD1A30ED13AB9240CD0EA07C9EF12B7064F5C8902671F16638C5188CABF5BE3C5F4C5AB8E63C9EAF7FEFC23A0F3CCBDCD6295133444352BE730302BC8B3ACB08573312D6B7F3605C1104EFBC88EC404631B55FE430527474BC6A8A0227B1D8CE1AE3244280345D178E2F746883550E017D4B1C7D373950346622E0D1C722262CE62C8396A0EBAD7B799565FCFDCFE33B42DCB7EB1794C693E36081E4124EFF725D5859FB82217B1C2C3B83D88A07A9709E1E32AEA101A83CB0F35B9FDBAA86E80254AA5CE158EC792F2 6558A9C59

Add this key? (yes, no, session) yes
ssh2: dial: handshake failed
term% ssh2 -d osx
Key verification dialog failed
ssh2: dial: handshake failed
term% ssh2 -d -k osx
Key verification dialog failed
ssh2: dial: handshake failed


In both cases, the key for the remote system is
successfully saved in $home/lib/keyring.

-sl
Brian L. Stuart
2012-04-02 16:12:36 UTC
Permalink
After patching ndb/cs and running
nfactotum, I'm still having
some trouble getting the new ssh to successfully login to a
term% ssh2 openbsd
ek=10001
...
Add this key? (yes, no, session) yes
ssh2: dial: handshake failed
Unfortunately, the handshake failed error is something of
a catch-all when something fails in the early negotiation
to set up the connection. To narrow in on what's happening,
could you first kill all instances of sshtun that are running.
Then run a fresh instance of auth/factotum and don't load
anything from secstore. Then try ssh again. If it still
doesn't work, kill sshtun again, and run it manually with
a -d option, then run ssh. You should get quite a lot of
output to stderr and that will hopefully give us some clue
as to what's happening.

BLS
s***@9front.org
2012-04-02 16:32:25 UTC
Permalink
After rebuilding nfactotum and starting it in a fresh window,
I'm able to login to all of the previously tried remote hosts.

-sl
s***@9front.org
2012-04-02 16:53:07 UTC
Permalink
Post by s***@9front.org
After rebuilding nfactotum and starting it in a fresh window,
I'm able to login to all of the previously tried remote hosts.
It seems to be failing only when factotum is already populated with
keys (I should point out: keys unrelated to the hosts I'm trying to
login to with the new ssh):

term% sshtun -d

term% ssh2 openbsd
Got destroy fid on file: 0 0 0 0: ssh
new connection: 0
id string: 21:SSH-2.0-OpenSSH_6.0
Initializing kexinit packet
Sent KEX algs: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
Sent host key algs: ssh-rsa,ssh-dss
Sent crypto algs: aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc,arcfour
Sent MAC algs: hmac-sha1
Starting reader for connection 0, pid:8
calling read for connection 0, state 2, nb 4, dc -1
Got message length: 980
got message of 984 bytes 9 padding: first byte: 20
Using diffie-hellman-group1-sha1 Kex algorithm and ssh-rsa PKA
calling read for connection 0, state 5, nb 4, dc -1
Got message length: 700
got message of 704 bytes 8 padding: first byte: 31
Verifying server signature
In rsa_verify for connection: 0
got error in factotum: unknown role verify
Key verification dialog failed
Shutting down connection 0
clone 2 ctl 3 data 2 listen 2 local 2 remote 2 status 2
Done processing shutdown of connection 0
Got destroy fid on file: 18000 0 0 0: keys
Got destroy fid on file: 28000 1 0 0: ctl
ssh2: dial: handshake failed

term% ssh2 osx
Got destroy fid on file: 0 0 0 0: ssh
new connection: 1
id string: 21:SSH-2.0-OpenSSH_5.2
Initializing kexinit packet
Sent KEX algs: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
Sent host key algs: ssh-rsa,ssh-dss
Sent crypto algs: aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc,arcfour
Sent MAC algs: hmac-sha1
Starting reader for connection 1, pid:15
calling read for connection 1, state 2, nb 4, dc -1
Got message length: 780
got message of 784 bytes 10 padding: first byte: 20
Using diffie-hellman-group1-sha1 Kex algorithm and ssh-rsa PKA
calling read for connection 1, state 5, nb 4, dc -1
Got message length: 700
got message of 704 bytes 10 padding: first byte: 31
Verifying server signature
In rsa_verify for connection: 1
got error in factotum: unknown role verify
Key verification dialog failed
Shutting down connection 1
clone 2 ctl 3 data 2 listen 2 local 2 remote 2 status 2
Done processing shutdown of connection 1
Got destroy fid on file: 18000 0 0 0: keys
Got destroy fid on file: 28080 1 1 0: ctl
ssh2: dial: handshake failed

-sl
Brian L. Stuart
2012-04-02 17:21:14 UTC
Permalink
Post by s***@9front.org
It seems to be failing only when factotum is already
populated with
keys (I should point out: keys unrelated to the hosts I'm
trying to
term% sshtun -d
term% ssh2 openbsd
Verifying server signature
In rsa_verify for connection: 0
got error in factotum: unknown role verify
Key verification dialog failed
Shutting down connection 0
While it is possible to get it confused with keys already
stored in factotum (the reason the -z option is there), in
this particular case, the "unknown role verify" from factotum
seems to suggest it's talking to the old factotum.

BLS
s***@9front.org
2012-04-02 17:57:40 UTC
Permalink
Post by Brian L. Stuart
While it is possible to get it confused with keys already
stored in factotum (the reason the -z option is there), in
this particular case, the "unknown role verify" from factotum
seems to suggest it's talking to the old factotum.
You're right.

I forgot that 9front starts a factotum that was rolled into the
kernel build, quite separate from the userland auth/factotum that
exists on the system. This at least makes the observed results
sensible. The running kernel was not built with nfactotum, while
I as launching nfactotum manually from the command line.

But now that I experiment, I find that I have a problem with nfactotum:

term% auth/factotum -D
<-5- Tversion tag 65535 msize 8216 version '9P2000'
-5-> Rversion tag 65535 msize 8216 version '9P2000'
<-5- Tauth tag 42 afid 706 uname sl aname
-5-> Rerror tag 42 ename auth/factotum: authentication not required
<-5- Tattach tag 42 fid 706 afid -1 uname sl aname
-5-> Rattach tag 42 qid (0000000000000000 0 d)

term% cpu -h sp -u sl
<-5- Twalk tag 42 fid 706 newfid 837 nwname 2 0:factotum 1:rpc
-5-> Rwalk tag 42 nwqid 2 0:(0000000000000001 0 d) 1:(0000000000000002 0 )
<-5- Topen tag 42 fid 837 mode 2
fid mode is 0x2
-5-> Ropen tag 42 qid (0000000000000002 0 ) iounit 0
<-5- Twrite tag 42 fid 837 offset 0 count 38 'start proto=p9any role=client user=sl'
-5-> Rwrite tag 42 count 38
<-5- Tread tag 42 fid 837 offset 38 count 4096
-5-> Rread tag 42 count 2 'ok'
<-5- Twrite tag 42 fid 837 offset 40 count 5 'read '
-5-> Rwrite tag 42 count 5
<-5- Tread tag 42 fid 837 offset 45 count 4096
-5-> Rread tag 42 count 40 'phase in state 'read offer' want 'write''
<-5- Twrite tag 42 fid 837 offset 85 count 6 'write '
-5-> Rwrite tag 42 count 6
<-5- Tread tag 42 fid 837 offset 91 count 4096
-5-> Rread tag 42 count 13 'toosmall 4096'
<-5- Twrite tag 42 fid 837 offset 104 count 15 '77726974 65207039 736b3140 6e7600'
-5-> Rwrite tag 42 count 15
<-5- Tread tag 42 fid 837 offset 119 count 4096
-5-> Rread tag 42 count 2 'ok'
<-5- Twrite tag 42 fid 837 offset 121 count 5 'read '
-5-> Rwrite tag 42 count 5
<-5- Tread tag 42 fid 837 offset 126 count 4096
-5-> Rread tag 42 count 57 'needkey user=sl role=client proto=p9sk1 dom=nv !password?'

!Adding key: user=sl role=client proto=p9sk1 dom=nv
password:
!
<-5- Twalk tag 42 fid 706 newfid 850 nwname 2 0:factotum 1:ctl
-5-> Rwalk tag 42 nwqid 2 0:(0000000000000001 0 d) 1:(0000000000000007 0 )
<-5- Topen tag 42 fid 850 mode 2
fid mode is 0x2
-5-> Ropen tag 42 qid (0000000000000007 0 ) iounit 0
<-5- Twrite tag 42 fid 850 offset 0 count 64 'key user=sl role=client proto=p9sk1 dom=nv !password=xxxxxxx
'
-5-> Rwrite tag 42 count 64
<-5- Tread tag 42 fid 850 offset 64 count 1024
-5-> Rread tag 42 count 54 'key dom=nv proto=p9sk1 role=client user=sl !password?
'
<-5- Tclunk tag 42 fid 850
-5-> Rclunk tag 42
<-5- Twrite tag 42 fid 837 offset 183 count 5 'read '
-5-> Rwrite tag 42 count 5
<-5- Tread tag 42 fid 837 offset 188 count 4096
-5-> Rread tag 42 count 12 '6f6b2070 39736b31 206e7600'
<-5- Twrite tag 42 fid 837 offset 200 count 5 'read '
-5-> Rwrite tag 42 count 5
<-5- Tread tag 42 fid 837 offset 205 count 4096
-5-> Rread tag 42 count 11 '6f6b2098 10cb0d4c 932e7a'
<-5- Twrite tag 42 fid 837 offset 216 count 5 'read '
-5-> Rwrite tag 42 count 5
<-5- Tread tag 42 fid 837 offset 221 count 4096
-5-> Rread tag 42 count 42 'phase in state 'read tickreq' want 'write''
<-5- Twrite tag 42 fid 837 offset 263 count 6 'write '
-5-> Rwrite tag 42 count 6
<-5- Tread tag 42 fid 837 offset 269 count 4096
-5-> Rread tag 42 count 12 'toosmall 141'
<-5- Twrite tag 42 fid 837 offset 281 count 147 '77726974 65200167 6c656e64 61000000 00000000 00000000 00000000 00000000 0000006e 76000000 00000000 00000000 00000000 00000000 00000000 00000000'
-5-> Rwrite tag 42 count 147
<-5- Tread tag 42 fid 837 offset 428 count 4096
-5-> Rread tag 42 count 2 'ok'
<-5- Twrite tag 42 fid 837 offset 430 count 5 'read '
auth/factotum: ioproc alloc

At this point the nfactotum proc blocks indefinitely in Pread.

-sl
c***@gmx.de
2012-04-02 19:52:31 UTC
Permalink
can reproduce it here. the problem is 9fronts implementaiton
of ioprocs. instead of posting notes, we added a "interrupt" and
"nointerrupt" ctl messages to /proc/n/ctl that interrupts without
posting a note.

the problem was that notes could be scheduled before we even did
the syscall making them unreliable.

this mechanism simplified the ioproc implementation quite a lot,
but relied on the fact that one can open /proc/n/ctl of the
ioproc().

this breaks because nfactotum makes its ctl file readonly so it
can't be killed.

fortunately, it doesnt use iointerrupt() at all so we could just
ignore the failing open of /proc/n/ctl in the case of factotum.

--
cinap
Brian L. Stuart
2012-04-02 16:56:04 UTC
Permalink
Post by s***@9front.org
After rebuilding nfactotum and
starting it in a fresh window,
I'm able to login to all of the previously tried remote
hosts.
For the reference of future search engines I have a guess
on what you might have been seeing. If in the original
window, you had attempted to run ssh with an instance of
the older factotum bound to /mnt/factotum, then the tunnel
that got started would be running with that one. Because
the tunnel is persistent, running a new factotum wouldn't
have affected the existing tunnel. Opening a new window
created a new name space where the tunnel wasn't bound to
/net, so ssh started a new one, and this time the new
factotum was bound to /mnt/factotum so the tunnel is using
it.

BLS
Brian L. Stuart
2012-04-02 16:27:10 UTC
Permalink
Add this key? (yes, no, session) yes
ssh2: dial: handshake failed
One other thing that might be instructive is to look
at the logs. The client side logs will be in /sys/log/ssh
and the server's are often in something like /var/log.
They might have something that will help us pinpoint
where it's getting unhappy.

BLS
s***@9front.org
2012-04-02 16:33:40 UTC
Permalink
Post by Brian L. Stuart
The client side logs will be in /sys/log/ssh
This was not created on my system.

-sl
Brian L. Stuart
2012-04-02 16:44:17 UTC
Permalink
Post by Brian L. Stuart
Post by Brian L. Stuart
The client side logs will be in
/sys/log/ssh
This was not created on my system.
My bad. He only uses syslog when he's in the role
of server, not client.

BLS
andy zerger
2012-04-23 01:11:57 UTC
Permalink
Post by Lyndon Nerenberg
Post by Lyndon Nerenberg
I haven't tried genning up a CPU kernel with the new factotum yet.
Sorry, I meant to say "with Richard's patched original factotum."
(if there is a double-post in play or in an individuals mailbox pardon me,
i tried using comp.os.plan9 on the web and I am not sure where "reply" sent
the message")


I haven't tried building a new pccpuf kernel yet either, but on rebooting
with factotum and ssh binaries built from from blstuart/ssh and on
miller/factotum I get to "auth Authentication failed"

I think I might have something configured wrong, and not a bug, so please
look? any thoughts/suggestions/other debugging tools?

Here is some output from acid -l truss on my plan9 client, and the sshd -d
logs from my gentoo sshd host


/*acid -l truss /bin/ssh */
acid: new()
acid: truss()
fd2path(0, 0xdfffdeb0, 64)
return value: 0
data: "/dev/cons"
brk_(0x0000fd60)
return value: 0
stat("/net/ssh", 0x0000ede4, 115)
return value: -1
rfork(0x00000038)
return value: 7629
await(0xdfffdcec, 511, 511)
return value: 38
data: "7629 0 10 10 'sshtun 7629: threadmain'"
rfork(0x00000074)
return value: 7632
notify(0x0000405c)
return value: 0
open("/net/cs", 2)
return value: 4
pwrite(4, "ssh!192.168.1.10!22", 19, 4294967295)
return value: 19
seek(0x0000e754, 4, 0, 0)
return value: 0
pread(4, 0xdfffdcb0, 127, 4294967295)
return value: 30
data: "/net/ssh/clone 192.168.1.10!22"
open("/net/ssh/clone", 2)
return value: 7
pread(7, 0xdfffd880, 255, 4294967295)
return value: 1
data: "0"
pwrite(7, "connect 192.168.1.10!22", 23, 4294967295)
return value: 23
open("/net/ssh/0/data", 2)
return value: 10
close(4)
return value: 0
errstr(0xdfffda08, 128, 128)
return value: 0
data: "'/net/ssh' dns: file does not exist"
seek(0x0000e754, 7, 0, 0)
return value: 0
pread(7, 0xdfffdf1c, 10, 4294967295)
return value: 1
data: "0"
open("/dev/cons", 2)
return value: 4
open("/dev/consctl", 1)
return value: 11
pwrite(11, "rawon", 5, 4294967295)
return value: 5
pwrite(7, "ssh-userauth K rhoyerboat", 18, 4294967295)
return value: -1
open("/mnt/factotum/rpc", 2)
return value: 12
brk_(0x00011de8)
return value: 0
pwrite(12, "start proto=pass service=ssh server=192.168.1.10
user=rhoyerboat", 57, 4294967295)
return value: 57
pread(12, 0x0000ed6c, 4096, 4294967295)
return value: 2
data: "ok"
pwrite(12, "read ", 5, 4294967295)
return value: 5
pread(12, 0x0000ed6c, 4096, 4294967295)
return value: 21
data: "ok rhoyerboat XXXX12345"
close(12)
return value: 0
pwrite(7, "ssh-userauth k rhoyerboat XXXX12345", 33, 4294967295)
return value: -1
errstr(0xdfffdbe0, 128, 128)
return value: 0
data: "Authentication failed"
errstr(0xdfffdbe0, 128, 128)
return value: 0
data: "(null)"
pwrite(2, "auth Authentication failed
", 27, 4294967295)
auth Authentication failed
return value: 27
pwrite(11, "rawoff", 6, 4294967295)
return value: 6
close(11)
return value: 0
close(4)
return value: 0
pwrite(0, "close", 5, 4294967295)
return value: -1
close(0)
return value: 0
close(0)
return value: -1
close(10)
return value: 0
close(0)
return value: -1
close(7)
return value: 0
pwrite(0, "kill", 4, 4294967295)
return value: -1
close(0)
return value: -1
open("#c/pid", 0)
return value: 0
pread(0, 0xdfffdec0, 20, 4294967295)
return value: 12
data: " 7628 "
close(0)
return value: 0
7628: breakpoint _exits+0x5 INTB $0x40


/* sshd -d logs */

Connection from 192.168.1.9 port 41598
debug1: HPN Disabled: 0, HPN Buffer Size: 87380
debug1: Client protocol version 2.0; client software version Plan9
SSH: Server;Ltype: Version;Remote: 192.168.1.9-41598;Protocol: 2.0;Client:
Plan9
debug1: no match: Plan9
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v10
debug1: permanently_set_uid: 22/22
debug1: MYFLAG IS 1
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-cbc'
debug1: kex: client->server aes128-cbc hmac-sha1 none
SSH: Server;Ltype: Kex;Remote: 192.168.1.9-41598;Enc: aes128-cbc;MAC:
hmac-sha1;Comp: none
debug1: REQUESTED ENC.NAME is 'aes128-cbc'
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: expecting SSH2_MSG_KEXDH_INIT
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user rhoyerboat service ssh-connection method
password
SSH: Server;Ltype: Authname;Remote: 192.168.1.9-41598;Name: rhoyerboat
debug1: attempt 0 failures 0
debug1: Config token is loglevel
debug1: Config token is permitrootlogin
debug1: Config token is rsaauthentication
debug1: Config token is pubkeyauthentication
debug1: Config token is authorizedkeysfile
debug1: Config token is passwordauthentication
debug1: Config token is usepam
debug1: Config token is printmotd
debug1: Config token is printlastlog
debug1: Config token is subsystem
debug1: PAM: initializing for rhoyerboat
debug1: PAM: setting PAM_RHOST to 192.168.1.9
debug1: PAM: setting PAM_TTY to ssh
Read from socket failed: Connection reset by peer
debug1: do_cleanup
debug1: do_cleanup
debug1: PAM: cleanup
Post by Lyndon Nerenberg
Thanks to the support of Coraid, I am pleased to announce
that a native SSHv2 implementation is now available in
contrib/blstuart/ssh
contrib/quanstro/root/sys/src/cmd/auth/factotum
Although not strictly necessary it's also helpful to add ssh
{ "ssh", iplookup, iptrans, 1 },
There's a man page that will hopefully help to get anyone
started who wants to play with it.
No doubt, there are still some rough edges. But we've been
using it at Coraid for a while now so at least a few of the
rough edges should be polished. Also there are some parts
of the code that are a little ugly, and I plan to clean them up.
But lest it live in a perpetual state of "just one more thing I
need to clean up" here it is.
Good luck and enjoy,
BLS
Loading...