n 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_buf
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
On 2012-04-26, Paul Smith wrote:
> On Thu, 2012-04-26 at 15:33 +0000, Grant Edwards wrote:
>> I'm trying to switch from the openssh server to dropbear's server on
>> an embedded system, and I've run into one snag. I've enabled the
>> "allow blank pas
On 2012-04-27, Laurent Bercot wrote:
>> 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 test
cally "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
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
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 any
