Can’t create SSH session to deployment machine

Sysprogs forums Forums VisualGDB Can’t create SSH session to deployment machine

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #35384

    VisualGDB version 5.6R9 (build 4827)

    I’m trying to update our target machine from Linux 4.14 to 6.2.0.  I have built the image locally using a custom configuration.  As I am new to kernel builds, I’m certain I have a configuration problem, but I’m having difficulty finding a resolution.  I’m trying to create a new SSH session to our machine.  The user is root. It has to be root because our process is created by systemd and needs root privileges to access resources.  The target is an ARM embedded system running a stripped down Debian Linux.

    When I select Create, the dialog hangs.  On the target, I can see that an SSH login was successful, but the process is sleeping awaiting on an event.

     497 497 251  root root  Ss   sshd    sshd: root@notty
     507 507 497  root root  Ss   bash    bash -c pwd

    The ‘Ss’ means “interruptible sleep (waiting for an event to complete)” and “is a session leader”.  Linux 6 seems to have stricter security than 4.14 and user root may now have more restrictions when logging in over SSH versus a local serial console.  I just don’t know who is causing this and how to override it.  Any suggestions would be appreciated.



    I have a little more information.  From Windows CMD I run this ssh command:

    C:\Devel>ssh root@ ls
    root@'s password:
    stty: 'standard input': Inappropriate ioctl for device
    stty: 'standard input': Inappropriate ioctl for device

    SSH is hung at this point.  I have to Ctrl-C to terminate.  When I add the ‘-t’ switch, it works:

    C:\Devel>ssh -t root@ ls
    root@'s password:
    BSP-VERSION.txt README.txt initialized
    Connection to closed.

    So far, I don’t see any difference in the configuration of SSHD in the new or old Linux versions.


    • This reply was modified 1 month, 3 weeks ago by murrellr.


    This looks like a bug in the SSH server.

    The SSH protocol indeed allows running commands either with or without a PTY and both modes have different semantics. Running programs with PTY allows sending special events like Ctrl-C or wrapping the output to fit the terminal. However, it breaks processing of raw binary data, and forces many commands to assume interactive mode (i.e. they would ask for clarification instead of just returning an error code).

    Based on what you have described, it looks like the non-PTY mode on the SSH server is broken.

    VisualGDB can run commands in both modes, however it highly depends on the context. Forcing it to run everything with PTY would randomly break things like sending files using tar (that will try to interpret escape sequences inside binary data) or make completely unexpected commands hang with something like “press enter to see the next page” where VisualGDB totally doesn’t expect it.

    A better option would be to try building the debug version of the SSH server from sources, run it under GDB, and see why it hangs without the PTY. You may need to patch the server code, or change something in the kernel configuration to accommodate it. If you wish, we could book a consulting session at our consulting rate and help you get this working via Zoom or other screen sharing tool.


Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.