can Telnet via SSH log into email server? am getting auth error - telnet

I am using Telnet on an Ubuntu 18.04 Server being accessed via SSH. I log into the email server being set up that uses PostFix and DoveCot, to test if the "phil#xxxxxxx.com" mail account is working.
This is the exchange:
root#xxxxxxx:/var/log# telnet xxxxxxx.com 110
Trying 2600:3c01::f03c:92ff:fe93:5fa0... Connected to xxxxxxx.com.
Escape character is '^]'. +OK Dovecot (Ubuntu) ready.
USER phil +OK
PASS fakepassword
-ERR [AUTH] Authentication failed.
I'm not trying to solve the entire mystery here, but just wanted to check on whether this is a valid use of Telnet. A website about using Telnet states the following:
However, you should note that Telnet is not encrypted. Most public
internet services, such as Google or Yahoo, require an encrypted
connection—which isn't supported by Telnet.
Is this a situation were the lack of encryption might contribute to the authentication failure? I'm guessing not, since I'm not going through a browser. I just wanted to verify that if everything was set up right, this would be a valid way to test the email account.

Yes, you can use telnet for protocol exploration. POP3 in this case is text based and not wrapped in TLS, so it works out without any other advanced tools (eg openssl).
That said you will want to familiarize yourself with the POP3 AUTH exchange, which is probably not going to accept credentials in cleartext these days. (If this were 1999, different story.)
https://ietf.org/rfc/rfc1939.txt
You might consider using an actual email program (MUA in the parlance) to negotiate the connection, in tandem with a protocol sniffer like wireshark to see how the exchange works.

Related

Decrypting SSL3.3 (SSL3 TLS1.2) with Fiddler4

I'm working with Delphi and using Indy components for SSL connection. I had Fiddler2 running and was able to see SSL traffic, but had to upgrade Indy to newer version because it had some errors. For compatibility between Indy and OpenSSL I also upgraded to OpenSSL1.0.2a. After this upgrade it seems that it has switched to SSL3.3 a newer protocol than what was used before. I installed Fiddler4.5, .NET framework 4.5 and enabled TLS1.2 as descriped on http://blogs.telerik.com/fiddler/posts/13-02-11/fiddler-and-modern-tls-versions. I also reimported Fiddler's certificate to my trusted root certificates, however i can still not decrypt the SSL traffic.
Following is written in Fiddler:
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
Fiddler's HTTPS Decryption feature is enabled, but this specific tunnel was configured not to be decrypted. Session Flag 'X-No-Decrypt' was set to: 'PeekYieldedUnknownProtocol'.
A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
I tried to search Indy and OpenSSL source for the string "X-No-Decrypt", but it does not seem to be included anywhere. Accoring to fiddlers documentation it seems to be a string that you can include if you dont want fiddler to decrypt this particular session, but i have no idea where this string is included from.
Any suggestions?
Thanks /Rune
The text PeekYieldedUnknownProtocol indicates that when Fiddler looked at the first bytes sent by the client within the CONNECT tunnel, those bytes were not those of a HTTPS handshake. To avoid breaking whatever type of traffic is flowing through the tunnel, Fiddler simply passes the bytes back and forth without interpreting them.
To debug this further, your best bet would be to contact me using Help > Send Feedback in Fiddler. If you can send me a SAZ File (File > Save Session Archive) containing the traffic, I can investigate this problem further.
If you can't share a SAZ file, please at least right-click on the CONNECT in the Web Sessions list and choose Properties. Update your question with the value of the x-CONNECT-Peek flag.

WinSCP commandline: Hostkey not found in cache error

I am trying to connect to Unix server from WinSCP commandline for the first time.
It closes with the the following error:
The server's host key was not found in the cache. You have no guarantee that the
server is the computer you think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 1024 42:9e:c7:f4:7f:8b:50:10:6a:06:04:b1:d4:f2:04:6d
If you trust this host, press Yes. To connect without adding host key to the cac
he, press No. To abandon the connection press Cancel.
In the WinSCP commandline, it does not ask for any input (Yes or No). It closes with Authentication failed. If I connect through the WinSCP tool, I'll get the same error. However, I'll be able to press YES.
I also know that If I add -hostkey switch in the command line, I'll be able to connect. But, I don't want pass hostkey in my batch script as I will be connecting to various servers. So, my requirement is to pass "YES" input from the commandline in case of this error. Can someone help?
A host key fingerprint verification is a crucial step in securing your SSH connection. Even if you are using a set of sessions with your script, it does not excuse you. The fingerprint should be part of a set of information you have for each of the sessions (in addition to a hostname, an username and a password).
Skipping the fingerprint verification means that you lose any security and there's no point using an SSH/SFTP anymore.
Anyway, if you do not care about a security, you can use the -hostkey=* switch to unconditionally accept any host key.
Further references:
Where do I get SSH host key fingerprint to authorize the server?
Verifying the host key

Google Cloud SQL Authorized Network can't connect

I'm trying to connect to my Google Cloud SQL instance from my desktop but am getting the following error:
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
According to the docs this means that the client's IP isn't authorised to access the instance. I have done the standard "what's my ip" google search and added the IP to the "Authorised Networks" list of the instance (as well as a bunch of variations and /x ranges - none have worked, yes I restarted the instance). I have set a root password and even tried connecting with the necessary SSL certs - yields the same error.
I can connect to other (non-google) sql databases, I can ping the database, and I'm not behind any significant firewalls.
How i'm typically trying to connect (also tried SSL):
mysql --host=the.instance.ip.add --user=root --password
Nothing I try seems to work.
I feel like I must be missing something obvious - any suggestions welcome (this is a nightmare).
Could you check again if you have authorized the correct IP address.
If using your desktop from home, you may be having a private IP address for the desktop. What you really need to authorize is the public IP address.
The "what's my ip" search on Google doesn't currently work properly when the ISP is proxying the web traffic transparently. Better information on the IP seems to be provided by Proxy Test from http://www.lagado.com/proxy-test.
Make sure that the IP you are using is the public IP, keep in mind that this can change from time to time depending on your Internet provider. The easiest way to authorize any network is to add 0.0.0.0/0 to the witelist
I check my ip addres in this page https://www.whatismyip.com/es/

How HTTP servers accepts Telnet

I understand that Telnet is a protocol as much as HTTP. I have this notion that after the initial TCP connection is made the Telnet client would send some telnet specific code over to the server on the other side in this case a HTTP server. But since HTTP server doesn't understand Telnet specific codes it should throw an error or drop the connection etc. But in reality we can telnet to a HTTP server and fetch pages if we type in correct HTTP headers and send them. How can it be like that? Wikipedia entry really didn't help me to understand this specific point. (http://en.wikipedia.org/wiki/Telnet#Telnet_data)
Telnet is just an easy interactive way to open a TCP connection to a listening socket. Because the telnet client blindly sends what you type to that socket, it can theoretically emulate any other protocol on top of TCP. Actually the fact that non printable chars are interpreted by the keyboard driver is the only limit.
HTTP does not use non printable chars except to delimit between the HTTP header and the body with two consecutive "line breaks" (i.e. a "blank line").
Please note that I'm not talking about the HTML body tag here, but the payload (e.g SOAP body).
No magic here basically.
Let's see the dynamic of things.
HTTP supports a number of commands like GET, POST, PUT etc...
Each command has its syntax and there is an associated response with an agreed upon syntax and well defined error codes.
When you connect to an HTTP server using telnet, you open the socket connection and the server forks a thread to manage the dialog with your client. You can then mimic a browser by typing the command that the browser would send. Each time you strike the CR key, the client submits the line to the server. If a command contains several lines, you can enter several lines, each of them corresponding to a line of the command header. Once you strike two CR in a row (i.e. an empty line), the command header is deemed complete by the server and the response is put together and sent back to your client. Because a telnet client's life goal is to echo received characters (unless told otherwise), then you can see the response header and body on your terminal window. Telnet stops there. A browser would render the HTML (if the response is an HTML page).
I hope that clarifies it all.
You are right in saying that telnet is its own protocol, which is described in a couple of RFC's. You can take a look at wikipedia to see which ones exactly and some other resources that explain the protocol.
Basically it works like this: when you use telnet to connect to a server, it will show every printable character the server sends to you. And everything you type will be sent back to the server. This is how you can retrieve web pages when connecting to a web server: you send a command that a http server accepts and get the correct result.
Now, there are a few telnet specifics option. IIRC, you won't send them to the server unless the server sends them first. Those options are used to enable/disable local echo (think about passwords, you don't want those visible when logging in), negotiate terminal size, negotiate end of line type. Those are commands that are a few bytes long and start with byte 255 (called IAC, interpret as command). When you connect to a telnet server, your client will interpret those and reply accordingly, all automatically in the background, without showing you those commands.
Although not specific to telnet, a telnet server can also send ANSI escape sequences. Those are used for colors, bold, cursor positioning, ... A telnet client will also interpret those (or just pass them on to the terminal emulator you're using, like xterm).
If you want something "lower-level" than telnet, which won't interpret telnet options and actually display what you get, you may want to take a look at netcat
You can query a http server using telnet, I often do as a quick and nasty test
telnet doesnt send any codes. it just makes the connection, but there are telnet specific codes you can send if you require
do this...
telnet server.com 80
GET http/1.0 /^m
host: server.com^m
^m
... servers response
^m = enter key
I have done this is done in linux in windows it may be different.
DC

POP3 netcat protocol error

I tried to connect to my POP3 school server as part of my assignment. Now, I can connect to the server but the real problem is when I try to log in using the "USER" command.
c:/>nc server.pop3.com 110
+OK Microsoft Exchange Server 2003 POP3 server version 6.5.7638.1 (server.pop3.com) ready.
USER myuserid
-ERR Protocol error
Now I'm wondering whether there's an issue on my side or on the server? Thank you for the time and answers.
Exchange expects a CRLF as line termination.
Use
netcat -C servername pop3
Use CAPA command just after connection.
You'll see what login mechanisms are supported.
Exchange usually does not allow clear text mechanisms. Most likely you'll be forced to use SSL+plain text, or APOP login mechanism.