9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] silly question on ssh
Date: Tue, 15 Apr 2003 10:54:52 -0400	[thread overview]
Message-ID: <492c18722cee957a3068d7e4d1e7d0c2@plan9.bell-labs.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304150804300.8725-100000@maxroach.lanl.gov>

> One plan 9 image, running a term and login as glenda, can ssh to the linux
> side no trouble. The other, a cpu/auth/kfs server with me logged in as
> user bootes, used to work, but nowadays is getting 'client authentication
> failed'.
>
> tcpdump shows the client side (plan 9) closing the connection.
>
> What's a good way to start debugging this kind of thing? My keyring is
> empty. I'm not really sure where to start, and am ssh-impaired to boot.

Run:

	auth/factotum
	ssh linux-box

so that you don't have any factotum state.
Hopefully you'll get prompted for a key.
It's likely you typed the wrong password
and then factotum held onto it.

> Another silly question. Same box. I have a cpu node (real hardware) coming
> up with 9load in flash. It is connected to eth0, 10.0.4.1. The vmware
> network is vmnet8 @ 172.16.189.1 (vmnet8 as vmware says you have to use
> NAT if you have wireless, which I do). I am also routing-impaired :-)
>
> I have tested this cpu hardware downloading plan9 kernels via 9load and a
> dhcp/tftp server in linux, and it works. Now I need to have it connect to
> the auth server in vmware, and I would most prefer to have it suck the
> kernel down from the auth server in vmware.
>
> What I want is to rig things somehow so that the DHCP requests from the
> hardware CPU node on the eth0 net (10.0.x.x) go to the vmware auth server
> on vmnet8 (172.16.189.x).
>
> I note that broadcasts are not making it from the 10.0.x.x net to the
> 172.16.189.x net.
>
> OK, anyone know the magic formula to make this work? How many things am I
> doing wrong-- countably or uncountably infinite?

I think VMware 4 might be able to do bridged mode over wireless.
I don't remember, but I thought I saw that listed as one of the new features.

Otherwise you'd have to convince the Linux host to act as a router
for the private network and also do DHCP forwarding to the VM network.
Problem is your 10.0.x.x network probably has a default gateway to
get to the rest of the internet, and that default gateway isn't your
VMware box.  You might be able to get this going with some chewing
gum and string, but it won't be pretty.



      reply	other threads:[~2003-04-15 14:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-15 14:35 ron minnich
2003-04-15 14:54 ` Russ Cox [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=492c18722cee957a3068d7e4d1e7d0c2@plan9.bell-labs.com \
    --to=rsc@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).