Karsten M. Self wrote:
> on Thu, Dec 15, 2005 at 01:38:29PM -0500, Steve Brueckner
> (steve@xxxxxxxxxxxxxx) wrote:
>> I'm using Fedora Core 4. I need to create an ssh port forwarding
>> tunnel to my xen0 domain when my xenU domain starts up, so I added
>> this to the xenU's /etc/rc.d/rc.local:
>> ssh -v -f -L 5500:localhost:5501 xen0_ip tail -f /dev/null
>> This causes my VM to pause for about 3 minutes during boot.
>> Furthermore, the ssh tunnel never gets created. The ssh command is
>> stalling at "Connecting to (xen0_IP) port 22"
> It would be useful to see what's happening on the remote (well,
> local) server side. Check sshd's logs, and/or run it manually in
> debug mode and watch its output as the connection is being attempted:
> sshd -ddDe
> <ctrl>-c to exit when done.
>> I have null-passphrase authentication keys working, so I can execute
>> the tunnel manually after I log in. So why won't the tunnel work
>> before I log in?
>> When I try the same trick on the bare-metal host machine and ssh to a
>> different physical machine, it works fine: no 3-minute stall and the
>> ssh tunnel is created fine.
> A three-minute timeout sounds suspiciously like a network timeout.
> rc.local runs _after_ all other rc scripts, so networking should be
> up and running.
> You might want to ammend your script to check networking status,
> _before_ the ssh command is executed:
> ifconfig; route -n; ping localhost
> Check also that /etc/hosts has a proper localhost entry.
>> So what is it about Xen or my xenU domain that breaks ssh before
>> login, but not after login? And what is it about Xen or my xenU
>> domain that breaks ssh before login, while it works fine for a
>> physical host?
> Logs and debug output would be helpful here.
Ah, I should have thought of this earlier. My custom SELinux policy
disables networking for unconfined_t, so it puts ssh into sshd_t (which
allows networking). But it only puts ssh into sshd_t when started by root;
there was no transition specified in my policy that ssh should go into
sshd_t when started by initrc_t. A couple of lines in my
domains/program/ssh.te fixed it:
role initrc_t types sshd_t;
domain_auto_trans(initrc_t, sshd_exec_t, sshd_t)
So, the network was in fact up but I was shooting myself in the foot. This
is definitely not a Xen-related issue. Thanks for your responses; I
appreciate the help.
Xen-users mailing list