[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: scp asks for host key during /etc/init.d
> Is it possible that during the boot sequence scp doesn't look in the right > place for the trusted host file ? A boot environment and a login environment are very different things. For instance, in your boot environment, you have no defined USER or HOME environment variables. scp has no way of knowing that your known_hosts file is in /root/.ssh if there's no HOME=/root variable to tell it so. Adjust the environment in your scp command line. Make sure it does not leak to the rest of the boot scripts, though. -- Laurent
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
Re: dropbear still requires password when password is blank
> 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. I've always run automated stuff on embedded boxes via dropbear with a little pubkey authentication; I store a public key in the embedded firmware, and the testing process has the corresponding private key. This has the following additional advantage: if there's a massive f*ckup and some development version goes into release, the box is still not publicly accessible. ;) -- Laurent
Re: Dropbear channel request race condition?
I'm not sure whether it's possible to use EOF like that for a session with a PTY terminal. It's not, and it's a well-known problem with read/write file descriptors - they cannot transfer one-way EOFs. shutdown() was actually added to the BSD socket interface to address this problem, but it's an ad-hoc and half-working solution, and it doesn't work on anything else than sockets. Terminals are complex here because they weren't designed for separate input and output; the terminal model is a single point of management for communication, whether inbound or outbound, and sending half-duplex EOFs isn't supported AFAIK. Dropbear could still catch the write-EOF from the client and not close the pty until the read-EOF also arrives. Or only close it after a configurable timeout; closing as soon as the write-EOF is received is definitely a suboptimal behaviour. -- 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