>
>> 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
m
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
>> > 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
> reb
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 k
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
>
> 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
> 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 go
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
>
> I have fixed various bugs in ssh2; they'll be in the ssh2
> on sources once it's all shaken down.
Wow!
++L
I have fixed various bugs in ssh2; they'll be in the ssh2
on sources once it's all shaken down.
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."
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/f
> 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?
>> 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 (tha
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 u
> 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 w
> 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 fa
> 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 instan
> 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
> > 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
> The client side logs will be in /sys/log/ssh
This was not created on my system.
-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
> 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
> 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: hands
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
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=DA58E231
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=DA58E23128A865ABF57DCEEBB31529854F0EFBB0D50ADC5D930F29D7B5592724E9C8A1D74D011407
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 a
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 wrote:
> so russ i think with input from charles, rewrote factotum so that the
> protoc
> 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
> 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
2012/3/30 erik quanstrom :
>> 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 -
> contrib/quanstro/root/sys/src/cmd/auth/factotum
contrib/install quanstro/nfactotum. move your old factotum out of the way
first.
- erik
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
>
> 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
> 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
>
>> 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, pl
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
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
>> 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
>> 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
> Would it be hard to add cooked mode (-C)?
never mind: it's easy to simulate by binding /dev/nul over /dev/consctl.
>> 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
> contrib/blstuart/ssh
It's great! All thumbs up!
Would it be hard to add cooked mode (-C)?
--
- Yaroslav
> contrib/quanstro/root/sys/src/cmd/auth/factotum
Nfactotum misses proto=mschap which is used by cifs(4) for doing NTLM.
> 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 b
> 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?
superb!
On 30 Mar 2012, at 03:10 AM, blstu...@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:
>
>> There's a "start" member to "struct Srv" that doesn't
>> seem to exist in
>
> You should apply this patch (from plan9port):
Thanks, David, that seems to have worked so far.
++L
> There's a "start" member to "struct Srv" that doesn't
> seem to exist in
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(*de
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
> 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
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.
> 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.
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, wrote:
> congratulations! :)
>
> --
> cinap
>
--
Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)
congratulations! :)
--
cinap
54 matches
Mail list logo
