I've installed xquartz on my OSX machine, and upon connecting to a remote server with ssh -X user#server.domain I'm able to launch gui windows (let's say Rstudio for example --I see the window show up on my screen even though it's running on the remote server -neato!).
What I'd like to do is create stable, persistent sessions to disconnect/reconnect to (i.e. close and re-open the same window with my environment and variables still there, instead of closing it and opening another one).
Hence, I'm using a tmux session from the terminal so that I can detach from my ssh connection to the server and connect back later. What I'd like to do then is re-launch the gui windows that I started from that session previously. Unfortunately, I don't know how to "store" or "detach" from the GUI windows once they are created --if I close them, then the unsaved data is deleted and the session is lost.
Is there a way to launch a persistent window from within ssh -X, and then "hide" that window, and re-open it after connecting again later?
Not sure if this will still help now but I'll put it here for posterity. For the specific RStudio case you'd be better off installing a server version of RStudio - either the paid RStudio Workbench or the free open-source version. The server versions provide the persistent sessions you're looking for, including for long-running jobs.
The open source version has a login, but all passwords are sent in unencrypted - don't expose it to the internet without other protections. In the open-source version you can only have one session per user.
Even without allowing access to the public internet you could forward port 8787 over ssh ( -L 8787:localhost:8787) & log into the remote RStudio Server instance from your local browser by visiting localhost:8787.
I would like to use RStudio for analysis of data on a MySQL instance. This is a AWS RDS MySql instance that is only accessible via a jump box / bastion host. I have the credentials necessary to connect to the jump box, and from the jump box to the RDS instance. What do I need to do be able to query this DB directly from within the RStudio console?
I can connect (using the Terminal tab in RStudio)to the jump box using:
ssh -p 22xx user#ip.add.re.ss
Then I can connect to RDS mysql using:
mysql -u username -p database -h hostname.us-east-1.rds.amazonaws.com
I can connect and do manual mysql commands from within RStudio terminal, but I don't seem to be able to do anything with the DB from the RStudio console.
Sorry for opening a 2yo thread, but for everyone dealing with this issue as I am - I found this thread and it looks like it works (connecting with MySQL via ssh from R Studio).
You should use something which is called port forwarding. Some details
are here
(https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding) For
example, say you wanted to connect from your laptop to
http://www.ubuntuforums.org using an SSH tunnel. You would use source
port number 8080 (the alternate http port), destination port 80 (the
http port), and destination server www.ubuntuforums.org. :
ssh -L 8080:www.ubuntuforums.org:80 Where should be
replaced by the name of your laptop.
This is done for whole computer so you dont need to do this from r
studio.
Offcourse you need to forward your port to 3036. But you need special
privilige on the server. Because on most hosting you can only connect
from localhost (for example from PHP)
Source: https://www.py4u.net/discuss/881859
I am using paramiko as ssh client for remote machine and starting a new tmux session using the client. After sometime I am getting a broken pipe exception. Socket exception: Connection reset by peer (54). Because of this my tmux sessions are killed. I tried changing ssh.socket to service and also added Killmode in ssh#.service. But still i am getting the same exception. Any suggestions to solve this error?
After editing /etc/network/interfaces on a GCloud VM instance I cannot access the machine at all through SSH. GCloud SDK shell still shows the instance running but the applications are no longer available. I have tried to SFTP to the machine as well, but without success. Is there any way to edit/repair the VM instance interfaces file without having to revert back to an earlier snapshot?
Many thanks!
You can create a new GCE instance and attach the disk of the old instance to the new instance. Then you can connect to the new instance and change anything you want in the old disk.
I'm looking for a way that will allow me to use an SSH Tunnel to connect to a MySQL Server (as opposed to a file) within R; I'm assuming it'll require a combination of RCurl and RODBC, but I can't seem to get it to work properly.
I came across this post and this post that talk about utilizing SSH to connect to specific files or tables, but I'm hoping to use it as part of a Shiny app that will execute different SQL queries based on input from the user, which would require connecting into the server as opposed to specific files.
I'm assuming the code would look something along these lines x = scp("remote.ssh.host.com", "/home/dir/file.txt", "My.SCP.Passphrase", user="username"), but would I replace the "/home/dir/file.txt" piece with an odbcConnect() statement or replace it with the port number for the specific database I want to access?
Edit: The line I use for a regular odbcConnect() is odbcConnect(dsn, uid = "userid", pwd = "password"). Part of the problem is, I am developing it on Windows, but it will be deployed to a Linux server (handled be someone else) so I'm struggling to figure out what exactly will need to be used in my server.R code for connecting to the database.
Okay, so to test this on Windows, either grab Cygwin, or install OpenSSH so you can run ssh from the command line in Windows, like you would do in Linux.
Once you have ssh running on your Windows box, then try first making a tunnel through SSH. Run this from the command line:
ssh -f <server_user>#<server_ip> -L <unused_local_port>:localhost:<database_remote_port> -N
Obviously, replace everything in '<>' with the appropriate information. It will ask for the password, and remember that this isn't the database password, but the password to the server itself. Notably, the server_ip doesn't have to be the server with the database on it, just any server that is inside the proper subnet and that runs an SSH server, which is pretty much all Linux machines.
Now, setup an ODBC connection, except make the IP localhost, and the port unused_local_port. Now, try connecting to your new ODBC connection in R. If this works you're halfway there.
The next problem is the password, because you will have to enter a password to connect via SSH, but in R you won't be able to input it after a simple system command. So you have to setup some a public/private rsa key pair. Notably, this will make it so that anyone with access to your user/pass on your Windows box will now have automatic access to your server, so be careful. First, generate a SSH key:
ssh-keygen -t rsa
Don't make a passphrase, and save it in the default location. Now, create the directory for your public key on the remote host, and drop your public key in there.
# This creates a directory on the other machine if it wasn't already there. (Type in your password on the remote machine)
ssh <server_user>#<server_ip> mkdir -p .ssh
# This adds your public key to the list of accepted ones:
cat ~/.ssh/id_rsa.pub | ssh <server_user>#<server_ip> 'cat >> .ssh/authorized_keys'
Now try creating your tunnel again from the command line:
ssh -f <server_user>#<server_ip> -L <unused_local_port>:localhost:<database_remote_port> -N
If it doesn't ask you for the password, you have succeeded in creating your keypair. Now you are ready to run your ssh command from the command line. But before you do that, try and kill your ssh command, so you can make sure that R is actually creating the tunnel, and you aren't just reusing an old one. You can do it through Windows Task Manager (Ctrl+Alt+Esc), and just right click and End Process the ssh.exe.
So, just run:
system('ssh -f <server_user>#<server_ip> -L <unused_local_port>:localhost:<database_remote_port> -N')
And then connect to your new tunneled ODBC connection.