The initial connection messages from the telnet-ssl client:
Connected to othersite.mydomain Escape character is '^]'. [SSL - attempting to switch on SSL]
include "attempting to switch on SSL", indicating that the client doesn't simply start with the SSL connection negotiation once a basic TCP connection is established, but there is some sort of Telnet protocol handshake first, that includes some way to say "I would want to use encryption". And apparently the server side does not begin the SSL negotiation until it sees that. So it would actually be something similar to STARTTLS, not just plain SSL.
Debian's openssl s_client has the -starttls <protocol> option, which would be just the thing for situations like this. Unfortunately, it does not seem to include support for the Telnet protocol.
According to this expired Internet Draft, as soon as the TCP connection opens, the server should be sending the Telnet protocol message IAC DO START_TLS, which would be three bytes on the TCP connection: 0xff 0xfd 0x2e in hexadecimal. That matches the SSL handshake has read 3 bytes and written 0 bytes message.
The client would have to answer with another Telnet protocol message that acknowledges it's able and willing to make SSL/TLS encrypted connections, and then another pair of messages would be exchanged to mark the actual start of the SSL/TLS negotiation. But because your openssl s_client doesn't know how to speak Telnet, it cannot give the server the answer that would allow the SSL/TLS negotiation to begin.
Unless you find a version of openssl s_client that includes STARTTLS support for the Telnet protocol, I would guess the only way would be to use tcpdump to capture the connection negotiation done by the real telnet-ssl client, and then use wireshark or similar to analyze the results.
The procedure would be: 1.) Have two terminal windows open. 2.) In the first window, start the capture:
sudo tcpdump -i <network interface> -s0 -Knpvv -w telnet-ssl-dump.cap host othersite
3.) After entering the password for sudo (if necessary), leave that command running, move to the second terminal window, and run your telnet-ssl command there. You should see a counter of captured packets increase in the first window.
4.) You don't have to actually log in: as soon as you see the remote login prompt, the SSL/TLS negotiation should be done and you can stop the packet capture by moving to the first window and pressing Ctrl+C.
Now in the session of the first terminal window, you should have a telnet-ssl-dump.cap file, which you can analyze further.
Wireshark is a professional-grade network traffic analyzer with a GUI interface. It is best to run it in your local workstation. If your local system is Linux, you can probably find it in your distribution's package repositories. For Windows, you can download it from the link above.
If you give Wireshark the name of the packet capture file as a parameter, it won't require any special privileges, so run wireshark telnet-ssl-dump.cap. Without any parameters, Wireshark will assume that you are planning to start capturing traffic, and may show you some questions about network interface(s) to use. But when started with a packet capture file, it should immediately show a list of captured packets. You can select one of them to see a detailed breakdown of it as far as Wireshark can parse it. Find the packets that contain the SSL/TLS protocol negotiation, and you should be able to see which encryption algorithm gets chosen and other connection details. If you see the packet contents listed only as <encrypted data>, you went too far, and are looking at the SSL/TLS encrypted datastream after the negotiation has completed.
