[PATCH] Compilation fix when ENABLE_CLI_AGENTFWD undefined
Hello,
(I just subscribed to the list, so the following points might already
have been addressed; sorry if it's the case.)
Here is a patch for dropbear-0.53.1 that fixes a compilation and
linking issue that currently comes up when ENABLE_CLI_AGENTFWD is not
defined at all. Only the cli-authpubkey.c file is touched.
Matt, please review, and apply if it's correct. :)
Also, please note that make distclean, after a dropbear build, fails
to remove the following files:
- config.log
- config.status
- libtomcrypt/Makefile
- libtommath/Makefile
I did not provide a patch for this because it could be intentional;
if it is not, please fix it too for completeness.
--
Laurent
diff -rNU3 dropbear-0.53.1.old/cli-authpubkey.c dropbear-0.53.1/cli-authpubkey.c
--- dropbear-0.53.1.old/cli-authpubkey.c2011-03-02 14:23:35.0
+0100
+++ dropbear-0.53.1/cli-authpubkey.c2011-07-29 12:52:19.0 +0200
@@ -123,6 +123,7 @@
void cli_buf_put_sign(buffer* buf, sign_key *key, int type,
const unsigned char *data, unsigned int len)
{
+#ifdef ENABLE_CLI_AGENTFWD
if (key-source == SIGNKEY_SOURCE_AGENT) {
/* Format the agent signature ourselves, as buf_put_sign would.
*/
buffer *sigblob;
@@ -134,9 +135,11 @@
buf_free(sigblob);
} else {
+#endif
buf_put_sign(buf, key, type, data, len);
+#ifdef ENABLE_CLI_AGENTFWD
}
-
+#endif
}
/* TODO: make it take an agent reference to use as well */
@@ -186,13 +189,13 @@
int cli_auth_pubkey() {
TRACE((enter cli_auth_pubkey))
-
+#ifdef ENABLE_CLI_AGENTFWD
if (!cli_opts.agent_keys_loaded) {
/* get the list of available keys from the agent */
cli_load_agent_keys(cli_opts.privkeys);
cli_opts.agent_keys_loaded = 1;
}
-
+#endif
if (cli_opts.privkeys-first) {
sign_key * key = (sign_key*)cli_opts.privkeys-first-item;
/* Send a trial request */
Re: [solaris] library -lc: not found
$ make PROGRAMS=scp STATIC=1 gcc -L/usr/local/lib -R/usr/local/lib -static -o scp scp.o progressmeter.o atomicio.o scpmisc.o compat.o ld: fatal: library -lc: not found As Matt said, you cannot make static programs on Solaris. Solaris does not ship with a libc.a, only a libc.so. This would be an excellent reason to change operating systems and use something less braindead and obsolete. But if you're hell-bent on using Solaris, just remove the STATIC=1 part of your command line and dropbear should compile without trouble, it will simply use dynamic libraries. -- Laurent
dropbear hangs instead of returning failure on a long command
Hello Matt (and list), When given a command that exceeds MAX_CMD_LEN, the dropbear server just hangs and does nothing (it stays on select() in the main loop until the client closes the connection, which may never happen). It happens whether or not a pty is requested. I've only tested it with dbclient, not with other clients. I think it should return a failure message to the client and close the connection instead. I've been able to track this down to svr-chansession.c, in the chansessionrequest() function. sessioncommand() correctly returns DROPBEAR_FAILURE when the command exceeds MAX_CMD_LEN, but ret is only tested when wantreply is true. So the right fix might be to actually set the boolean in the payload on the dbclient side - but I'm not knowledgeable about the ssh protocol so you be the judge. If it helps: dropbear-763979a9c1f1 (hg tip taken yesterday), Linux 3.10.42, x86_64, musl-1.1.4 libc. Thanks a lot for dropbear, it's extremely useful ! -- Laurent
dbclient reports integrity errors with GitHub
Hello, dropbear-2015.67, compiled with a recent (last week) musl libc, statically linked. The problem also occurs with dropbear-2014.66. Since a few days ago (but I'm not sure when it started; in any case it's less than a month ago), every git pull and push over SSH from/to GitHub fails with the following message: dbclient: Connection to g...@github.com:22 exited: Integrity error (bad packet size $N) $N is a nonsensical number, sometimes negative, but not always. Connections to GitHub via the OpenSSH client *work*. Connections to git repositories other than GitHub via dbclient *work*. Connections to GitHub via dbclient *do not work*, whether my client key is ECDSA or RSA. I don't use DSA. Any idea of what's going on or what I could do to learn more ? It's probably a GitHub problem, but I figured I had more chances of finding knowledgeable people here :) Thanks, -- Laurent
Re: dbclient reports integrity errors with GitHub
On 23/04/2015 02:03, Matt Johnston wrote: I think its because their version of libssh ignores one of the protocol flags, fixed in libssh 0.6.4. I'll send an email to github. https://git.libssh.org/projects/libssh.git/commit/?id=eb86fd8cdfd69f46c60bf0885a2125285e4a22b3 Thanks for your quick answer! I hope their reaction time will be as quick. (One can dream.) -- Laurent
Re: server limits commands to MAX_CMD_LEN
On 01/07/2015 19:24, Tim Broberg wrote: Yes, I have had to scp scripts to the target and run them in place for large commands specifically because of dropbear. I've run into the same issue and just recompiled dropbear with increased limits. 8k is enough for me (but 4k is not enough, so Matt, if you're changing the default, please make it 8k :-)) -- Laurent
Re: Dropbear SSH integrity error
On 12/11/2015 10:28, Zbynek Michl wrote: # ssh d...@demo.mt.lv ssh: Connection to d...@demo.mt.lv:22 exited: Integrity error (bad packet size -22146333) Hi Zbynek, I had the same problem earlier this year with GitHub: git over ssh worked with an OpenSSH client, but not with a dropbear client. I reported it to GitHub; I didn't get any answer, but two weeks or so later, they fixed the problem. I suspect this has to do with some sshd server that is not compatible with a dropbear client - I'm inclined to think that the server makes assumptions about unspecified protocol details and those assumptions are false with dbclient. Or the other way around. Do you know what sshd server RouterOS uses? I can't tell from d...@demo.mt.lv because they don't provide a shell :) -- Laurent
Re: Dropbear Digest, Vol 171, Issue 1
I can't compile DB 2020.79 with uClibc-ng (1.0.32, looking at the 1.0.34 sources nothing has changed) unless I add "#define _GNU_SOURCE" on top of "dbrandom.c" (it is required by sys/random.h, line 11 https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/common/sys/random.h). The alternative is to #include manually. Which is best? The former is best. Or, you could simply compile dropbear with -D_GNU_SOURCE in your CFLAGS. Never directly include Linux kernel headers in your application code if you can avoid it (because it requires careful namespace manipulation and not all kernel headers are suitable for this, so it can be the beginning of a looong chain of problems). -- Laurent
