Re: Remote program doesn't terminate when ssh session ends
On 2021-02-25, Catalin Patulea wrote:
> I believe the right way this works it that:
> - ssh client closes session
> - dropbear closes the read end of command's stdout pipe
> - next time command writes to pipe, it receives SIGPIPE and dies
> Thus I don't think dropbear needs to explicitly kill anything. but perhaps
> the mechanism is somehow not working.
>
> I would investigate this by running 'strace' on the remote host and seeing
> if, after closing the session, 1) dropbear closes the pipe and 2) the
> command tries to write to it and receives SIGPIPE.
Thanks for the clue!
The problem is that the executable I ran (ash) doesn't receive
SIGPIPE. What receives the SIGPIPE are the `date` utility and the
`sort` utilities. They die when they try to write to stdout, but the
shell program that invoked them continues to run.
The same thing happens with the openssh server.
In this case I can fix it by setting the `errexit` shell option in the
shellscript I'm running so that the shell will exit when `date` or
`sort` exit with an error. [This would not work if `sort` and `date`
exited with status 0 when receiving SIGPIPE.]
#!/bin/sh
set -o errexit
while true
do
date
cat /proc/[0-9]*/stat |
awk '$23 > 0 {printf "%5d %20s %8d %5d\n", $1, $2, $23, $24}' |
sort -n
sleep 15
done
Another work-aroud is to force allocation of a tty like this:
$ ssh -t root@10.0.0.99 ./showmem.sh
That way when the user presses ctrl-C and ssh client gets a SIGINT,
the SIGINT will also be sent to the members of the tty group at the
server end. However, if the user exits the ssh client by typing "~."
instead of hitting ctrl-C, the program will continue to run as before
Remote program doesn't terminate when ssh session ends
I have a small ash script that prints memory statistics once a second:
#!/bin/sh
while true
do
date
cat /proc/[0-9]*/stat |
awk '$23 > 0 {printf "%5d %20s %8d %5d\n", $1, $2, $23, $24}' |
sort -n
sleep 60
done
When I run that remotely via dropbea:
$ ssh root@10.0.0.99 ./showmem.sh
Everything works as expected while the ssh session is active, but when
I end the ssh connection, the shell script never terminates: it
continues to run (indifinitely, AFAICT). I don't recall this happening
when we used to use openssh's server. Is there any way to get dropbear
to terminate a "child" program when the ssh session closes?
Re: Dropbear on bare-metal ARM Cortex-M3?
On 2012-07-31, Freddie Chopin freddie_cho...@op.pl wrote: I was wondering whether it's possible (in a reasonable amount of time) to port Dropbear to bare-metal platform - one without an OS (like Linux), but with RTOS (FreeRTOS) that provides tasks, queues and synchronization (semaphores + mutexes) + LwIP TCP/IP stack? I would require a very minimal implementation of SSH server, without all possible encryption options (the code/RAM footprint has to be low) and without all possible features - ideally only simpliest SSH server that can pass received strings to other parts of code and transfer strings from code via SSH to connected client. Of course I'm talking only about command-line interface. If Dropbear is not a good option for such task, do you have any other recommendations? I've used (non-free) SSL/SSH libraries from Peersec on a platform similar to what you're describing (using an RTOS different than, but similar to, FreeRTS). I haven't looked at dropbear source code in any detail, but I can tell you that porting network servers written to run on a Unix OS to an RTOS environment can be _very_ difficult. The two main problems are that the servers generally expect to be able to 1) Call fork() to create a server process for each incoming connection. 2) Call exit() after a connection is closed with the assumption that all the resources that were allocated will be auto-magically freed. Coming up with fixes/work-arounds for those two issues alone can be a huge amount of work. -- Grant Edwards grant.b.edwardsYow! Used staples are good at with SOY SAUCE! gmail.com
dropbear still requires password when password is blank
debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/grante/.ssh/id_rsa (0x80b6ea0) debug2: key: /home/grante/.ssh/id_dsa ((nil)) debug2: key: /home/grante/.ssh/id_ecdsa ((nil)) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/grante/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/grante/.ssh/id_dsa debug3: no such identity: /home/grante/.ssh/id_dsa debug1: Trying private key: /home/grante/.ssh/id_ecdsa debug3: no such identity: /home/grante/.ssh/id_ecdsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password root@10.0.0.99's password: debug3: packet_send2: adding 64 (len 49 padlen 15 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). Authenticated to 10.0.0.99 ([10.0.0.99]:22). debug1: Final hpn_buffer_size = 131072 debug1: HPN Disabled: 0, HPN Buffer Size: 131072 debug1: channel 0: new [client-session] debug1: Enabled Dynamic Window Scaling -- Grant Edwards grant.b.edwardsYow! This is a NO-FRILLS at flight -- hold th' CANADIAN gmail.comBACON!!
Re: dropbear still requires password when password is blank
On 2012-04-26, Matt Johnston m...@ucc.asn.au wrote: I assume what OpenSSH is doing is looking whether the user has a blank password at the first none request, and sending success straight away. Ah, I had assumed that the process started out with the server sending a list of acceptable auth methods, and I couldn't find that anywhere. But, I gather than the client just starts sending various auth requests in whatever order it wants until it finds a winner. That seems sensible enough to me, Dropbear should probably do the same so it can be like rshd :) I had forgotten about rsh/rlogin... Have a look at svr-auth.c , search for AUTH_METHOD_NONE. I think the checkusername() test needs to move before the 'none' test (that populates ses.authstate.pw_passwd among other things). Then the none test can apply the same logic for ALLOW_BLANK_PASSWORD as svr_auth_password(). I'll take a look and see what I can come up with. That's a 2 minute look at how Dropbear could be modified, there might be some caveats I haven't noticed. Patches accepted or I might try get it done for the next release. It might seem that hitting enter at the password prompt isn't a big deal, and for interactive use, that's true. The embedded system is set up with a blank password mainly during development and testing because it's a handy way to do automate testing using shell scripts running on the development host. The password prompt breaks that. -- Grant Edwards grant.b.edwardsYow! I would like to at urinate in an OVULAR, gmail.comporcelain pool --
