At 19:15 12/07/2012, you wrote:
Hi Doug,
Thanks for the feedback Tim.
Glad I could help.
Using your string, I can now telnet to port 22222 on localhost (hostA) and I get the mysql connection string (from hostB), but it is not able to make a mysql connection (using mysql -u user -p -h localhost --port=22222 from hostA), with a test user that I set up to allow connections from anywhere. The error that I am getting is: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
I did test and the mysql test user that I created is able to connect from hostB.
Because the mysql connection is via an ssh tunnel, you need to ensure on the MySQL server hostB that is allows the mysql user access from 127.0.0.1 on hostB as that is effectively where the MySQL server on hostB sees the connection coming from.
Also, when I do this, it still opens up an ssh session, logging me into the remote machine, thus making it so I can't use this terminal.
Yes you need to run it is a screen session if you want it permanently connected.
The eventual goal is to do this in a script, that will open the connection, use it for the duration of the script, and then close it when the script finishes, but it looks like that won't work, since it is logging me into the remote machine. I guess I could get around that by always leaving the screen session going with the connection, but I would prefer only creating the connection when I need it.
Any ideas how to do this without leaving the connection open all the time?
I have used an expect script to do this in the past. Which allows you to remotely log in to a server. Downside is you need to store the password in plain text in the expect script. So make sure only root can read the script. Or setup a lower privilege user to use sudo and do it that way.
regards Tim Tim D'Cruz
Doug,
It's also possible to send ssh to the background and also skip remote commands (perfect for tunneling).
Options for ssh command: -f .......... background -N ......... skip remote commands
** Personally I'd look for a more robust tunnel/VPN alternative. ** 1) OpenSSH tun/tap devices - but this should really be used for a 'one-off' quick tunnel => requires root to establish, so it's not ideal for every situation! (think roadwarriors, etc) 2) OpenVPN - SSL VPN - software/application based - simpler to set up as a result 3) OpenSWAN - IPSec VPN - hooks into the kernel (netkey or klips)
---~~.~~--- Mike // SilverTip257 //
On Thu, Jul 12, 2012 at 4:15 PM, We Are Here support@wearehere.net wrote:
At 19:15 12/07/2012, you wrote:
Hi Doug,
Thanks for the feedback Tim.
Glad I could help.
Using your string, I can now telnet to port 22222 on localhost (hostA) and I get the mysql connection string (from hostB), but it is not able to make a mysql connection (using mysql -u user -p -h localhost --port=22222 from hostA), with a test user that I set up to allow connections from anywhere. The error that I am getting is: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
I did test and the mysql test user that I created is able to connect from hostB.
Because the mysql connection is via an ssh tunnel, you need to ensure on the MySQL server hostB that is allows the mysql user access from 127.0.0.1 on hostB as that is effectively where the MySQL server on hostB sees the connection coming from.
Also, when I do this, it still opens up an ssh session, logging me into the remote machine, thus making it so I can't use this terminal.
Yes you need to run it is a screen session if you want it permanently connected.
The eventual goal is to do this in a script, that will open the connection, use it for the duration of the script, and then close it when the script finishes, but it looks like that won't work, since it is logging me into the remote machine. I guess I could get around that by always leaving the screen session going with the connection, but I would prefer only creating the connection when I need it.
Any ideas how to do this without leaving the connection open all the time?
I have used an expect script to do this in the past. Which allows you to remotely log in to a server. Downside is you need to store the password in plain text in the expect script. So make sure only root can read the script. Or setup a lower privilege user to use sudo and do it that way.
regards Tim Tim D'Cruz
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 07/13/2012 03:45 AM, SilverTip257 wrote:
Doug,
It's also possible to send ssh to the background and also skip remote commands (perfect for tunneling).
Options for ssh command: -f .......... background -N ......... skip remote commands
** Personally I'd look for a more robust tunnel/VPN alternative. **
- OpenSSH tun/tap devices - but this should really be used for a
'one-off' quick tunnel => requires root to establish, so it's not ideal for every situation! (think roadwarriors, etc) 2) OpenVPN - SSL VPN - software/application based - simpler to set up as a result 3) OpenSWAN - IPSec VPN - hooks into the kernel (netkey or klips)
---~~.~~--- Mike // SilverTip257 //
On Thu, Jul 12, 2012 at 4:15 PM, We Are Heresupport@wearehere.net wrote:
At 19:15 12/07/2012, you wrote:
Hi Doug,
Thanks for the feedback Tim.
Glad I could help.
Using your string, I can now telnet to port 22222 on localhost (hostA) and I get the mysql connection string (from hostB), but it is not able to make a mysql connection (using mysql -u user -p -h localhost --port=22222 from hostA), with a test user that I set up to allow connections from anywhere. The error that I am getting is: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
I did test and the mysql test user that I created is able to connect from hostB.
Because the mysql connection is via an ssh tunnel, you need to ensure on the MySQL server hostB that is allows the mysql user access from 127.0.0.1 on hostB as that is effectively where the MySQL server on hostB sees the connection coming from.
Also, when I do this, it still opens up an ssh session, logging me into the remote machine, thus making it so I can't use this terminal.
Yes you need to run it is a screen session if you want it permanently connected.
The eventual goal is to do this in a script, that will open the connection, use it for the duration of the script, and then close it when the script finishes, but it looks like that won't work, since it is logging me into the remote machine. I guess I could get around that by always leaving the screen session going with the connection, but I would prefer only creating the connection when I need it.
Any ideas how to do this without leaving the connection open all the time?
I have used an expect script to do this in the past. Which allows you to remotely log in to a server. Downside is you need to store the password in plain text in the expect script. So make sure only root can read the script. Or setup a lower privilege user to use sudo and do it that way.
regards Tim Tim D'Cruz
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi,
You can also set up ssh access using keys so that you do not need to enter a password when connecting.
Regards
ChrisG
Hello Mike, On Thu, Jul 12, 2012 at 7:45 PM, SilverTip257 silvertip257@gmail.comwrote:
Doug,
It's also possible to send ssh to the background and also skip remote commands (perfect for tunneling).
Options for ssh command: -f .......... background -N ......... skip remote commands
I think these were the options that I was missing. I was able to create the tunnel, and get my prompt back (so it will work within a script), without a screen session. Thanks for this tip.
** Personally I'd look for a more robust tunnel/VPN alternative. **
- OpenSSH tun/tap devices - but this should really be used for a
'one-off' quick tunnel => requires root to establish, so it's not ideal for every situation! (think roadwarriors, etc) 2) OpenVPN - SSL VPN - software/application based - simpler to set up as a result 3) OpenSWAN - IPSec VPN - hooks into the kernel (netkey or klips)
Trying to get this connection over ssh is just a short term solution. We will be setting up a vpn tunnel between the systems in the near future (but probably still 2-3 weeks out), but I was needing to get something else running before then. The ssh solution works for the short term, until we have an opportunity to get the vpn working.
Thanks to every one for the assistance with this issue. -- Doug
Registered Linux User #285548 (http://counter.li.org) ---------------------------------------- Never trust a computer you can't throw out a window. -- Steve Wozniak
-
Chris Geldenhuis -
SilverTip257 -
Ski Dawg -
We Are Here