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
