[9fans] SSHv2

[9fans] SSHv2

[blstuart]

Thanks to the support of Coraid, I am pleased to announce
that a native SSHv2 implementation is now available in
contrib.  It's available in:

contrib/blstuart/ssh

You'll also need the backported p9p factotum in:

contrib/quanstro/root/sys/src/cmd/auth/factotum

Although not strictly necessary it's also helpful to add ssh
to the protocols cs understands:

	{ "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

Re: [9fans] SSHv2

[cinap_lenrek]

congratulations! :)

--
cinap

Re: [9fans] SSHv2

[Bruce Ellis]

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

On 30 March 2012 12:26,  <cinap_lenrek@gmx.de> wrote:
> congratulations! :)
>
> --
> cinap
>

--
Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)

Re: [9fans] SSHv2

[andrey mirtchovski]

you rule!

Re: [9fans] SSHv2

[Lucio De Re]

> 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.

Re: [9fans] SSHv2

[Lucio De Re]

> You'll also need the backported p9p factotum in:
>
> 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

Re: [9fans] SSHv2

[David du Colombier]

> 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

Re: [9fans] SSHv2

[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):

Thanks, David, that seems to have worked so far.

++L

Re: [9fans] SSHv2

[erik quanstrom]

On Fri Mar 30 02:08:59 EDT 2012, 0intro@gmail.com wrote:
> > 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):
>
[...]

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

Re: [9fans] SSHv2

[Jeff Sickel]

Excellent news.


On Mar 29, 2012, at 9:10 PM, blstuart@bellsouth.net wrote:

> You'll also need the backported p9p factotum in:
>
> contrib/quanstro/root/sys/src/cmd/auth/factotum
>

small hint, you'll need to backport 9p.h to build this factotum

-jas

Re: [9fans] SSHv2

[steve]

superb!


On 30 Mar 2012, at 03:10 AM, blstuart@bellsouth.net wrote:

> Thanks to the support of Coraid, I am pleased to announce
> that a native SSHv2 implementation is now available in
> contrib.  It's available in:
>
> contrib/blstuart/ssh
>
> You'll also need the backported p9p factotum in:
>
> contrib/quanstro/root/sys/src/cmd/auth/factotum
>
> Although not strictly necessary it's also helpful to add ssh
> to the protocols cs understands:
>
>    { "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
>

Re: [9fans] SSHv2

[Richard Miller]

> You'll also need the backported p9p factotum in:
>
> 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?

Re: [9fans] SSHv2

[Yaroslav]

> 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.

Re: [9fans] SSHv2

[blstuart]

>> You'll also need the backported p9p factotum in:
>>
>> 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

Re: [9fans] SSHv2

[erik quanstrom]

On Fri Mar 30 08:50:23 EDT 2012, blstuart@bellsouth.net wrote:
> >> You'll also need the backported p9p factotum in:
> >>
> >> 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

Re: [9fans] SSHv2

[Richard Miller]

> 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?

Re: [9fans] SSHv2

[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.

Re: [9fans] SSHv2

[Lyndon Nerenberg]

On 2012-04-02, at 1:08 PM, Richard Miller wrote:

> 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 ... ?

Re: [9fans] SSHv2

[Lyndon Nerenberg]

On 2012-04-02, at 7:27 PM, Lyndon Nerenberg wrote:

> 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."

Re: [9fans] SSHv2

[rhoyerboat]

On Apr 2, 8:31 pm, lyn...@orthanc.ca (Lyndon Nerenberg) wrote:
> On 2012-04-02, at 7:27 PM, Lyndon Nerenberg wrote:
>
> > 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

Re: [9fans] SSHv2

[Richard Miller]

>> > 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.

> 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.

Re: [9fans] SSHv2

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Monday, April 23, 2012, Richard Miller <9fans@hamnavoe.com> wrote:

> >> > 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


> > 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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1252 bytes --]

Re: [9fans] SSHv2

[andy zerger]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

>
>> 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

[-- Attachment #2: Type: text/html, Size: 705 bytes --]

Re: [9fans] SSHv2

[Yaroslav]

> contrib/quanstro/root/sys/src/cmd/auth/factotum

Nfactotum misses proto=mschap which is used by cifs(4) for doing NTLM.

Re: [9fans] SSHv2

[Lucio De Re]

>> 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

Re: [9fans] SSHv2

[erik quanstrom]

> 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.

> 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

Re: [9fans] SSHv2

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

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.

On 30 March 2012 14:03, erik quanstrom <quanstro@quanstro.net> wrote:

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

[-- Attachment #2: Type: text/html, Size: 622 bytes --]

Re: [9fans] SSHv2

[blstuart]

>> 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

Re: [9fans] SSHv2

[Yaroslav]

> contrib/blstuart/ssh

It's great! All thumbs up!

Would it be hard to add cooked mode (-C)?

--
- Yaroslav

Re: [9fans] SSHv2

[Yaroslav]

> Would it be hard to add cooked mode (-C)?

never mind: it's easy to simulate by binding /dev/nul over /dev/consctl.

Re: [9fans] SSHv2

[blstuart]

>> 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

Re: [9fans] SSHv2

[erik quanstrom]

On Fri Mar 30 06:48:39 EDT 2012, yarikos@gmail.com wrote:
> > 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,

Re: [9fans] SSHv2

[erik quanstrom]

> contrib/quanstro/root/sys/src/cmd/auth/factotum

contrib/install quanstro/nfactotum.  move your old factotum out of the way
first.

- erik

Re: [9fans] SSHv2

[Yaroslav]

2012/3/30 erik quanstrom <quanstro@quanstro.net>:
>> 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

Re: [9fans] SSHv2

[Lucio De Re]

> 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

Re: [9fans] SSHv2

[Lucio De Re]

> 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

Re: [9fans] SSHv2

[erik quanstrom]

On Fri Mar 30 09:56:24 EDT 2012, lucio@proxima.alt.za wrote:
> > 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

Re: [9fans] SSHv2

[sl]

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=DA58E23128A865ABF57DCEEBB31529854F0EFBB0D50ADC5D930F29D7B5592724E9C8A1D74D01140736B72E17EC2F9EFE130AC59BE7F23A4768F748217012B99AA5F508F963D01BE1D939B450F19B1F7CAF6CAA4A5C1AAD817170654045E4981CA380B1975FD87F60BCF38652CAD44CCE13171E0115733E8085BAB151E4C79621AC186D9A51F3B7325FCC5CAC9A64FD5108509D275F93D48AD4B4E8A774C43A07337135D82A01DA529CCEB6107913A20CD4D576BB9FB2C85E0233E9745BE6092A0E1EAAA5596DF2166B0B0A9845F51AF1121613DE9AB241C00416E9C2B39B1C0394A914C5414D838CE8FF4D62170774E0707CC628E495E210F430BA465BF9B2A7

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=C2787370C86F65343730ECC3CE8B58B789A652BDC64982CDA51E780801C545C8B1C1DA108DE8B938032C7AB9A1DB23225128BD1A30ED13AB9240CD0EA07C9EF12B7064F5C8902671F16638C5188CABF5BE3C5F4C5AB8E63C9EAF7FEFC23A0F3CCBDCD6295133444352BE730302BC8B3ACB08573312D6B7F3605C1104EFBC88EC404631B55FE430527474BC6A8A0227B1D8CE1AE3244280345D178E2F746883550E017D4B1C7D373950346622E0D1C722262CE62C8396A0EBAD7B799565FCFDCFE33B42DCB7EB1794C693E36081E4124EFF725D5859FB82217B1C2C3B83D88A07A9709E1E32AEA101A83CB0F35B9FDBAA86E80254AA5CE158EC792F26558A9C59

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

Re: [9fans] SSHv2

[erik quanstrom]

On Mon Apr  2 10:28:28 EDT 2012, sl@9front.org wrote:
> 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=DA58E23128A865ABF57DCEEBB31529854F0EFBB0D50ADC5D930F29D7B5592724E9C8A1D74D01140736B72E17EC2F9EFE130AC59BE7F23A4768F748217012B99AA5F508F963D01BE1D939B450F19B1F7CAF6CAA4A5C1AAD817170654045E4981CA380B1975FD87F60BCF38652CAD44CCE13171E0115733E8085BAB151E4C79621AC186D9A51F3B7325FCC5CAC9A64FD5108509D275F93D48AD4B4E8A774C43A07337135D82A01DA529CCEB6107913A20CD4D576BB9FB2C85E0233E9745BE6092A0E1EAAA5596DF2166B0B0A9845F51AF1121613DE9AB241C00416E9C2B39B1C0394A914C5414D838CE8FF4D62170774E0707CC628E495E210F430BA465BF9B2A7
>
> 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

Re: [9fans] SSHv2

[erik quanstrom]

On Mon Apr  2 10:30:50 EDT 2012, quanstro@quanstro.net wrote:
> On Mon Apr  2 10:28:28 EDT 2012, sl@9front.org wrote:
> > After patching ndb/cs and running nfactotum, I'm still having
> > some trouble getting the new ssh to successfully login to a
> > remote system:
[...]
>
> 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

Re: [9fans] SSHv2

[Brian L. Stuart]

> 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
> ...
>
> 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

Re: [9fans] SSHv2

[sl]

After rebuilding nfactotum and starting it in a fresh window,
I'm able to login to all of the previously tried remote hosts.

-sl

Re: [9fans] SSHv2

[sl]

> 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

Re: [9fans] SSHv2

[Brian L. Stuart]

> 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
> 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

Re: [9fans] SSHv2

[sl]

> 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

Re: [9fans] SSHv2

[cinap_lenrek]

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

Re: [9fans] SSHv2

[Brian L. Stuart]

> 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

Re: [9fans] SSHv2

[Brian L. Stuart]

> 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

Re: [9fans] SSHv2

[sl]

> The client side logs will be in /sys/log/ssh

This was not created on my system.

-sl

Re: [9fans] SSHv2

[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

Re: [9fans] SSHv2

[andy zerger]

[-- Attachment #1: Type: text/plain, Size: 6712 bytes --]

On Apr 2, 8:31 pm, lyn...@orthanc.ca (Lyndon Nerenberg) wrote:
> On 2012-04-02, at 7:27 PM, Lyndon Nerenberg wrote:
>
> > 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

On Thu, Mar 29, 2012 at 8:10 PM, <blstuart@bellsouth.net> wrote:

> Thanks to the support of Coraid, I am pleased to announce
> that a native SSHv2 implementation is now available in
> contrib.  It's available in:
>
> contrib/blstuart/ssh
>
> You'll also need the backported p9p factotum in:
>
> contrib/quanstro/root/sys/src/cmd/auth/factotum
>
> Although not strictly necessary it's also helpful to add ssh
> to the protocols cs understands:
>
>        { "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
>
>
>

[-- Attachment #2: Type: text/html, Size: 8093 bytes --]