Re: OpenWRT Dropbear v2020.80: Exit before auth: No matching algo kex
Walter Harms wrote: > This is caused by changes in ssh_config. You can try: > ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 USER@TARGET > > or persistent in ssh_config > KexAlgorithms=+diffie-hellman-group1-sha1 > > your mileage may vary etc. > > re, > wh Thanks! This advice has shown me how to connect directly to an old OpenSSH server again (not Dropbear), instead of via intermediate hops on intermediate servers :) However after reading [1] I decided a safer kex is diffie-hellman-group14-sha1 (group14 instead of group1). Mentioning this in case it's also an option for old Dropbear/OpenWRT users. [1] https://tools.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-09.html#rfc.section.3.4 "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)". Best, -- Jamie
Re: bug: stdio pipe is root owned so reopening it fails
Hi Matt, Matt Johnston wrote: > Not really sure of a good workaround. You can fchmod() or fchown() the pipe descriptor, with fchown() being more secure. # echo hello | (ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw--- 1 root root 0 May 1 17:06 /proc/self/fd/0 cat: /proc/self/fd/0: Permission denied # echo hello | (chmod a+rw /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw-rw-rw- 1 root root 0 May 1 17:05 /proc/self/fd/0 hello # echo hello | (chown nobody: /proc/self/fd/0; ls -lL /proc/self/fd/0; sudo -u nobody cat /proc/self/fd/0) prw--- 1 nobody nogroup 0 May 1 17:06 /proc/self/fd/0 hello Best, - Jamie Matt Johnston wrote: > Hi Szabolcs, > > Ah, that's a bit nasty. I guess the difference is that OpenSSH runs the daemon > as the user, while Dropbear runs as root. > > The procfs manpage mentions the problem. [1]http://man7.org/linux/man-pages/ > man5/proc.5.html > > Note that for file descriptors referring to inodes (pipes and > sockets, see above), those inodes still have permission bits > and ownership information distinct from those of the > /proc/[pid]/fd entry, and that the owner may differ from the > user and group IDs of the process. An unprivileged process > may lack permissions to open them, as in this example: > > $ echo test | sudo -u nobody cat > test > $ echo test | sudo -u nobody cat /proc/self/fd/0 > cat: /proc/self/fd/0: Permission denied > > Not really sure of a good workaround.
Re: Single-address space, no processes?
Matt Johnston wrote: > It mightn't be necessary to pass pointers around everywhere if > ses/svr_ses/cli_ses could be thread-local pointer variables - how widely > supported is thread-local storage? If you can get a "current thread id" or set one "thread-local value", you can make thread-local variables in portable C using macros without compiler support. It's not as fast as compiler supported thread-local storage, but it's portable other than function to get the id, and provided you can set the value, it's not necessarily slow. Best, -- Jamie
Re: [Patch] Add SSH_CLIENT environment variable
Matt Johnston wrote: > Thanks, I've merged it with some small changes. > > I keep being surprised bash doesn't have separate > interactive/non-interactive config files, like .zshrc vs > .zshenv It does, if you pass BASH_ENV in the environment. BASH_ENV gives the name of a config file to run only when bash is non-interactive, so you to match that zsh behaviour, you might set BASH_ENV=$HOME/.bashenv. -- Jamie
Re: Configure dropbear to be fast/insecure? (need a Microblaze speed-up!)
Mike Frysinger wrote: > if it's all private / development, why dont you just use telnet w/out login ? Maybe because "ssh command < file > file2" works while it doesn't work with telnet? ssh is a much more convenient and reliable interface. -- Jamie
Re: [PATCH] dropbear-051: uClinux vfork
Rob Landley wrote:
> On Tuesday 21 October 2008 00:01:56 Mike Frysinger wrote:
> > - if ((pid = fork()) == -1)
> > +#ifdef __uClinux__
> > + pid = vfork();
> > +#else
> > + pid = fork();
> > +#endif /* __uClinux__ */
> > + if (pid == -1)
> > fatal("do_local_cmd: fork: %s", strerror(errno));
>
> If it's ever safe to call vfork() from a given place, then it should
> always be safe to call it from that place, so the #ifdef isn't
> really necessary.
Not always true. This is true if you're following the portable rules
for what a vfork-child can do, or if you expect the code to only run
on Linux.
On uClinux (and Linux), a vfork-child can get away with quite a lot of
things that are not safe on other OSes. For example, malloc() and
printf() are probably fine, because they update memory in the same way
as the parent would anyway. Thread-local storage keys off the stack
address, if you're using LinuxThreads not NPTL, so again the
vfork-child updates memory the same way as the parent. Setting signal
handlers or masks in the vfork-child are fine and don't affect the
parent in Linux, same for chdir(). execvp() is ok, even though that
calls malloc() (in at least one Glibc version I looked at).
In my own library of portable code, I use vfork() on OSes where either
the child is following the very restrictive rules, or it's uClinux and
there's no choice and it'll work when the child doesn't follow all the
rules. I don't use vfork() for daemon() though, as that doesn't work
(I've seen some uClinux patches do that and it's just broken); clone()
works for that. I get nervous when it's uClinux _and_ threaded. :-)
-- Jamie
Re: [PATCH] dropbear-051: errno bug fix
Matt Johnston wrote: > > is that errno is already set to non-zero > > before strol is called, then strol is successful but since strol doesn't > > reset errno to zero, the next line thinks that strol failed. > > I've applied this now in a more general form with a new > function m_str_to_int(). Funnily enough setting errno=EINVAL isn't > actually defined by C99 - though most (all?) platforms seem > to do that. Single Unix Specification (aka. POSIX) does though. http://www.opengroup.org/onlinepubs/95399/functions/strtol.html The strtol() function shall not change the setting of errno if successful. Since 0, LONG_MIN or LLONG_MIN, and LONG_MAX or LLONG_MAX are returned on error and are also valid returns on success, an application wishing to check for error situations should set errno to 0, then call strtol() or strtoll(), then check errno. RETURN VALUE Upon successful completion, these functions shall return the converted value, if any. If no conversion could be performed, 0 shall be returned and errno may be set to EINVAL. If the correct value is outside the range of representable values, LONG_MIN, LONG_MAX, LLONG_MIN, or LLONG_MAX shall be returned (according to the sign of the value), and errno set to ERANGE. -- Jamie
Re: [PATCH] dropbear-051: uClinux vfork
Farrell Aultman wrote: > Between dropbear-047 and dropbear-051 changes were made that > accounted for the fact that uClinux needs to use vfork instead of > fork. However, fork was not replaced with vfork in all places. I > moved the conditional preproccessor check for uClinux into the > includes.h file, so that fork is always replaced with vfork in all > of the dropbear code when compiling for uClinux. A side effect is > that the code is cleaner since you just call fork without wrapping > it every time with a conditional preprocessor check. Have you checked that it's safe to call vfork in all those places? vfork is not always a safe replacement for fork, even on uClinux where fork doesn't work. -- Jamie
Re: [PATCH] dropbear-051: errno bug fix
Farrell Aultman wrote: > The code assumed that when strol is successful, that it will set > errno to zero. This is not the case, at least under uClinux. It's not the case in general, POSIX doesn't require it to be set to zero. > The man page does not indicate this either. What can happen is that > errno is already set to non-zero before strol is called, then strol > is successful but since strol doesn't reset errno to zero, the next > line thinks that strol failed. That's right. The correct way to call strtol in general, if you're checking errno after, is to set errno to zero before. Since reading errno can be slow (in threaded programs), you might want to check if the result from strtol is LONG_MIN or LONG_MAX before checking errno. -- Jamie
Re: Another question about tunnelling
Matt Johnston wrote: > > To stop it from terminating, I have to send something: > > > > (while:; do sleep 20; echo keepalive; done) | \ > > dbclient -T -i $HOME/.ssh/id_rsa.db -R 1:127.0.0.1:23 [EMAIL > > PROTECTED] \ > > 'while :; do sleep 20; echo keepalive; done' > > > > As the sole purpose of the dbclient command in this case is to set up > > a tunnel, is there an easier way to do this than all the extra input? > > > > In other words, is there a way to enable keepalive messages without > > having to pipe something in, perhaps like OpenSSH's ClientAlive > > options? > > There's nothing there currently, though I might add > something like that in a future version. Thanks for the reply! For reference, I noticed something interesting in the behaviour of keepalives recently. I had a number of little devices running dbclient, connecting to a server running OpenSSH, doing this: dbclient -T -i $HOME/.ssh/id_rsa.db -R 1:127.0.0.1:23 [EMAIL PROTECTED] \ 'while :; do sleep 20; echo keepalive; done' (Note: No input to dbclient, just responses from the server). Those terminate after 2 minutes if there's no traffic over the tunnel. (Conveniently, when there's tunnel traffic, they don't terminate). However, they were connecting over an IP NAT. At some time, it appears the NAT state was reset, so packets from the server could no longer get to the clients. I found (to my surprise) that the clients didn't terminate after this happened. They kept running, with no traffic. This indicates that the 2 minute timeout is not internal to dbclient, but is caused by the OpenSSH server terminating the connection after lack of incoming traffic. But I couldn't find anything in the OpenSSH server config to configure that 2 minutes. Curious. -- Jamie
Another question about tunnelling
I'm using dropbear to set up a tunnel, using a command like this: dbclient -T -i $HOME/.ssh/id_rsa.db -R 1:127.0.0.1:23 [EMAIL PROTECTED] This works very well, but I'm finding the command terminates after 2 minutes. If I do something equivalent to this, it still terminates after 2 minutes: dbclient -T -i $HOME/.ssh/id_rsa.db -R 1:127.0.0.1:23 [EMAIL PROTECTED] \ 'while :; do sleep 20; echo keepalive; done' I'm surprised that's not enough. To stop it from terminating, I have to send something: (while:; do sleep 20; echo keepalive; done) | \ dbclient -T -i $HOME/.ssh/id_rsa.db -R 1:127.0.0.1:23 [EMAIL PROTECTED] \ 'while :; do sleep 20; echo keepalive; done' As the sole purpose of the dbclient command in this case is to set up a tunnel, is there an easier way to do this than all the extra input? In other words, is there a way to enable keepalive messages without having to pipe something in, perhaps like OpenSSH's ClientAlive options? Thanks, -- Jamie
[PATCH] wildcard host keys
I'm using dropbear on an embedded device that has to connect to a
server at an IP address that isn't known in advance, but is verifiable
with a host key.
So I added the ability to use "*" in the known_hosts file to match any
hostname/IP. This is better than disabling host key checking
altogether, as I can still verify it's connecting to an authorized
server.
Someone else may find the patch useful.
-- Jamie
This allows the known_hosts file to use wildcard "*" to match any host.
This is used to prevent the interactive "y/n" question as long as the
host key is in the recognised list - essential for non-interactive setup
of tunnels, to IPs that aren't known when the /root directory is created.
--- dropbear-0.46/cli-kex.c.orig2006-08-30 03:49:40.0 +0100
+++ dropbear-0.46/cli-kex.c 2006-08-30 03:58:54.0 +0100
@@ -202,6 +202,14 @@
break;
}
+ /* Match "*" wildcard hostname. */
+ if (line->len >= 2
+ && strncmp("* ", buf_getptr(line, 2), 2) == 0) {
+ buf_incrpos(line, 2);
+ TRACE(("matched wildcard host"))
+ goto check_algo;
+ }
+
/* The line is too short to be sensible */
/* "30" is 'enough to hold ssh-dss plus the spaces, ie so we
don't
* buf_getfoo() past the end and die horribly - the base64
parsing
@@ -225,6 +233,7 @@
continue;
}
+ check_algo:
if ( strncmp(buf_getptr(line, algolen), algoname, algolen) !=
0) {
TRACE(("algo doesn't match"))
continue;
