Go Down

Topic: SSHPASS not functional in background (Read 5330 times) previous topic - next topic

supersleeper

Hi Folks,

Setting up a reverse-ssh session through double NAT so I can communicate back.  It absolutely works perfect while I'm in an active console session, but I can't seem to get it to work automatically from boot out of /etc/rc.local.

The script definitely get's executed because I see the process, but when I do a netstat, I see that the session is CLOSE_WAIT.  I also get "connection refused" from my SSH server (remote box).

I can ssh back into the yun, and execute the shell script in my active session, and it then gets ESTABLISHED connection and I can connect from my ssh server.

Here's a copy of the shell script minus my credentials:

   sshpass -p "mypassword" ssh -Rfy 12345:localhost:22 pi@home.myremoteserver.com/12345

Note I've got the -f flag for ssh to run in background after auth.  I've even attempted to place it in the crontab with no luck.

Any guidance is appreciated.

sonnyyu


jessemonroy650

#2
Jul 19, 2015, 11:15 am Last Edit: Jul 19, 2015, 11:16 am by jessemonroy650
::::SNIP::::
Here's a copy of the shell script minus my credentials:

   sshpass -p "mypassword" ssh -Rfy 12345:localhost:22 pi@home.myremoteserver.com/12345

Note I've got the -f flag for ssh to run in background after auth.  I've even attempted to place it in the crontab with no luck.

Any guidance is appreciated.

@supersleeper,

two things come to mind.

1) what is lower case (y) for? Did you mean upper case (Y) - Enables trusted X11 forwarding. ?

2) The time on the Yun is only set AFTER the system is fully booted and connected to the network.
It gets its time from a NTP server. ssh is time sensative - unless under loose settings.

FWIW, cron(1) likely does not work because you have a limited environment. If you want to delay the launch of sshpass, then use sleep(1) in a retry loop.

Jesse



supersleeper

@sonnyyu - I tried public keys, and got it to work only from my Pi to the Yun, but not the other way.  I see on my Pi auth.log I'm getting this, which corresponds to the messages in netstat:

Jul 20 08:45:18 home dropbear[7603]: Child connection from 70.214.14.205:11996
Jul 20 08:50:19 home dropbear[7603]: Exit before auth: Timeout before auth
Jul 20 08:51:52 home dropbear[7737]: Child connection from 70.197.12.24:57842
Jul 20 08:56:53 home dropbear[7737]: Exit before auth: Timeout before auth

@jessemonroy650 - lowercase y is supposed to keep the session open after auth.  I assumed it was to prevent any timeout.  I saw it on another example script for the same sort of reverse-ssh deal.  Thanks for the reminder on NTP.  I had forgot about the Yun not keeping time on reboot.

That said, however the cron should have worked.  I actually have sleep 70 set and the cron is set for every 1 min.  Still getting auth timeout.  Not sure exactly why.  At this point, still testing the script manually works which suggests it's already sync with NTP at that point, so I'm still confused.

My initial thought was that it didn't have permissions to run, but looking at the auth.log on the Pi tells me it's not executing one of the prompts (likely password).  Leads me to believe that sshpass lacks some permissions to run as a background process.

sonnyyu

#4
Jul 20, 2015, 07:55 pm Last Edit: Jul 20, 2015, 07:57 pm by sonnyyu

supersleeper

Sonnyyu - You are amazing.  I must have done at least 5-10 search variations trying to figure out Yun to third party keys.  This tutorial is perfect!  Thank you.

supersleeper

So strange.  Same results.  Works perfect (without password) while in active session, but not in cron.  Remote system logs are:

Jul 20 13:10:24 raspbmc dropbear[1625]: Exit (pi): Exited normally
Jul 20 13:15:38 raspbmc dropbear[1738]: Child connection from 70.197.12.24:57846
Jul 20 13:15:39 raspbmc dropbear[1738]: Pubkey auth succeeded for 'pi' with key md5 (KEY REMOVED) from 70.197.12.24:57846

It looks like the session isn't remaining open.  My command from Yun is as follows:

ssh -Rfy 2222:localhost:22  user@home.myserver.com/12345 -i ~/.ssh/id_rsa

executes and works perfectly but not in cron.


sonnyyu


jessemonroy650

::::SNIP::::

@jessemonroy650 - lowercase y is supposed to keep the session open after auth.  I assumed it was to prevent ::::SNIP::::
executing one of the prompts (likely password).  Leads me to believe that sshpass lacks some permissions to run as a background process.
Yep, it might be a server permission error. This might help.

sshpass script for connecting to two nested machines?
http://ubuntuforums.org/showthread.php?t=1986755

SSH Tunnel in Background
http://altfs.net/ssh-tunnel-in-background/


Google: sshpass background

Jesse

supersleeper

Hi Folks,

Looks like I got a little further ;).  So I can see that the cron sessions on the Yun are ESTABLISHED, and that the Pi now shows "Pubkey auth succeeded for 'pi'" however immediately after this I get "Exit (pi): Exited normally" with not even a second's time between entries.

if I execute the following command on the pi:

  while true; do ssh root@localhost -p 2222; done

It gives me "ssh: connect to host localhost port 222: Connection refused" and when the Yun established connection, it returns "ssh_exchange_identification: Connection closed by remote host".

I believe this is telling me that it's the Yun that's closing the connection, not the Pi.  According to anything I can find through google, this entry looks correct:

  ssh -Rfy 2222:localhost:22  user@home.myserver.com/12345 -i ~/.ssh/id_rsa

I'm going to try a tcp dump from my firewall too to see if anything is obvious.  Let me know if you think I'm missing something.

sonnyyu

Setup Reverse SSH via autossh

http://www.ibuyopenwrt.com/index.php/2-uncategorised/193-setup-reverse-ssh


Auto startup at boot, auto restart when droped.



Use autossh will kill two birds with one stone, could auto start at bootup and reconnect if connection is dropped.



supersleeper

Thanks folks, got autossh working.  I had an extra variable in my config file that was preventing the reverse tunnel from functioning.  Works very well.  Now I've been able to script and control my Yun through the Verizon Mifi from remote.

sonnyyu

#12
Jul 27, 2015, 09:11 pm Last Edit: Jul 27, 2015, 09:11 pm by sonnyyu
mark (edit) subject as "[SOLVED]", please.





Go Up