How to suppress exp_spawn translating " to \? - tcl

I am using tcl8.5 on windows 7. I need to use spawn with openssh. The username has double-quotes (e.g. abc"). I can use openssh to login the remote device with this account when I am using it in a command window:
D:\Program Files\OpenSSH\bin>ssh 192.168.0.253 -labc"\""
...
abc"#192.168.0.253's password:
(the correct username is displayed by openssh)
However, when I use spawn ssh with the same syntax in a script, the " is translated to \
When I enter the correct password, access is denied.
exp_spawn "$sshClient" "192.168.0.253" -labc\"\\\"\"
=>
abc\\""#192.168.0.253
The following attempt also shows " being translated to \
exp_spawn "$sshClient" "192.168.0.253" -labc\"
=>
abc\#192.168.0.253
Could anyone show me the correct syntax please? Or is there any option in exp_spawn I need to enable?

Try
exp_spawn $sshClient 192.168.0.253 {-labc"}

Related

expect garbage before prompt

I try to connect to my router using ssh in order to automatically extract some logs from it.
I developed this code below :
#!/usr/bin/expect -f
spawn ssh root#192.168.1.1
expect "Are you sure you want to"
send -- "yes\r"
expect "password"
send -- "root\r"
expect "\#"
send -- "ls\r"
expect "\#"
the problem is I expected a garbage before the prompt in the output log.
spawn ssh root#192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is SHA256:6aeE74qXMeQzg0SGJBZMIa0HFQ5HJrNqE5f3XZ6Irds.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/amin/.ssh/known_hosts).
root#192.168.1.1's password:
BusyBox v1.30.1 () built-in shell (ash)
OpenWrt Version: ALPHA
OpenWrt base: 19.07
------------------------------------
]0;root#openwrt: ~root#openwrt:~# ls
[0;0mnetwork[m
]0;root#openwrt: ~root#openwrt:~#
what's the main cause of this issue? How I can fix it?
The problem is that there are terminal escape sequences being issued, probably to control what colour the terminal uses. The easiest fix is to set the terminal type (an environment variable) to something that doesn't support colour before doing the spawn. Perhaps this will do the trick:
set env(TERM) "dumb"
If that doesn't work (it depends on exactly what is in someone's .bashrc) then you can just override the PS1 environment variable on the remote side with your first command after logging in.
# etc for logging in
expect "# "
send "PS1='# '\r"
expect "# "
# Everything should be right from here on

Passing user and password in URL doesn't work

I have some URL like this : X.XXX.XXX.XXX:10080
I tried to add a user and password in this url like this: http://OLM:OLM794$#X.XXX.XXX.XXX:10080
User = OLM
Psw = OLM794$
And it doesn't work
Also when I run : curl http://OLM:OLM794$#X.XXX.XXX.XXX:10080 it shows me :
curl: (6) Could not resolve host:OLM:OLM794X.XXX.XXX.XXX, it removes $# and the port :10080
When I try : curl -u OLM X.XXX.XXX.XXX:10080 then I enter the password, it works, Im able to connecte to that server.
My need is to call my url with user and password like this:
http://OLM:OLM794$#X.XXX.XXX.XXX:10080
But it doesn't work.
I read this solution : Using cURL with a username and password? but I haven't found solution
Have you an idea why ?
It would seem curl parses and reconstructs the URL, leaving out characters that it thinks are illegal. For me, the same command gives a different error though.. It could be that your curl version differs from mine.
$ curl -v http://OLM:OLM794$#127.0.0.1:10000
* Rebuilt URL to: http://OLM:OLM794127.0.0.1:10000/
* Port number ended with 'O'
* Closing connection -1
curl: (3) Port number ended with 'O'
The solution is quite trivial, just url-escape the $ symbol: %24:
$ curl http://OLM:OLM794%24#127.0.0.1:10000
According to RFC1738, the dollar-sign was allowed as an unreserved character and could be directly used, but this old RFC has since been updated many times. RFC3986, for example, does not mention it as an unreserved character anymore. This means the $ symbol has received a special meaning and should be encoded in any URL where it does not serve the function it was given.

How to run mysql in a command prompt using AutoIt?

I tried to run a command prompt and log in into mysql.
Run(#ComSpec & ' /k' & 'cd'&' '&#ScriptDir&'/mysql/bin')
this works perfectly. But When I add the mysql command like below, it doesn't work. It displays a 'path not found' error message:
Run(#ComSpec & ' /k' & 'cd'&' '&#ScriptDir&'/mysql/bin/mysql u- root -p')
I would appreciate if anyone could show me the correct way to go.
You don't need to change your directory (cd) when you want to actually execute a program. The error message tells you, there is no directory #ScriptDir/mysql/bin/mysql - and there isn't. The directory #ScriptDir/mysql/bin/ most likely exists and there most likely is an executable mysql inside...
So just use two commands separated by ; instead:
Run(#ComSpec & ' /k' & 'cd ' & #ScriptDir & '/mysql/bin; mysql -u root -p')
You need to separate between the cd and the actual call of mysql. And you'd propably want to correct u- to -u.

Mysql database restoring with fab and curses in django

#hosts(['localhost'])
def start():
import curses
screen = curses.initscr()
backup_file = db_backup.sql
local("mysql -u %s -p %s < " % (
db_username,db_name) + backup_file)
now I run this with fab start
it asks for a password, after I entered the password the screen is not responding.
Can anyone know what's happening here? if I remove curses it is working fine.
The local command is doing the prompt for the password. That expects that the terminal modes are set normally, so that if you press Enter (which sends a ^M) it is mapped into a newline (^J).
When you initialized curses using curses.initscr, that changes the terminal modes so that the mapping is not done. The curses library does its own mapping when you call getch.
If you press controlJ rather than Enter, that should appease the password prompt in the local command.
Since your example is not using curses (perhaps it does later) you can either omit it, or move the initialization down to the place where you need to use it.
In any case, you probably cannot make the local command use a password prompt in the script via curses (without assuming and relying upon special devices).
By suspending the curses, it will return to the terminal. where we can complete the restore database task.

SQLMap realy slow on local network

i'am currently trying to use SQLMap on an apparently easy injection on a local web server :
SELECT * from table WHERE `col` LIKE 'VULN_HERE';
I'am using the following command :
sqlmap -u http://localhost/?i=1 --dbms mysql --level 5 --risk 3 -p i --dbs -v 2 --technique 'T'
When running this command, sqlmap identify the injection correctly but is blocking at :
[14:36:43] [INFO] checking if the injection point on GET parameter 'i' is a false positive
What is wrong ?
I think your URL shall be quoted :
sqlmap -u "http://localhost/?i=1" ....
Hi check your syntax and have a look:
SQLmap
You need your URL to be within quotes always or the command prompt will take i=1 outside the URL and as a different parameter.
Hope it'll solve your issues.