Autossh not accepting logfile option for ssh - ssh

autossh -M 10984 -v -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -R 6889:localhost:22 user#rpi.local
The above command works. The one below doesn't.
autossh -M 10984 -E /home/pi/ssh.log -v -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -R 6889:localhost:22 user#rpi.local
It says,
/usr/lib/autossh/autossh: invalid option -- 'E'`
How can I specify a log file as the SSH option when passing it to autossh?

This is a limitation of autossh. The autossh source code contains a list of command-line switches which the program accepts. The list is apparently supposed to include all of the ssh options, but it doesn't include "E":
#define OPTION_STRING "M:V1246ab:c:e:fgi:kl:m:no:p:qstvw:xyACD:F:I:MKL:NO:PR:S:TVXY"
...
/*
* We accept all ssh args, and quietly pass them on
* to ssh when we call it.
*/
while ((ch = getopt(argc, argv, OPTION_STRING)) != -1) {
switch(ch) {
case 'M':
...
It seems there are a few workarounds at present:
Run autossh with standard error directed to the desired file:
autossh -M 10984 -v -o ... user#rpi.local 2>>/some/log/file
SSH instances launched from autossh should inherit the redirection.
Use the ssh "-y" option to log through syslog, and have syslog write the messages where you want them to be written.
Modify the autossh source code to add support for the "-E" option.
Report the issue to the autossh maintainer and hope he fixes it in a later release.

Related

Escaping karate.fork Commands

I am trying to run the following command in karate using karate.fork
ssh -o ProxyCommand="ssh -W %h:%p -i ~/.ssh/id_rsa root#myjumphost" -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no -o PasswordAuthentication=no root#finaldest echo test
I have broken this up into an array to pass to karate.fork like so:
[
ssh,
-o,
ProxyCommand="ssh -W %h:%p -i ~/.ssh/id_rsa root#myjumphost",
-i,
~/.ssh/id_rsa,
-o,
StrictHostKeyChecking=no,
-o,
PasswordAuthentication=no,
root#finaldest,
echo test
]
Then run the command like so:
* karate.fork(args) where args is the array mentioned above
The command works when I paste it into the terminal and run it manually, however when run with karate.fork I get
zsh:1: no such file or directory: ssh -W finaldest:22 -I ~/.ssh/id_rsa root#myjumphost
kex_exchange_identification: Connection closed by remote host
I have tried adding a few backslashes before the " in the ProxyCommand but no amount of back slashes fixes this issue. I think I am misunderstanding what karate.fork is doing to run the command, is there some internal parsing or manipulating of the given input? I was able to get this command to work when I used useShell: true however this option breaks other tests for me so I would really like to avoid it.
I had to remove the double quotes, seems like they didn't play well with karate.fork and the command still runs without them
[
ssh,
-o,
ProxyCommand=ssh -W %h:%p -i ~/.ssh/id_rsa root#myjumphost,
-i,
~/.ssh/id_rsa,
-o,
StrictHostKeyChecking=no,
-o,
PasswordAuthentication=no,
root#finaldest,
echo test
]

How to deal with "Pseudo-terminal will not be allocated because stdin is not a terminal."

ssh -t remotehost vim /tmp/x.txt
I know that I can run a command like the above.
But I would like to be able to run any local bash code in a remote machine. For this reason, I'd like to call the remote 'bash -s' so that can process any local bash code.
ssh -t remotehost 'bash -s' <<< vim /tmp/x.txt
However, the above example shows "Pseudo-terminal will not be allocated because stdin is not a terminal." Is there any way to let ssh take local bash code via stdin and run it via the remote 'bash -s'? Thanks.
ssh -t remotehost 'bash -s' <<< vim /tmp/x.txt
You're getting the "Pseudo-terminal will not be allocated..." message because you're running ssh with a single -t option, when the standard input to the ssh process isn't a TTY. ssh prints that message specifically in this case. The documentation for -t says:
-t
Force pseudo-terminal allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
The -t command-line option is related to the ssh configuration option RequestTTY:
RequestTTY
Specifies whether to request a pseudo-tty for the session. The argument may be one of: no (never request a TTY), yes (always request a TTY when standard input is a TTY), force (always request a TTY) or auto (request a TTY when opening a login session). This option mirrors the -t and -T flags for ssh(1).
A single -t is equivalent to "RequestTTY yes", while two of them is equivalent to "RequestTTY force".
If you want your remote command(s) to run with a TTY, then specify -t twice:
ssh -tt remotehost 'bash -s' <<< vim /tmp/x.txt
or
ssh -t -t remotehost 'bash -s' <<< vim /tmp/x.txt
ssh will allocate a TTY for the remote system and it won't print that message.
If the command(s) being run on the remote system don't require a TTY, you can leave the -t option out:
ssh remotehost 'bash -s' <<< vim /tmp/x.txt
I believe the following might suit your purposes:
vim /tmp/x.txt ; ssh remotehost 'bash -s' < /tmp/x.txt
The first expression (vim ...) allows you to specify the commands you want to execute remotely as a local file called /tmp/x.txt; the second expression (ssh ...) calls the remote bash interpreter, and sends the contents of your local file to it for execution. Note that you do not need the -t option for ssh in this case (which gave rise to the pseudo-terminal warning), and that you do not need to use a here string (<<<) but can use the normal file input operator (<).
This solution seems to work for, e.g., the following file contents:
echo These commands are being executed on $HOSTNAME
echo This is a second command

Permission denied using ssh command in shell

I'm trying to execute this shell with command line
host="192.168.X.XXX"
user="USERNAME"
pass="MYPASS"
sshpass -p "$pass" scp -o StrictHostKeyChecking=no /home/MYPATH/File.import "$user#$host:/"home/MYPATH/
To copy a file from my local server in to remote server. The remote server is a copy of the remote server but when I try to execute this shell I have this error:
**PERMISSION DENIED, PLEASE TRY AGAIN**
I didn't understand why if I try to execute this command in command line is working.
USERNAME#MYSERVER:~$ sshpass -p 'MYPASS' scp -o StrictHostKeyChecking=no /home/MYPATH/File.import USERNAME#192.168.X.XXX:/home/MYPATH/
Somebody have a solution??
Please use a pipe or the -e option for the password anyway.
export SSHPASS=password
sshpass -e ssh user#remote
Your simple command with -e option:
export SSHPASS=password
sshpass -e scp -o StrictHostKeyChecking=no /home/MYPATH/File.import user#192.168.X.XXX:/home/MYPATH/
Please remove the wrong quotes from your command:
sshpass -p "$pass" scp -o StrictHostKeyChecking=no /home/MYPATH/File.import $user#$host:/home/MYPATH/
You should also be able to remove the quotes around $pass.
Please ensure that you have no special characters in your pass variable or escape them correctly (and no typos anywhere).
For simplicity use a ssh command instead of scp for testing
Use the -v or -vvv option for the scp command to check what scp is trying to do. Also check the secure log or auth.log on the remote server
You have to install "sshpass" command then use the below snippet
export SSHPASS=password
sshpass -e sftp user#hostname << !
cd sftp_path
put filename
bye
!
A gotchya that I encountered was escaping special characters in the password which wasn't necessary when entering it in interactive ssh mode.

ssh client (dropbear on a router) does no output when put in background

I'm trying to automate some things on remote Linux machines with bash scripting on Linux machine and have a working command (the braces are a relict from cmd concatenations):
(ssh -i /path/to/private_key user#remoteHost 'sh -c "echo 1; echo 2; echo 3; uname -a"')
But if an ampersand is concatenated to execute it in background, it seems to execute, but no output is printed, neither on stdout, nor on stderr, and even a redirection to a file (inside the braces) does not work...:
(ssh -i /path/to/private_key user#remoteHost 'sh -c "echo 1; echo 2; echo 3; uname -a"') &
By the way, I'm running the ssh client dropbear v0.52 in BusyBox v1.17.4 on Linux 2.4.37.10 (TomatoUSB build on a WRT54G).
Is there a way to get the output either? What's the reason for this behaviour?
EDIT:
For convenience, here's the plain ssh help output (on my TomatoUSB):
Dropbear client v0.52
Usage: ssh [options] [user#]host[/port][,[user#]host/port],...] [command]
Options are:
-p <remoteport>
-l <username>
-t Allocate a pty
-T Don't allocate a pty
-N Don't run a remote command
-f Run in background after auth
-y Always accept remote host key if unknown
-s Request a subsystem (use for sftp)
-i <identityfile> (multiple allowed)
-L <listenport:remotehost:remoteport> Local port forwarding
-g Allow remote hosts to connect to forwarded ports
-R <listenport:remotehost:remoteport> Remote port forwarding
-W <receive_window_buffer> (default 12288, larger may be faster, max 1MB)
-K <keepalive> (0 is never, default 0)
-I <idle_timeout> (0 is never, default 0)
-B <endhost:endport> Netcat-alike forwarding
-J <proxy_program> Use program pipe rather than TCP connection
Amendment after 1 day:
The braces do not hurt, with and without its the same result. I wanted to put the ssh authentication to background, so the -f option is not a solution. Interesting side note: if an unexpected option is specified (like -v), the error message WARNING: Ignoring unknown argument '-v' is displayed - even when put in background, so getting output from background processes generally works in my environment.
I tried on x86 Ubuntu regular ssh client: it works. I also tried dbclient on x86 Ubuntu: works, too. So this problem seems to be specific to the TomatoUSB build - or inside the "dropbear v0.52" was an unknown fix between the build in TomatoUSB and the one Ubuntu provides (difference in help output is just the double-sized default receive window buffer on Ubuntu)... how can a process know if it was put in background? Is there a solution to the problem?
I had the similar problem on my OpenWRT router. Dropbear SSH client does not write anything to output if there is no stdin, e.g. when run by cron. I presume that & has the same effect on process stdin (no input).
I found some workaround on author's bugtracker. Try to redirect input from /dev/zero.
Like:
ssh -i yourkey user#remotehost "echo 123" </dev/zero &
It worked for me as I tried to describe at my blog page.

Problems with ${(z)var}

Code:
HOST=localhost
PORT=1234
RSYNCCMD="rsync -avP -e \"ssh -p $PORT\""
${(z)RSYNCCMD} root#$HOST:"\"/foo\"" /bar
Output:
rsync: Failed to exec ssh -p 1234: No such file or directory (2)
...
If I enter the same thing (rsync -avP -e "ssh -p 1234" ...) directly into the console, it works.
How do I fix it?
using ${(Q)${(z)RSYNCCMD}} might work for you (instead of ${(z)RSYNCCMD})
(${(z)RSYNCCMD} seems to be expanded to rsync -avP -e \"ssh\ -p\ 1234\", (Q) does an additional unquoting magic)