2

I have a simple openssh server running in a Alpine Linux 3.15 Docker container, and a another container, also running the same version of Alpine of the SSH server) that runs a X server with dwm

I'm connecting to the SSH server (and running st) from the X server with the following command:

ssh -v -t [email protected] st

The SSH server is being executed with the following command:

/usr/bin/sshd -D -d -e

The $DISPLAY variable gets set to ssh:10 (ssh being the SSH server hostname)

The client is able to open a graphical application (st) through X11 forwarding from the server to the client display, the problem is that i can only open a single instance of st before receiving the following error:

ssh: connect to host 172.17.0.2 port 22: Connection refused

server-side log:

Starting session: command on pts/1 for client from 172.17.0.3 port 34060 id 0
debug1: Setting controlling tty using TIOCSCTTY.
debug1: X11 connection requested.
debug1: channel 3: new [X11 connection from 172.17.0.2 port 35028]
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 9
debug1: session_exit_message: session 0 channel 0 pid 9
debug1: session_exit_message: release channel 0
debug1: session_by_tty: session 0 tty /dev/pts/1
debug1: session_pty_cleanup2: session 0 release /dev/pts/1
debug1: channel 3: free: X11 connection from 172.17.0.2 port 35028, nchannels 4
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
debug1: session_close_x11: detach x11 channel 1
debug1: session_close_x11: detach x11 channel 2
Close session: user client from 172.17.0.3 port 34060 id 0
debug1: channel 0: free: server-session, nchannels 3
debug1: channel 1: free: X11 inet listener, nchannels 2
debug1: channel 2: free: X11 inet listener, nchannels 1
Received disconnect from 172.17.0.3 port 34060:11: disconnected by user
Disconnected from user client 172.17.0.3 port 34060
debug1: do_cleanup
debug1: do_cleanup

client-side log:

Running /usr/bin/xauth remove ssh:10.0
/usr/bin/xauth add ssh:10.0 MIT-MAGIC-COOKIE-1 49907415ff518044198f6f0075f270fe
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 172.17.0.2 35028
debug1: channel 1: new [x11]
debug1: confirm x11
OpenSSH_8.8p1, OpenSSL 1.1.1l  24 Aug 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 172.17.0.2 [172.17.0.2] port 22.
debug1: connect to address 172.17.0.2 port 22: Connection refused
ssh: connect to host 172.17.0.2 port 22: Connection refused
xinit: connection to X server lost

waiting for X server to shut down debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 1: free: x11, nchannels 2
X connection to ssh:10.0 broken (explicit kill or server shutdown).
debug1: channel 0: free: client-session, nchannels 1
Connection to 172.17.0.2 closed.
Transferred: sent 91292, received 92728 bytes, in 3.1 seconds
Bytes per second: sent 29350.8, received 29812.5
debug1: Exit status 1
(II) Server terminated successfully (0). Closing log file.

deallocvt: can't open console
4
  • Please edit your question to show how sshd is being invoked on the server in sucha a way that you're capturing debugging output.
    – Kenster
    Mar 7, 2022 at 16:48
  • @Kenster just added the requested details to the answer Mar 7, 2022 at 17:42
  • I was hoping to see how the ssh server was being invoked (and how you're capturing debug output for it), not the ssh client.
    – Kenster
    Mar 7, 2022 at 18:00
  • Sorry, i misinterpreted you comment, i added it to the question Mar 7, 2022 at 18:38

1 Answer 1

4

You say that you're running sshd using this command:

/usr/bin/sshd -D -d -e 

The "-d" option is used for debugging. It has this effect:

Debug mode. The server sends verbose debug output to standard error, and does not put itself in the background. The server also will not fork(2) and will only process one connection. This option is only intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is 3.

The behavior that you describe, in which sshd only accepts one connection and then no more, is exactly what you'd expect to see with the "-d" option in effect.

If you want to get the same behavior that you're getting now, only with sshd handling multiple connections, this should do it:

/usr/bin/sshd -D -e -o LogLevel=DEBUG1
  • The "-D" option causes sshd to run in the foreground.
  • "-e" directs logging messages to sshd's standard error.
  • "-o LogLevel=DEBUG1" enables debug1-level logging.
1
  • 1
    Thank you very much! i've read the documentation for both ssh and sshd CLI's, but i missed this small detail of the -d flag Mar 7, 2022 at 19:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .