Local echo off after password request, never back on?

Nov 5, 2009 at 1:20 AM

Hello. I'm rather new to SSH, so I may be missing something obvious, but the local echo (when connecting from Putty) stops for password entry, which is normal, but then it never turns back on - so real type key press feedback stops at that point. Is that expected? Is there a way around it, so I can see what I'm typing at the remote terminal? I tried forcing local echo on in putty, but this causes double characters to display when entering username, due to server side echo I presume combining with putty's simulated echo. Thanks for your time. Love your library. I've made a few small mods, to allow for logging into a domain (not just local machine) and for allowing the server to listen to Any instead of a specific IP (maybe this is possible with a specific IP string? I couldn't figure it out if so...). Let me know if you want them and I will submit.

Nov 5, 2009 at 3:47 AM

Nevermind the binding to Any thing - I guess using 0.0.0.0 is what triggers that.

Coordinator
Nov 5, 2009 at 12:21 PM

Hi,

The lack of a local echo is just due to the implementation of the BaseProcessConsole and cmd.exe. I assume when you run cmd.exe as a window it performs a local echo of sorts but when using it through NSsh even though we send each character as we get it to the cmd.exe process it only echos them back in one hit after a command is executed. It might be possible to echo characters manually and then chop them out of the response from cmd.exe but I haven't looked into it.

If you could submit any improvements via a patch in the "Source Code" tab it would be great! And yes you are correct 0.0.0.0 is the string to listen on all interfaces.

 

Cheers,

 

Luke

Nov 5, 2009 at 2:14 PM

That makes sense. Seems like it might be kind of tough to force in a robust way as it doesn’t seem like there is a strong boundary between request/response in this type of communication,  so I guess it is what it is J I’m probably going to need to write my own IShell then, to provide a remote shell for my IronRuby environments – in that implementation, I should write each input character to the output as it arrives? That is how it is usually done?

From: tmyroadctfig [mailto:notifications@codeplex.com]
Sent: Thursday, November 05, 2009 5:22 AM
To: Nathan Stults
Subject: Re: Local echo off after password request, never back on? [NSsh:74132]

From: tmyroadctfig

Hi,

The lack of a local echo is just due to the implementation of the BaseProcessConsole and cmd.exe. I assume when you run cmd.exe as a window it performs a local echo of sorts but when using it through NSsh even though we send each character as we get it to the cmd.exe process it only echos them back in one hit after a command is executed. It might be possible to echo characters manually and then chop them out of the response from cmd.exe but I haven't looked into it.

If you could submit any improvements via a patch in the "Source Code" tab it would be great! And yes you are correct 0.0.0.0 is the string to listen on all interfaces.

Cheers,

Luke

Read the full discussion online.

To add a post to this discussion, reply to this email (NSsh@discussions.codeplex.com)

To start a new discussion for this project, email NSsh@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Nov 5, 2009 at 4:30 PM

One more quick question - the sole purpose of the fifo queue stream in between the console and the process to transform \r into \r\n, or is there more to it than that?

Coordinator
Nov 8, 2009 at 11:14 AM

Echoing the characters as they come in sounds like a reasonable approach to me.

The FIFO queue between the process and the remote client is required because the data make come in asynchronously. It was a handy place to modify the data before sending it to the remote client though.

IronRuby, that sounds interesting!

 

Cheers,

Luke

Developer
Nov 18, 2009 at 4:09 AM

I've come up against the same thing re. the handling of key presses or escape codes sent back to the SSH client. It's not as simple as simply echoing characters back as that does not take into account control sequences like backspace, delete, arrows etc. The old VT100 standard deals with exactly that and I have already cobbled together a very (very, very) minimal VT100 server for NSsh, it handles backspace and the left and right arrows. I'm planning on cleaning it up and checking it in in the next day or so.

Regards,

Aaron