Can’t create SSH session to deployment machine

[murrellr]

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.

 PID TID PPID USER GROUP STAT COMMAND COMMAND
 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.

 

[murrellr]

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

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

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@172.23.165.1 ls
root@172.23.165.1's password:
BSP-VERSION.txt README.txt debug.sh initialized
Connection to 172.23.165.1 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 9 months, 4 weeks ago by murrellr.

[support]

Hi,

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.

 

[Author]

Posts