ssh in rc.local stalls [SOLVED]

[Steve Brueckner]

Mike McGrath wrote:
> Steve Brueckner wrote:
> 
>> Mike McGrath wrote:
>> 
>> 
>>> Steve Brueckner wrote:
>>> 
>>> 
>>> 
>>>> I need to create an ssh port forwarding tunnel to another machine
>>>> when my Xen VM starts up, so I added this to the VM's
>>>> /etc/rc.d/rc.local: 
>>>> 
>>>> ssh -f -L 5500:localhost:5501 remote_host_ip tail -f /dev/null
>>>> 
>>>> This causes my VM to pause for about 3 minutes during boot right
>>>> after "Starting HAL daemon: [  OK  ]" Furthermore, the ssh tunnel
>>>> never gets created. 
>>>> 
>>>> 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? 
>>>> 
>>>> I don't get any errors in /var/log/messages, just a 3-minute gap
>>>> between entries.  Is there anywhere else I can look to find
>>>> potential error messages? 
>>>> 
>>>> When I try the same trick on the bare-metal host machine, it works
>>>> fine: no 3-minute stall and the ssh tunnel is created fine.  So I
>>>> suppose what I need is a way to find or create error messages so I
>>>> can diagnose further.  Maybe then I can take this to the Xen list.
>>>> 
>>>> Stephen Brueckner, ATC-NY
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> I use the following method to create ssh tunnels on startup: (in
>>> inittab) 
>>> 
>>> log1:3:respawn:/usr/bin/ssh -nNtx -R 5500:localhost:5501
>>> remote_host_ip > /dev/null 2>&1
>>> 
>>> This, however, may not solve your problem.  Are you sure you're
>>> public and private keys are in the right spot and have the correct
>>> permissions? 
>>> 
>>> 	-Mike
>>> 
>>> 
>> 
>> My permissions are OK, since I can run the command manually after
>> login.  I just tried adding -vvv to the ssh command, and it's
>> hanging on: 
>> 
>> "Debug1: Connecting to (remote_IP) port 22."
>> 
>> So I also tried adding a wget into rc.local, and wget fails with:
>> 
>> "Resolving download.fedora.redhat.com... Failed: Host not found."
>> 
>> So my guess is that Xen isn't bringing up the network for the VM
>> until after login. 
>> 
>> 
>> 
> On the remote machine, (not the VM) try running a TCP dump to see if
> anything is getting sent to that machine from the VM. 
> 
>     -Mike

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)

Thanks for your response; I appreciate it.

 - Steve