Re: [9fans] SSHv2
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
On Monday, April 23, 2012, Richard Miller 9f...@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.
Re: [9fans] SSHv2
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
Re: [9fans] SSHv2
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_(0xfd60) return value: 0 stat(/net/ssh, 0xede4, 115) return value: -1 rfork(0x0038) return value: 7629 await(0xdfffdcec, 511, 511) return value: 38 data: 7629 0 10 10 'sshtun 7629: threadmain' rfork(0x0074) return value: 7632 notify(0x405c) return value: 0 open(/net/cs, 2) return value: 4 pwrite(4, ssh!192.168.1.10!22, 19, 4294967295) return value: 19 seek(0xe754, 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(0xe754, 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, 0xed6c, 4096, 4294967295) return value: 2 data: ok pwrite(12, read , 5, 4294967295) return value: 5 pread(12, 0xed6c, 4096, 4294967295) return value: 21 data: ok rhoyerboat 12345 close(12) return value: 0 pwrite(7, ssh-userauth k rhoyerboat 12345, 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
Re: [9fans] SSHv2
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_(0xfd60) return value: 0 stat(/net/ssh, 0xede4, 115) return value: -1 rfork(0x0038) return value: 7629 await(0xdfffdcec, 511, 511) return value: 38 data: 7629 0 10 10 'sshtun 7629: threadmain' rfork(0x0074) return value: 7632 notify(0x405c) return value: 0 open(/net/cs, 2) return value: 4 pwrite(4, ssh!192.168.1.10!22, 19, 4294967295) return value: 19 seek(0xe754, 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(0xe754, 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, 0xed6c, 4096, 4294967295) return value: 2 data: ok pwrite(12, read , 5, 4294967295) return value: 5 pread(12, 0xed6c, 4096, 4294967295) return value: 21 data: ok rhoyerboat 12345 close(12) return value: 0 pwrite(7, ssh-userauth k rhoyerboat 12345, 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+0x5INTB$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
Re: [9fans] SSHv2 and scp
Makes me want fire my guru plug back up since i'm experimenting on all the x86 machines i have (between nix and some disk work, they're all busy), i've been using my openrd as a terminal again. it's already irritatingly slow. (and don't even think of using gs.) it gets pounded by an intel atom. isn't the guru clocked at just 2/3rds that of the openrd? ouch! - erik
Re: [9fans] SSHv2 and scp
I have fixed various bugs in ssh2; they'll be in the ssh2 on sources once it's all shaken down. Wow! ++L
Re: [9fans] SSHv2 and scp
On Tuesday, April 3, 2012, Lucio De Re wrote: I have fixed various bugs in ssh2; they'll be in the ssh2 on sources once it's all shaken down. Wow! ++L Makes me want fire my guru plug back up
Re: [9fans] SSHv2 and scp
Makes me want fire my guru plug back up My sheevaplug (does that put me in a lower or higher caste?) is waiting for somebody to write me a Go runtime preamble (actually, just help me along with a few hints that will make it possible for me to write it - last I looked at the Linux/Arm stuff, I got such a fright, I thought the Arm was a hopeless case; I have recovered a little from the fright, but my faith is still badly shaken!) and for something Plan 9-ish that escapes me right now. I look forlornly at the plug on my desk, it is still so much of a novelty to me. And it does work! My Android phone is much more of a disappointment, but then it ought to be a Plan 9 phone, oughtn't it? ++L
Re: [9fans] SSHv2
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
On Mon Apr 2 10:28:28 EDT 2012, s...@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
On Mon Apr 2 10:30:50 EDT 2012, quans...@quanstro.net wrote: On Mon Apr 2 10:28:28 EDT 2012, s...@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
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
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
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
The client side logs will be in /sys/log/ssh This was not created on my system. -sl
Re: [9fans] SSHv2
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
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
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
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
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 ( 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:(0001 0 d) 1:(0002 0 )
-5- Topen tag 42 fid 837 mode 2
fid mode is 0x2
-5- Ropen tag 42 qid (0002 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:(0001 0 d) 1:(0007 0 )
-5- Topen tag 42 fid 850 mode 2
fid mode is 0x2
-5- Ropen tag 42 qid (0007 0 ) iounit 0
-5- Twrite tag 42 fid 850 offset 0 count 64 'key user=sl role=client
proto=p9sk1 dom=nv !password=xxx
'
-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
6100 006e 7600
'
-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
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
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
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
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.
[9fans] SSHv2 and scp
scp seems a bit unhappy with the new ssh as well. Single file copies work in both directions, and copying multiple files to plan9 works, but copying multiple files from plan9 to remote unix systems barfs: : lyndon@gandalf:/sys/src/cmd/unix/u9fs; lc LICENSE convM2S.c fcall.h print.c strecpy.c utfrune.c authnone.c convS2M.c fcallconv.c random.csun-inttypes.h authp9any.c cygwin.cmakefilereadn.c tokenize.c authrhosts.cdes.c oldfcall.c remotehost.c u9fs.c convD2M.c dirmodeconv.c oldfcall.h rune.c u9fs.h convM2D.c doprint.c plan9.h safecpy.c u9fsauth.h : lyndon@gandalf:/sys/src/cmd/unix/u9fs; scp -v * legolas:src/u9fs gandalf: remote destination: send LICENSE to legolas:src/u9fs gandalf: remotessh: legolas: scp -d -v -t src/u9fs scp: unexpected response character 0x75 Connection closed by server usage: scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] : lyndon@gandalf:/sys/src/cmd/unix/u9fs; EOF on client side scp -v * treebeard:src/u9fs gandalf: remote destination: send LICENSE to treebeard:src/u9fs gandalf: remotessh: treebeard: scp -d -v -t src/u9fs scp: unexpected response character 0x55 Connection closed by server Usage: scp [-pqrvBC46] [-F config] [-S program] [-P port] : lyndon@gandalf:/sys/src/cmd/unix/u9fs; EOF on client side legolas is running FreeBSD 9.0; treebeard is OpenSolaris snv_b134, so the target ssh implementations are quite different. Sometimes the unexpected character comes back as 0x63.
Re: [9fans] SSHv2
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
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
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
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
contrib/quanstro/root/sys/src/cmd/auth/factotum Nfactotum misses proto=mschap which is used by cifs(4) for doing NTLM.
Re: [9fans] SSHv2
contrib/blstuart/ssh It's great! All thumbs up! Would it be hard to add cooked mode (-C)? -- - Yaroslav
Re: [9fans] SSHv2
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
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
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
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
On Fri Mar 30 06:48:39 EDT 2012, yari...@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
On Fri Mar 30 08:50:23 EDT 2012, blstu...@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
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
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
On Fri Mar 30 02:08:59 EDT 2012, 0in...@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
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
2012/3/30 erik quanstrom quans...@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
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
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
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 quans...@quanstro.net wrote: so russ i think with input from charles, rewrote factotum so that the protocols proceed in a single thread.
Re: [9fans] SSHv2
On Fri Mar 30 09:56:24 EDT 2012, lu...@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
[9fans] SSHv2
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
congratulations! :) -- cinap
Re: [9fans] SSHv2
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_len...@gmx.de wrote: congratulations! :) -- cinap -- Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)
Re: [9fans] SSHv2
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
Excellent news. On Mar 29, 2012, at 9:10 PM, blstu...@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
