Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm testing server connections using OpenSSL, with varying results

  • Server A: connection is successful, as are user login and the other commands I expected to work
  • Server B: connection is successful, but the server is unresponsive when I try to submit a command. I don't get an error, or even a disconnection – just a blank line from where I hit Enter or ^M

My hunch is that Server B's configuration requires a different character encoding or something and it's simply not recognizing my Enter keystroke, but I've looked to no avail... any suggestions would be appreciated!

share|improve this question
    
Do you mean OpenSSH? –  UtahJarhead Oct 3 '12 at 2:35
    
I connect using openssl s_client -connect server.com:port, in lieu of telnet –  Dan B Oct 3 '12 at 15:53

2 Answers 2

up vote 1 down vote accepted

Turns out my initial suspicion was correct... the server simply wasn't accepting my Enter command. Adding the -crlf flag took care of it:

openssl s_client -connect server:port -crlf

From what I've read, this forces the s_client tool to send a CR/LF when you hit enter, which is needed for a Windows-based server to read. It's likely, then, that Server A worked because it was a *NIX server and Server B is a Windows server.

share|improve this answer
    
Good find Dan. You should accept your own answer. –  Ben Graham Oct 4 '12 at 1:24
    
Thanks, Ben. Looks like there's a 24-hour delay between when you answer your own question and when you can accept it, though. Guess I'll stop back later. Anyway, thanks for your answer! –  Dan B Oct 4 '12 at 3:27

I'm assuming like @UtahJarhead that you mean OpenSSH.

I don't know much about encodings, but I would be surprised to learn that things like space, enter, null etc - low-end ASCII stuff - differed.

  1. Check the shell of Server B's user. Can you get access to that machine somehow and su to that user? Does the same problem occur?
  2. Check the sshd config. Are there any fishy options like ChrootDirectory, ForceCommand, etc? Diff the sshd configs from both servers and see what looks suspect
  3. Debug. Connect to Server B like ssh -vvv user@serverb and look for sus output. My shell allocation looks like:

    debug2: channel 1: request shell confirm 1
    debug2: callback done
    debug2: channel 1: open confirm rwindow 0 rmax 32768
    debug2: channel_input_status_confirm: type 99 id 1
    debug2: PTY allocation request accepted on channel 1
    debug2: channel 1: rcvd adjust 2097152
    debug2: channel_input_status_confirm: type 99 id 1
    debug2: shell request accepted on channel 1
    

    These are the last lines of debug output for me.

Failing any of that - what obvious stuff differs between these machines?

share|improve this answer
    
I don't have SSH access to server B – I'm connecting as a client using openssl s_client -connect in lieu of telnet because the server requires a secure connection. –  Dan B Oct 3 '12 at 15:56
    
Which SSH can provide. –  UtahJarhead Oct 3 '12 at 20:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.