Have a look at the following post:
How to telnet google using command prompt?
I've tried the same thing, but keep getting a Bad Request! (400!) I'm working on a Windows 8 PRO machine. I just want to try a few things using Telnet, but as long as I keep getting this 400-error I can't really achieve much!
All I'm doing is the following:
o www.google.com 80 (PRESSING ENTER TWICE!!!)
GET / HTTP/1.1 (ENTER)
Host: www.google.com (PRESSING ENTER TWICE!!!)
Any help appreciated!
This problem can be solved by typing in the Telnet Commands exactly, so capitalize where needed and vice versa! Check this source for more detailed information on how to setup Telnet as a Instant HTTP Client. The source also explains that once you use a BACKSPACE to retype a command that the server receiving the command may interpret it as
<bs>
and if so, declares it as an illegal request! (This is what happened to me!)
Conclusion
It seems that you can communicate the Backspace-character properly if you have the host and client communicating properly! There's an article here that explains more about it on a technical level. To get this to work for the Windows Telnet Client, I do not know how and I'm not sure whether its possible! To get around this I would like to suggest using a program like PuTTY which is a free (MIT-licensed) Win32 Telnet and SSH client. There's an option available in the PuTTY client that allows you to change how the Backspace is generated in PuTTY, that is, which one is acceptable to you're host (if at all!)!
Please read the documentation section 4.4.1 for configuring this option "properly" (if all hosts are using this protocol; otherwise you probably need to read this article and somehow configure PuTTY to be accepted by you're host or vice versa!)!
Also, in the previous example I used Google which may need other parameters to get that working, but this may not have been the best choice to get a 200-status code immediately! Try bing.com instead (working for me at the moment!)!
o www.bing.com 80 (press ENTER twice!!!)
GET / HTTP/1.1 (press ENTER)
Host: www.bing.com (press ENTER twice!!!)
Related
For an application I had to develop a simple telnet module. (Which I could do quickly with the help of minimalistic telnet)
I did create a telnet server and a client and I used PuTTY to test the behavior of the server.
PuTYY was configured for 'Telnet negotiation mode: active'.
In the server I did see the expected telnet negotiation sequence (and it was giving correct replies).
The last action in the PuTTY negotiation was a strange one.
0xff 0xfe 0x32 or IAC DONT 0x32
The third byte, 0x32, is the option and that is where the problem is (for me).
I did look up all Telnet options at IANA and according to them the options range 50-137 is unassigned (0x32 is 62).
What is behind PuTTY option 0x32?
I have looked on the internet but can't find anything.
I have looked up the PuTTY documentation, same thing.
Putting up a request to the PuTTY development is severely discouraged due to capacity problems (not enough hands to type a sensible reply).
It is perfectly sensible not to use this unknown option but it still is nagging me.
What is option 0x3e supposed to do?
Problem solved.
There was an error in my server code causing PuTTY to generate a reply for a non existing option.
I hereby thank Simon Tatham for the suggestion he gave leading me to find the real problem.
I am trying to monitor https traffic with Fiddler, using current newest version:2.4.4.5
I've successfully set up https, certificates and I can see the full https encrypted traffic for example browsing my bank's web site.
...however...
When I trying to monitor an other server I got this error message in the response window:
"Failed to secure existing connection for 77.87.178.160. A call to SSPI failed, see inner exception. InnerException: System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm"
For full Fiddler window see:
The client is not a in this case browser, but a custom client program, which communicates with its own server.
My question: Is this exception misleading and in reality some other error prevents the secure channel to set up?
...or...
We have still chance to monitor this https communication?
Thx in advance
What is the client program?
This error typically indicates that that client application is only offering certain HTTPS ciphers, and those ciphers are not supported by Fiddler.
However, in this case, the specific problem here is almost certainly this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx
The client is trying to use AES with SSLv3, but that isn't one of the valid ciphers for SSL3. As a consequence, the connection fails.
You might be able to workaround this by clicking Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
Please let me know if this works.
NOTE Current versions of Fiddler offer a UI link for this: Look at the lis of enabled protocols on the HTTPS tab.
Unbelievably this issue is still present some 6 years later.
Just installed the latest version of Fiddle (v5.0.20194.41348), and sure enough on Win7 using Chrome or IE it keeps failing with the dreaded error:
"fiddler.network.https> HTTPS handshake to google.com (for #1) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm"
After some hours of testing, I found a middle ground solution which seems to work with virtually all websites. The aim was to get the highest possible security with no errors in the log. Without needing to add any code, simply changing this line under Tools > Options > HTTPS > Protocols is what worked for me (just copy and paste it):
<client>;ssl3;tls1.1;tls1.2
Basically removed the ssl2 and tls1.0 protocols which leaves us with some pretty decent security and no errors so far. Having spent hours of frustration with this error, hope someone out there might find this useful, and a big thanks to EricLaw who discovered the root of the problem.
Yes I too have seen this error when working outside of fiddler and it was connected with AuthenticateAsServer but only went wrong when using IE10 and not Chrome as the browser.
Odd thing is that it did not break all the time for IE10 using SslProtocols.Tls for the protocol so I will add a bit of code to switch the protocol if one fails
The protocol that can be used also seems to change on if you are using a proxy server like Fiddler or using an invisible server by hijacking the DNS via the hosts file to divert traffic to the server
I was trying telnet into a Web server and send a multiline request message. I have to include in the request message the If-modified-since. I made settings for Win7.
For instance when I type telnet edition.cnn.com 80 on my command prompt, it opens a black empty screen, I don't see any thing that I type.
Then I wrote this line on the black screen GET pageName HTTP/1.0, it returned 400 Bad Request Error and says connection closed. What should I do? I used get pagename for an example.
If you want to use e.g. a telnet client to manually get web-pages, you have to remember the format of a HTTP request header:
GET pageName HTTP/1.0
additional header
additional header
Note that the last line is an empty line. You might also need HTTP/1.1 for certain headers to make sense. Please read a HTTP specification for more information and what headers are standard.
The "black screen" is simply the telnet program running in a command window.
400 is an HTTP error code, meaning you did succesfully send a message to the server, it was just invalid HTTP (probably a simple typo)
The black screen and not seeing what you type is 'normal' behavior for telnet (at least I always had that).
If you use a tool like Putty you can see what you type, so it becomes easier to do this sort of thing, and spot your typo.
See the tutorial here: http://www.hellboundhackers.org/articles/571-spoofing-http-requests-with-putty.html
Hope this helps you.
If you need to anything other than basic interaction with the web server I'd suggesting using a tool specifically made for the job, for example cURL. It will allow you set headers etc.
curl -H "If-Modified-Since:04-Nov-2012 11:59:00 GMT" http://host.com/21838937.asp
I'm having issues with using the following format using WinSCP
open sftp://user:password#site.com
vs. this, which works with the console and GUI:
open sftp.site.com.
I would like to automate logging in through the command line but when I try with sftp://user:password#site.com I get a timeout.
Any ideas?
It works fine for me both ways. Is the problem that you are using site.com instead of sftp.site.com in your first example?
Just because you specify the protocol sftp, doesn't mean it will attempt to connect to sftp.site.com when you provide site.com as the host. You still need the full hostname, the sftp:// just tells it what protocol you want to speak once connected.
I'm sending a command to a Mikrotik router using Telnet.
telnet 192.168.100.100 -l admin
Password: pass1234
[admin#ZYMMA] > /interface pppoe-server remove [find user=aspeed13]
[admin#ZYMMA] > quit
It works fine.
Now I want to automate it using expect tcl script:
#!/usr/bin/expect --
spawn telnet 192.168.100.100
expect "Login:"
send "admin\r"
expect "Password:"
send "pass1234\r"
expect "\[admin#ZYMMA\] >"
send "/interface pppoe-server remove \[find user=aspeed13\]\r"
expect "\[admin#ZYMMA\] >"
send "quit\r"
It works, but after authentication (line 6: send "pass1234\r") when the Router CLI is loading it freezes for ~10seconds with the following characters ^[[?6c^[[24;3R
Then the scripts runs ok.
My question is why Telnet loads fast when accessed manually and it takes too much time when accessed via expect script? I read in forums about telnet automation they say telnet is slow, but since manually it's too fast why it takes time to load with expect?
What you're seeing is blow-back from terminal negotiation, which is because you're not running in a real terminal. (Strictly, you are – that's expect's magic – but it's not behaving as a normal terminal does.)
The easiest fix is to set the terminal to something else before spawning the telnet session, e.g.:
#!/usr/bin/expect --
set env(TERM) dumb
spawn telnet 192.168.100.100
# Rest of your script goes here ...
Alternatively, you could try to respond correctly to the request to enter VT102 mode and the report of the cursor location (which feels like a lot of work) or you could rewrite your code so that it does everything inside interact (which connects the other end with the real terminal that you're running inside). But if setting an environment variable fixes it, why go to all that extra hassle?
(NB: I suggest setting the terminal to dumb here, but the key is that you want the stupidest terminal that works. Dumb terminals are ideal, because they're just about totally stupid, making it easy to pretend to be them…)
My answer is possibly too late. This is "Telnet autoconfig command"...I was this problem and found at Mikrotik Wiki this solution:
Add +t after login name. This switch autodetect to off.
Example:
send "admin+t\r"
It is works great and not "wait cca 10 sec" after login by expect.
There is link to Mikrotik WiKi help with more "switches":
http://wiki.mikrotik.com/wiki/Manual:Console_login_process#FAQ
P.S.: Sorry for my English.
Did you try with netcat, with telnet emulation enabled?
A little bit late to answer.
But if you want to speed up your character input with expect.
Try to generate the script with "autoexpect" command, which will save the
interaction in a file named "script.exp" in the same directory from where
you ran the command.
For instance:
cd $HOME
autoexpect telnet 192.168.100.100
# some more telnet commands here
exit
All the above commands will be saved in ~/script.exp
About Tcl, I don't know if ths script can be ran via tcl.