I'm having a curious problem with a little script to make a VNC connection to a remote host. The script just makes an SSH tunnel for the VNC session and then opens the viewer. It's only two lines, and when copied into the shell manually, it works fine. However, invoking the script causes the VNC viewer to fail with this error:
main: unable to connect to host: Connection refused (111)
Here's the script:
#!/bin/bash
ssh -N -L5903:localhost:5903 username#example.com &
vncviewer :3
The tunnel lives throughout the process, so that isn't the problem. Neither is permissions -- the same error occurs when the script is run as root. I've got public key authentication set up, so it's not that ssh is requesting a password.
What am I missing? The commands work when typed in the shell!
Thanks in advance.
Most likely the vncviewer command is being executed too quickly after the ssh command. Try putting
sleep 3
between those two commands to allow time for the port forwarding to be set up.
Related
Essentially what I want to do is run a Bash script I created that switches WiFi SSIDs before starting the SSH connection, and after the SSH connection closes.
I have added this to ~/.ssh/config by setting ProxyCommand to ./run-script; ssh %h:%p but by doing this, I feel like it would ignore any parameters I passed when I run the ssh command. Also, I have no idea how to get the script to run again when the SSH connection closes.
For OpenSSH you can specify a LocalCommand in your ssh config (~/.ssh/config).
But for that to work you also need the system-wide option (in /etc/ssh/ssh_config) PermitLocalCommand to yes. (By default it is set to no.)
It gets executed on the local machine after authenticating but before the remote shell is started.
There appears to be no (easy) way of executing something after the connection has been closed, though.
Assuming that it is not possible to implement a wrapper to 'ssh' (using alias, or some other method), it is possible to implement the following in the proxyCommand.
Important to note that there is no protection against multiple invocation of 'ssh' - possible that during a specific invocation that WIFI is already connected. Also, it is possible that when a specific ssh is terminated, the WIFI has to stay active because of other pending conditions.
Possible implementation of the proxy script is
ProxyCommand /path/to/run-script %h %p
#! /bin/sh
pre-command # connect to WIFI
nc -N "$1" "$2" # Tunnel, '%h' and '%p' are passed in
post-command # Disconnect WIFI
You do not want to use simple ssh in the proxy script, as this will translate into another call to the 'run-script'. Also note that all options provided to the original ssh will be handled by the initial 'ssh' session that will be leveraging the proxy 'nc' tunnel.
I am trying to download a stackoverlfow dump of all posts to a remote server (actually a container on a remote host). Now as you can image the dump is large (11G). I want to start a download and then be able to exit my SSH connection to the remote host.
I have looked at tmux but it's confusing.
I know wget https://archive.org/download/stackexchange/stackoverflow.com-Posts.7z will work but I will have to stay connected for the duration of the download.
Does anyone know how I can use tmux to solve this problem?
If I've correctly understood you situation, using nohup to launch the command will do the trick.
nohup wget https://archive.org/download/stackexchange/stackoverflow.com-Posts.7z
This will prevent the killing of the wget process when the shell terminates.
You can connect via SSH, execute the above command and exit. It will keed downloading by itself.
By the way: Tmux stands for Terminal Multiplexer and it's not related to the life cycle of a process.
I am on a server and running a script file that has following code.
ssh username#servername
sudo su - root
cd /abc/xyz
mkdir asdfg
I am able to ssh... but then the next command is not working.. the script is not sudo-ing. any idea?
Edit: Able to create a mech id and then do the things.. though still looking for the answer to above question :|
First of all your command will "stuck" on the first line because it will go into an interactive mode. The ssh command will require a password to be provided by a user (unless there is an sshkey being used) . And if the ssh is logged into the remote server then it will wait for user commands from standard input.
Secondly the lines following the ssh command will be executed only when the first process has exited. This is why your script is not "sudoing" - it's waiting for the ssh to end.
So if your point is to run a command on a remote server then put the command as a parameter into the same line as ssh connection. In your case:
ssh user#server sudo su - root
But this will not be of satisfaction for you. I suggest you create a script of what you want to execute on the remote server and then execute the script.
ssh user#server scriptName
The sudo thing here is very tricky because again your script might get stuck in the interactive mode waiting for a password to be inserted so I suggest you think again on the basis of the script.
mb47!
You want to run the script on the remote computer, correct?
On the remote machine, create a file containing the commands you would like to execute.
Then, on the other machine, run ssh user#machine /path/to/script/you/created/earlier
I hope this helps!
ALinuxLover
Shrewsoft [1] provides a command line interface for setting up the vpn tunnel automatically without any user intervention, such as by using the following command
ikec -u username -p password -r configuration -a
IS there any way to detect if the connect attempt was successful such as by reading live logs and how can we terminate the vpn tunnel after some time using the command line. Any help will be appreciable.
By looking at the terminal output from ikec -u username -p password -r configuration -a, you can tell if the connection was successful; if the output has a line ii : tunnel enabled, that means the connection was successful and should work. If you get a message such as >> : detached from key daemon or failed to connect to key daemon, it means there was a problem with the connection (https://askubuntu.com/a/793336/705434 suggests running sudo /usr/sbin/iked for a solution to this particular error). To exit the ikec command, just type q into the terminal.
EDIT: it looks like this page (https://gist.github.com/fschabmeyer/22b759994cf852df7e9b) has a shell script that can handle the detection, you should be able to add a case to exit the command automatically after a certain amount of time.
I frequently need to ssh into a server, but I can't ssh into it directly while I'm connected to our VPN. Thus, I have to ssh into another server and ssh into it from there. Is there any way that I can write a script and/or shell function for this? I've tried this, buit it gave me an error:
% ssh jason#server2 'ssh jason#server1'
jason#server2's password:
Pseudo-terminal will not be allocated because stdin is not a terminal.
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,gssapi-with-mic,password).
(and of course the username and server name have been changed)
It can't show you password prompt. I think all will work with public keys (and, for example, forwarded ssh-agent to eliminate need of entering key passphrases).
SSH connection stacking may help you. Assuming the following layout: Client -> Middleman -> Destination
On Client:
ssh user#Middleman -L 1337:Destination:22
This will allow you to directly SSH into Destination from Client in another session:
On Client:
ssh user#localhost -p 1337
The command runs as if you had typed ssh user#Destination. You can pipe stdin to it as if you were directly connected to it.
Sounds like you want to set up public key authentication between the middle machine and end machines.
Here are a couple of decent guides to get you started. Good luck.
http://hkn.eecs.berkeley.edu/~dhsu/ssh_public_key_howto.html
http://pkeck.myweb.uga.edu/ssh/
From what I see, the problem is ssh on the middle machine cannot get the standard input. I guess it just want to ask for your password. If that is true, perhaps you should try to set up ssh key so that you can ssh without password. NOTE: If that success, you better create a new user on the middle machine to hold that key as a security measure.