From m.fortini at selcomgroup.com Mon Jan 14 22:28:45 2008 From: m.fortini at selcomgroup.com (Matteo Fortini) Date: Mon, 14 Jan 2008 14:28:45 +0100 (CET) Subject: dropbear 0.50 Segfault Message-ID: <3155.172.26.4.190.1200317325.squirrel@mail.selcomgroup.com> I built dropbear on arm-linux using uclibc 9.27 and gcc 3.41 (snapgear linux). Unfortunately, every time I connect the server segfaults. I only have strace on my system, I put the output at the bottom of this email. I tried every config option, like --disable-zlib --disable-shadow --disable-syslog --disable-openpty --disable-utmp --disable-utmpx I tried building a static binary, but it doesn't work either. The dbclient is working properly. What could I try? Thank you, Matteo 17507 15:50:15.877744 close(3) = 0 17507 15:50:15.878947 close(5) = 0 17507 15:50:15.880263 getpid() = 17507 17507 15:50:15.882560 gettimeofday({1200066615, 883051}, NULL) = 0 17507 15:50:15.883953 pipe([3, 5]) = 0 17507 15:50:15.885310 fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 17507 15:50:15.886553 fcntl64(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 17507 15:50:15.887813 time(NULL) = 1200066615 17507 15:50:15.889035 brk(0x54000) = 0x54000 17507 15:50:15.890759 brk(0x57000) = 0x57000 17507 15:50:15.892377 rt_sigaction(SIGCHLD, {0x117c8, [TRAP FPE USR2 PIPE ALRM TERM STKFLT STOP 34 35], SA_NOCLDSTOP|0x4000000}, NULL, 8) = 0 17507 15:50:15.893930 time(NULL) = 1200066615 17507 15:50:15.895137 write(4, "SSH-2.0-dropbear_0.50\r\n", 23) = 23 17506 15:50:15.896849 close(6 17507 15:50:15.897669 select(5, [4], NULL, NULL, {1, 0} 17506 15:50:15.898474 <... close resumed> ) = 0 17507 15:50:15.899272 <... select resumed> ) = 1 (in [4], left {1, 0}) 17506 15:50:15.900146 close(4 17507 15:50:15.900916 time( 17506 15:50:15.901410 <... close resumed> ) = 0 17507 15:50:15.902144 <... time resumed> NULL) = 1200066615 17506 15:50:15.902707 select(6, [3 5], NULL, NULL, NULL 17507 15:50:15.903783 read(4, "S", 1) = 1 17507 15:50:15.905067 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.907306 time(NULL) = 1200066615 17507 15:50:15.908511 read(4, "S", 1) = 1 17507 15:50:15.909793 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.911688 time(NULL) = 1200066615 17507 15:50:15.912891 read(4, "H", 1) = 1 17507 15:50:15.914173 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.916440 time(NULL) = 1200066615 17507 15:50:15.917627 read(4, "-", 1) = 1 17507 15:50:15.918892 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.920753 time(NULL) = 1200066615 17507 15:50:15.923430 read(4, "2", 1) = 1 17507 15:50:15.924697 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.926612 time(NULL) = 1200066615 17507 15:50:15.927791 read(4, ".", 1) = 1 17507 15:50:15.929066 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.930928 time(NULL) = 1200066615 17507 15:50:15.932119 read(4, "0", 1) = 1 17507 15:50:15.933387 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.935302 time(NULL) = 1200066615 17507 15:50:15.936491 read(4, "-", 1) = 1 17507 15:50:15.937758 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.939646 time(NULL) = 1200066615 17507 15:50:15.940837 read(4, "O", 1) = 1 17507 15:50:15.942105 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.943975 time(NULL) = 1200066615 17507 15:50:15.945161 read(4, "p", 1) = 1 17507 15:50:15.946462 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.948325 time(NULL) = 1200066615 17507 15:50:15.949517 read(4, "e", 1) = 1 17507 15:50:15.950788 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.952670 time(NULL) = 1200066615 17507 15:50:15.953861 read(4, "n", 1) = 1 17507 15:50:15.955125 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.957376 time(NULL) = 1200066615 17507 15:50:15.958563 read(4, "S", 1) = 1 17507 15:50:15.959843 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.961711 time(NULL) = 1200066615 17507 15:50:15.964083 read(4, "S", 1) = 1 17507 15:50:15.965551 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.967443 time(NULL) = 1200066615 17507 15:50:15.968632 read(4, "H", 1) = 1 17507 15:50:15.969899 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.971760 time(NULL) = 1200066615 17507 15:50:15.972949 read(4, "_", 1) = 1 17507 15:50:15.974232 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.976675 time(NULL) = 1200066615 17507 15:50:15.977865 read(4, "4", 1) = 1 17507 15:50:15.979131 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.980998 time(NULL) = 1200066615 17507 15:50:15.982186 read(4, ".", 1) = 1 17507 15:50:15.983460 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.985363 time(NULL) = 1200066615 17507 15:50:15.986551 read(4, "3", 1) = 1 17507 15:50:15.987832 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.989701 time(NULL) = 1200066615 17507 15:50:15.990891 read(4, "p", 1) = 1 17507 15:50:15.992158 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.994048 time(NULL) = 1200066615 17507 15:50:15.995270 read(4, "2", 1) = 1 17507 15:50:15.996540 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:15.998426 time(NULL) = 1200066615 17507 15:50:15.999599 read(4, " ", 1) = 1 17507 15:50:16.000874 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.003925 time(NULL) = 1200066616 17507 15:50:16.005114 read(4, "D", 1) = 1 17507 15:50:16.006429 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.008297 time(NULL) = 1200066616 17507 15:50:16.009485 read(4, "e", 1) = 1 17507 15:50:16.010753 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.012641 time(NULL) = 1200066616 17507 15:50:16.013830 read(4, "b", 1) = 1 17507 15:50:16.015088 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.017295 time(NULL) = 1200066616 17507 15:50:16.018484 read(4, "i", 1) = 1 17507 15:50:16.019752 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.021639 time(NULL) = 1200066616 17507 15:50:16.022824 read(4, "a", 1) = 1 17507 15:50:16.024084 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.026181 time(NULL) = 1200066616 17507 15:50:16.027366 read(4, "n", 1) = 1 17507 15:50:16.028644 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.030513 time(NULL) = 1200066616 17507 15:50:16.031700 read(4, "-", 1) = 1 17507 15:50:16.032966 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.034851 time(NULL) = 1200066616 17507 15:50:16.036069 read(4, "8", 1) = 1 17507 15:50:16.037335 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.039200 time(NULL) = 1200066616 17507 15:50:16.040385 read(4, "u", 1) = 1 17507 15:50:16.041661 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.044751 time(NULL) = 1200066616 17507 15:50:16.046249 read(4, "b", 1) = 1 17507 15:50:16.047516 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.049381 time(NULL) = 1200066616 17507 15:50:16.050566 read(4, "u", 1) = 1 17507 15:50:16.051844 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.053712 time(NULL) = 1200066616 17507 15:50:16.054897 read(4, "n", 1) = 1 17507 15:50:16.056195 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.058076 time(NULL) = 1200066616 17507 15:50:16.059267 read(4, "t", 1) = 1 17507 15:50:16.060529 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.062395 time(NULL) = 1200066616 17507 15:50:16.063580 read(4, "u", 1) = 1 17507 15:50:16.064856 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.066752 time(NULL) = 1200066616 17507 15:50:16.067940 read(4, "1", 1) = 1 17507 15:50:16.069211 select(5, [4], NULL, NULL, {1, 0}) = 1 (in [4], left {1, 0}) 17507 15:50:16.071092 time(NULL) = 1200066616 17507 15:50:16.072279 read(4, "\n", 1) = 1 17507 15:50:16.073835 select(5, [3 4], [4], NULL, {300, 0}) = 1 (out [4], left {300, 0}) 17507 15:50:16.076437 time(NULL) = 1200066616 17507 15:50:16.077623 write(4, "\0\0\1\\\4\24\306\2422\220_\246\216k\225\351\325\243\375"..., 352) = 352 17507 15:50:16.079240 time(NULL) = 1200066616 17507 15:50:16.080446 select(5, [3 4], [], NULL, {300, 0}) = 1 (in [4], left {285, 20000}) 17507 15:50:31.060913 time(NULL) = 1200066631 17507 15:50:31.062125 read(4, "\0\0\2\304\5\24\255\377", 8) = 8 17507 15:50:31.063526 read(4, "/,\263\262\236\373j\376\205f\237\342K\323\0\0\0Ydiffie"..., 704) = 704 17507 15:50:31.065709 brk(0x59000) = 0x59000 17507 15:50:31.067374 select(5, [3 4], [], NULL, {300, 0}) = 1 (in [4], left {300, 0}) 17507 15:50:31.069482 time(NULL) = 1200066631 17507 15:50:31.071937 read(4, "\0\0\0\214\5\36\0\0", 8) = 8 17507 15:50:31.073333 read(4, "\0\201\0\270\3478\225\233$\314\345Y\302d\207\340\f\237"..., 136) = 136 17507 15:50:31.075406 brk(0x5a000) = 0x5a000 17507 15:50:31.077255 brk(0x5b000) = 0x5b000 17507 15:50:31.083828 brk(0x5c000) = 0x5c000 17507 15:50:31.094367 brk(0x5d000) = 0x5d000 17507 15:50:31.102785 brk(0x5e000) = 0x5e000 17507 15:50:33.172701 select(5, [3 4], [4], NULL, {300, 0}) = 1 (out [4], left {300, 0}) 17507 15:50:33.175072 time(NULL) = 1200066633 17507 15:50:33.176641 write(4, "\0\0\1\304\v\37\0\0\0\231\0\0\0\7ssh-rsa\0\0\0\3\1\0\1"..., 456) = 456 17507 15:50:33.178497 time(NULL) = 1200066633 17507 15:50:33.179735 select(5, [3 4], [4], NULL, {300, 0}) = 1 (out [4], left {300, 0}) 17507 15:50:33.182102 time(NULL) = 1200066633 17507 15:50:33.183554 write(4, "\0\0\0\f\n\25\326=\221\365t\276\371kl\37", 16) = 16 17507 15:50:33.185293 time(NULL) = 1200066633 17507 15:50:33.186501 select(5, [3 4], [], NULL, {300, 0}) = 1 (in [4], left {300, 0}) 17507 15:50:33.188636 time(NULL) = 1200066633 17507 15:50:33.189871 read(4, "\0\0\0\f\n\25\0\0", 8) = 8 17507 15:50:33.191260 read(4, "\0\0\0\0\0\0\0\0", 8) = 8 17507 15:50:33.193983 time(NULL) = 1200066633 17507 15:50:33.195270 select(5, [3 4], [], NULL, {300, 0}) = 1 (in [4], left {300, 0}) 17507 15:50:33.197731 time(NULL) = 1200066633 17507 15:50:33.198965 read(4, "\30\251S!\257\231H\366g<\200\220\v\230\356\325", 16) = 16 17507 15:50:33.200491 read(4, "\0r\361\311\0\362\t\250\211x5\207k{B_\213x\227M3\363-1"..., 32) = 32 17507 15:50:33.202360 select(5, [3 4], [4], NULL, {300, 0}) = 1 (out [4], left {300, 0}) 17507 15:50:33.204741 time(NULL) = 1200066633 17507 15:50:33.205980 write(4, "\230r\333\246q\367\220nIF\217\250\3000\16 }\301!\24\332"..., 48) = 48 17507 15:50:33.207744 time(NULL) = 1200066633 17507 15:50:33.208969 select(5, [3 4], [], NULL, {300, 0}) = 1 (in [4], left {300, 0}) 17507 15:50:33.212296 time(NULL) = 1200066633 17507 15:50:33.213542 read(4, "\t\30\212[\274C\201^S<\252\315\210\377\243~", 16) = 16 17507 15:50:33.215026 read(4, "<\213\353\204\3755E\353\347G?\346\r\200u*\32[]$\372\320"..., 48) = 48 17507 15:50:33.216907 select(5, [3 4], [4], NULL, {300, 0}) = 1 (out [4], left {300, 0}) 17507 15:50:33.219277 time(NULL) = 1200066633 17507 15:50:33.220482 write(4, "\33\232\333G\212\231\353+Q=\302\2439W\256\350k\270C\0\334"..., 64) = 64 17507 15:50:33.222067 time(NULL) = 1200066633 17507 15:50:33.223288 select(5, [3 4], [], NULL, {300, 0}) = 1 (in [4], left {298, 990000}) 17507 15:50:34.228044 time(NULL) = 1200066634 17507 15:50:34.229276 read(4, "?\3704\364C\323\214\351P\373B`\21\23\341\202", 16) = 16 17507 15:50:34.230772 read(4, "\10m\341RR_u\224\265n\2\354\30\\z\n\205\263G\226N\3\244"..., 128) = 128 17507 15:50:34.232544 open("/etc/passwd", O_RDONLY) = 7 17507 15:50:34.233855 ioctl(7, SNDCTL_TMR_TIMEBASE, 0xbffff848) = -1 ENOTTY (Inappropriate ioctl for device) 17507 15:50:34.235168 read(7, "root:$1$$oCLuEVgI1iAqOA8pwkzAg1:"..., 256) = 124 17507 15:50:34.236562 close(7) = 0 17507 15:50:34.237823 open("/etc/shells", O_RDONLY) = -1 ENOENT (No such file or directory) 17507 15:50:34.255358 time(NULL) = 1200066634 17507 15:50:34.256564 open("/etc/config/TZ", O_RDONLY) = 7 17507 15:50:34.257879 read(7, "MET-1METDST\n\n", 68) = 13 17507 15:50:34.259163 read(7, "", 55) = 0 17507 15:50:34.260434 close(7) = 0 17507 15:50:34.262935 open("/etc/config/TZ", O_RDONLY) = 7 17507 15:50:34.264251 read(7, "MET-1METDST\n\n", 68) = 13 17507 15:50:34.266020 read(7, "", 55) = 0 17507 15:50:34.267268 close(7) = 0 17507 15:50:34.268519 open("/etc/config/TZ", O_RDONLY) = 7 17507 15:50:34.269838 read(7, "MET-1METDST\n\n", 68) = 13 17507 15:50:34.271121 read(7, "", 55) = 0 17507 15:50:34.272516 close(7) = 0 17507 15:50:34.273751 getpid() = 17507 17507 15:50:34.274970 write(2, "[", 1) = 1 17507 15:50:34.276911 write(2, "17507", 5) = 5 17507 15:50:34.278450 write(2, "] ", 2) = 2 17507 15:50:34.279988 write(2, "Jan 11 15:50:34", 15) = 15 17507 15:50:34.281550 write(2, " ", 1) = 1 17507 15:50:34.283102 write(2, "password auth succeeded for \'roo"..., 58) = 58 17507 15:50:34.284699 write(2, "\n", 1) = 1 17507 15:50:34.286447 close(6) = 0 17506 15:50:34.287506 <... select resumed> ) = 1 (in [5]) 17507 15:50:34.288678 select(5, [3 4], [4], NULL, {300, 0} 17506 15:50:34.289766 close(5 17507 15:50:34.290585 <... select resumed> ) = 1 (out [4], left {300, 0}) 17506 15:50:34.291679 <... close resumed> ) = 0 17507 15:50:34.292520 time( 17506 15:50:34.293041 select(6, [3], NULL, NULL, NULL 17507 15:50:34.294055 <... time resumed> NULL) = 1200066634 17507 15:50:34.294827 write(4, "\277\340\375\3164\265:\v\334\16\225\0\236H\355f\367\6\210"..., 32) = 32 17507 15:50:34.296821 time(NULL) = 1200066634 17507 15:50:34.298046 select(5, [3 4], [], NULL, {300, 0}) = 1 (in [4], left {300, 0}) 17507 15:50:34.300175 time(NULL) = 1200066634 17507 15:50:34.302604 read(4, "\217\10\312I\21\322a\212\206\"b\236\213x\31w", 16) = 16 17507 15:50:34.304106 read(4, "\374\264\331\352\3\"|\27\37\330X\203\35\223R\32\21\361"..., 48) = 48 17507 15:50:34.305875 brk(0x5f000) = 0x5f000 17507 15:50:34.307737 select(5, [3 4], [4], NULL, {300, 0}) = 1 (out [4], left {300, 0}) 17507 15:50:34.310412 time(NULL) = 1200066634 17507 15:50:34.311603 write(4, "\353\335d>\236\315\357/\346\275\325\33\3\223t\0:\240k\336"..., 48) = 48 17507 15:50:34.313392 time(NULL) = 1200066634 17507 15:50:34.314623 select(5, [3 4], [], NULL, {300, 0}) = 1 (in [4], left {300, 0}) 17507 15:50:34.317114 time(NULL) = 1200066634 17507 15:50:34.318336 read(4, "\35m.\177\252\347\24\275\224\200Q&i\177\371\341", 16) = 16 17507 15:50:34.319845 read(4, "~\v\277$\214+\333\370\345-\214\3\235\326\2\347\337C\355"..., 320) = 320 17507 15:50:34.321831 open("/dev/ptyp0", O_RDWR|O_NOCTTY|O_LARGEFILE) = -1 EIO (Input/output error) 17507 15:50:34.323277 open("/dev/ptyp0", O_RDWR|O_NOCTTY|O_LARGEFILE) = -1 EIO (Input/output error) 17507 15:50:34.324727 open("/dev/ptyp1", O_RDWR|O_NOCTTY|O_LARGEFILE) = -1 EIO (Input/output error) 17507 15:50:34.326194 open("/dev/ptyp1", O_RDWR|O_NOCTTY|O_LARGEFILE) = -1 EIO (Input/output error) 17507 15:50:34.327663 open("/dev/ptyp2", O_RDWR|O_NOCTTY|O_LARGEFILE) = 6 17507 15:50:34.329470 open("/dev/ttyp2", O_RDWR|O_NOCTTY|O_LARGEFILE) = 7 17507 15:50:34.330838 ioctl(6, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 17507 15:50:34.332251 ioctl(6, SNDCTL_TMR_START, {B38400 opost isig icanon echo ...}) = 0 17507 15:50:34.333673 ioctl(6, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 17507 15:50:34.335106 open("/etc/group", O_RDONLY) = 8 17507 15:50:34.336748 ioctl(8, SNDCTL_TMR_TIMEBASE, 0xbffff758) = -1 ENOTTY (Inappropriate ioctl for device) 17507 15:50:34.338049 read(8, "root:x:0:root\nsshd:x:500:\n", 256) = 26 17507 15:50:34.339382 read(8, "", 256) = 0 17507 15:50:34.340624 close(8) = 0 17507 15:50:34.343020 stat64("/dev/ttyp2", {st_mode=S_IFCHR|0600, st_rdev=makedev(3, 2), ...}) = 0 17507 15:50:34.344577 chown("/dev/ttyp2", 0, 0) = 0 17507 15:50:34.346059 chmod("/dev/ttyp2", 0622) = 0 17507 15:50:34.347395 ioctl(6, 0x5414, {ws_row=62, ws_col=207, ws_xpixel=0, ws_ypixel=0}) = 0 17507 15:50:34.348698 ioctl(6, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 17507 15:50:34.350090 --- SIGSEGV (Segmentation fault) --- From rob at landley.net Fri Jan 18 16:01:15 2008 From: rob at landley.net (Rob Landley) Date: Fri, 18 Jan 2008 01:01:15 -0600 Subject: dropbear 0.50 Segfault In-Reply-To: <3155.172.26.4.190.1200317325.squirrel@mail.selcomgroup.com> References: <3155.172.26.4.190.1200317325.squirrel@mail.selcomgroup.com> Message-ID: <200801180101.16371.rob@landley.net> On Monday 14 January 2008 07:28:45 Matteo Fortini wrote: > I built dropbear on arm-linux using uclibc 9.27 and gcc 3.41 (snapgear > linux). > > Unfortunately, every time I connect the server segfaults. If it happens on arm but not on other platforms, my first guess would be an alignment issue. (Arm segfaults on unaligned 4-byte read/write attempts, rather than doing the two stage fetch thing other processors do.) It might be in uClibc 0.9.27 (which is a really old version, and I vaguely recall a bug like this in the networking stuff. DNS lookup, I think). Is there any way you can try 0.9.29, which is the current stable uClibc release? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From buytenh at wantstofly.org Thu Jan 24 07:46:53 2008 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Wed, 23 Jan 2008 23:46:53 +0100 Subject: dropbear 0.50 packaged for fedora Message-ID: <20080123224653.GA11410@xi.wantstofly.org> FYI, I've packaged dropbear 0.50 for Fedora: https://admin.fedoraproject.org/pkgdb/packages/name/dropbear It is available in F8 updates, and will be part of the F9 release. I needed the following patch to make it build on F8, or else the compiler bombs out saying that there is an opportunity for open() to be called with O_CREAT but without a third argument: --- dropbear-0.50/loginrec.c.orig 2007-08-08 17:39:37.000000000 +0200 +++ dropbear-0.50/loginrec.c 2008-01-07 11:13:13.000000000 +0100 @@ -1313,7 +1313,7 @@ /* open the file (using filemode) and seek to the login entry */ static int -lastlog_openseek(struct logininfo *li, int *fd, int filemode) +lastlog_openseek(struct logininfo *li, int *fd, int flags, mode_t mode) { off_t offset; int type; @@ -1334,7 +1334,7 @@ return 0; } - *fd = open(lastlog_file, filemode); + *fd = open(lastlog_file, flags, mode); if ( *fd < 0) { dropbear_log(LOG_INFO, "lastlog_openseek: Couldn't open %s: %s", lastlog_file, strerror(errno)); @@ -1364,7 +1364,7 @@ /* create our struct lastlog */ lastlog_construct(li, &last); - if (!lastlog_openseek(li, &fd, O_RDWR|O_CREAT)) + if (!lastlog_openseek(li, &fd, O_RDWR|O_CREAT, 0644)) return(0); /* write the entry */ From jacques at digidruid.com Wed Feb 6 01:13:13 2008 From: jacques at digidruid.com (Jacques Verryn) Date: Tue, 5 Feb 2008 18:13:13 +0200 Subject: Dropbear 0.50 scp problem. Most probably related to uclibc Message-ID: <25e3df530802050813n55e1e43fr6a55f775d2074401@mail.gmail.com> Hi all I'm seeing the same problem as per posts http://thread.gmane.org/gmane.network.ssh.dropbear/587 http://article.gmane.org/gmane.network.ssh.dropbear/607 I'm using linux kernel 2.6.20 on a gumstix with uclibc. The crux of the problem is if I scp a file from my desktop linux pc to the gumstix, the resulting file on the gumstix has zero file length. The common denominator in the above posts and in my case, is uclibc. I upgraded from dropbear 0.48.1 to 0.50 due the the scp hang error that was fixed be extensive reworking of the common-channel.c code. I'm working on a production level project and can unfortunately not trade scp functionality versus the occasional session hang. Any ideas??? Thx Jacques -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080205/e7a1b799/attachment.htm From mfgeg at yahoo.de Wed Feb 6 05:15:35 2008 From: mfgeg at yahoo.de (=?iso-8859-1?Q?Fritz_S=E4gesser?=) Date: Tue, 5 Feb 2008 20:15:35 +0000 (GMT) Subject: Keep alive time Message-ID: <143725.83667.qm@web26306.mail.ukl.yahoo.com> Hello @ all I am trying to build some tunnel connections between dropbear server and client. Both are using version 0.50. Tunnel build works but after a while stopps the tunnel. And i am searching for a way to keep it open. I start the tunnel with a script (i use public key 4 login): dbclient -N -i /home/user/.ssh/key -L 3000:XXX.XXX.XXX.XXX:14000 server & In the release notes of version 0.50 was written that its possible to use a keepalive setting -K. I have tried to add the option to the command, like this: dbclient -K 50 -N -i /home/root/.ssh/7025 -L 3000:192.168.1.26:12000 x-treme.dyndns.ws & But after starting the script the tunnel stops maybe after 10 hours. Is the -K time to long or is something wrong with my command' Best regards Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. www.yahoo.de/go From rob at landley.net Wed Feb 6 06:49:07 2008 From: rob at landley.net (Rob Landley) Date: Tue, 5 Feb 2008 15:49:07 -0600 Subject: Dropbear 0.50 scp problem. Most probably related to uclibc In-Reply-To: <25e3df530802050813n55e1e43fr6a55f775d2074401@mail.gmail.com> References: <25e3df530802050813n55e1e43fr6a55f775d2074401@mail.gmail.com> Message-ID: <200802051549.07584.rob@landley.net> On Tuesday 05 February 2008 10:13:13 Jacques Verryn wrote: > The crux of the problem is if I scp a file from my desktop linux pc to the > gumstix, the resulting file on the gumstix has zero file length. > The common denominator in the above posts and in my case, is uclibc. > I upgraded from dropbear 0.48.1 to 0.50 due the the scp hang error that was > fixed be extensive reworking of the common-channel.c code. > I'm working on a production level project and can unfortunately not trade > scp functionality versus the occasional session hang. > > Any ideas??? Run "./dropbear -F -E" under strace, and then do your scp to it with stderr captured to a log file. (Via serial console if necessary.) At a guess, some call to libc is returning an error that aborts the write. Figure out _where_ the write stops, and you're halfway to figuring out why. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From jacques at digidruid.com Fri Feb 8 23:44:36 2008 From: jacques at digidruid.com (Jacques Verryn) Date: Fri, 8 Feb 2008 16:44:36 +0200 Subject: Dropbear 0.50 scp problem. Most probably related to uclibc In-Reply-To: <200802051549.07584.rob@landley.net> References: <25e3df530802050813n55e1e43fr6a55f775d2074401@mail.gmail.com> <200802051549.07584.rob@landley.net> Message-ID: <25e3df530802080644s6ff8e290p2f141b2fb329e05@mail.gmail.com> On Feb 5, 2008 11:49 PM, Rob Landley wrote: > On Tuesday 05 February 2008 10:13:13 Jacques Verryn wrote: > > The crux of the problem is if I scp a file from my desktop linux pc to > the > > gumstix, the resulting file on the gumstix has zero file length. > > The common denominator in the above posts and in my case, is uclibc. > > I upgraded from dropbear 0.48.1 to 0.50 due the the scp hang error that > was > > fixed be extensive reworking of the common-channel.c code. > > I'm working on a production level project and can unfortunately not > trade > > scp functionality versus the occasional session hang. > > > > Any ideas??? > > Run "./dropbear -F -E" under strace, and then do your scp to it with > stderr > captured to a log file. (Via serial console if necessary.) > > At a guess, some call to libc is returning an error that aborts the write. > Figure out _where_ the write stops, and you're halfway to figuring out > why. > > Rob > -- > "One of my most productive days was throwing away 1000 lines of code." > - Ken Thompson. > > > I ran strace -fF dropbear -F. I then scp'd a file(small.txt) containing 'hello world\n' and saw the following <--- trace snip -----> [pid 6696] stat64("./small.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 [pid 6696] open("./small.txt", O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 3 [pid 6696] write(1, "\0", 1 [pid 6694] <... select resumed> ) = 1 (in [10], left {299, 640000}) [pid 6696] <... write resumed> ) = 1 [pid 6694] gettimeofday( [pid 6696] read(0, [pid 6694] <... gettimeofday resumed> {4920, 971917}, NULL) = 0 [pid 6694] read(10, "\0", 16375) = 1 [pid 6694] select(13, [4 6 10 12], [6], NULL, {300, 0}) = 1 (out [6], left {300, 0}) [pid 6694] gettimeofday({4920, 978769}, NULL) = 0 [pid 6694] write(6, "s\266?\251(\210b\337\376\247\207D\203p\354\37\201\315i"..., 48) = 48 [pid 6694] gettimeofday({4920, 983486}, NULL) = 0 [pid 6694] select(13, [4 6 10 12], [], NULL, {300, 0}) = 1 (in [6], left {300, 0}) [pid 6694] gettimeofday({4920, 988049}, NULL) = 0 [pid 6694] read(6, "s\273\227(D\r(\243\251\276\215\32~\233\226\306", 16) = 16 [pid 6694] read(6, "\312\333!d\3324\32\324\356\347\262\365A/k\301\32\205\371"..., 32) = 32 [pid 6694] select(13, [4 6 10 12], [9], NULL, {300, 0}) = 2 (in [6], out [9], left {300, 0}) [pid 6694] gettimeofday({4920, 996866}, NULL) = 0 [pid 6694] read(6, "\373r\306\275\16\272\360d\16$j\336|\34V\266", 16) = 16 [pid 6694] read(6, "\241y\256\0252N\226\365\'z79\270=\30E\253h\260.\267\2\261"..., 32) = 32 [pid 6694] write(9, "hello world\n\0", 13) = 13 [pid 6694] select(13, [4 6 10 12], [], NULL, {300, 0} [pid 6696] <... read resumed> "hello world\n", 12) = 12 [pid 6696] write(3, "hello world\n", 12) = 12 [pid 6696] ftruncate64(3, 51539607552) = 0 [pid 6696] close(3) = 0 [pid 6696] read(0, "\0", 1) = 1 [pid 6696] write(1, "\0", 1 The size parameter of the ftruncate64 call is WAY wrong! Doing the same with dropbear 0.48.1 yields the following trace <--- trace snip -----> [pid 6710] write(7, "hello world\n\0", 13) = 13 [pid 6710] select(11, [6 8 10], [], NULL, {20, 0} [pid 6712] <... read resumed> "hello world\n", 12) = 12 [pid 6712] write(3, "hello world\n", 12) = 12 [pid 6712] ftruncate(3, 12) = 0 [pid 6712] close(3) My first observation is that 0.48 use ftruncate instead ftruncate64 and secondly the size parameter is correct. The code in scp.c line(1032-1041) that is involved with the write and then ftruncate is: if (count != 0 && wrerr == NO && atomicio(vwrite, ofd, bp->buf, count) != count) { wrerr = YES; wrerrno = errno; } if (wrerr == NO && ftruncate(ofd, size) != 0) { run_err("%s: truncate: %s", np, strerror(errno)); wrerr = DISPLAYED; } This code has not change in a while. I also verified the 'size' has the correct value just before the ftruncate. I'm starting to suspect a compiler flag / package config issue. I'm going to fiddle a bit more, but this is what I have at the moment. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080208/4f98a32a/attachment.htm From rob at landley.net Sat Feb 9 07:30:54 2008 From: rob at landley.net (Rob Landley) Date: Fri, 8 Feb 2008 16:30:54 -0600 Subject: Dropbear 0.50 scp problem. Most probably related to uclibc In-Reply-To: <25e3df530802080644s6ff8e290p2f141b2fb329e05@mail.gmail.com> References: <25e3df530802050813n55e1e43fr6a55f775d2074401@mail.gmail.com> <200802051549.07584.rob@landley.net> <25e3df530802080644s6ff8e290p2f141b2fb329e05@mail.gmail.com> Message-ID: <200802081630.54747.rob@landley.net> On Friday 08 February 2008 08:44:36 Jacques Verryn wrote: > On Feb 5, 2008 11:49 PM, Rob Landley wrote: > > On Tuesday 05 February 2008 10:13:13 Jacques Verryn wrote: > > > The crux of the problem is if I scp a file from my desktop linux pc to > > the > > > gumstix, the resulting file on the gumstix has zero file length. > > > The common denominator in the above posts and in my case, is uclibc. > > > I upgraded from dropbear 0.48.1 to 0.50 due the the scp hang error that ... > [pid 6696] ftruncate64(3, 51539607552) = 0 > [pid 6696] close(3) = 0 > [pid 6696] read(0, "\0", 1) = 1 > [pid 6696] write(1, "\0", 1 > > > The size parameter of the ftruncate64 call is WAY wrong! That's certainly a bug, but how would it produce a 0 length file? (Especially since the truncate call isn't returning an error...) > > if (count != 0 && wrerr == NO && > atomicio(vwrite, ofd, bp->buf, count) != count) { > wrerr = YES; > wrerrno = errno; > } > > if (wrerr == NO && ftruncate(ofd, size) != 0) { > run_err("%s: truncate: %s", np, strerror(errno)); > wrerr = DISPLAYED; > } > > This code has not change in a while. I also verified the 'size' has the > correct value just before the ftruncate. Why is uClibc calling ftruncate64() for this on gumstix? Is that a 64 bit processor, or does it have large file support? This sounds like a uClibc issue. What version of uClibc are you using? In any case, uClibc should be casting size to uint64_t inside the call to ftruncate. Sounds like a mismatch between the prototype and the actual syscall... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From jacques at digidruid.com Mon Feb 11 22:44:53 2008 From: jacques at digidruid.com (Jacques Verryn) Date: Mon, 11 Feb 2008 15:44:53 +0200 Subject: Dropbear 0.50 scp problem. Most probably related to uclibc In-Reply-To: <200802081630.54747.rob@landley.net> References: <25e3df530802050813n55e1e43fr6a55f775d2074401@mail.gmail.com> <200802051549.07584.rob@landley.net> <25e3df530802080644s6ff8e290p2f141b2fb329e05@mail.gmail.com> <200802081630.54747.rob@landley.net> Message-ID: <25e3df530802110544h14203611j3bbaa8d74f9b621f@mail.gmail.com> I would also have expected an error from ftruncate64 call. For some reason I was forced to compile my uClibc with large file support. I'm not sure what that reason was since I've been tinkering with the gumstix buildroot for about a year now. Changing #define _FILE_OFFSET_BITS 64 to #define _FILE_OFFSET_BITS 32 in config.h seems to fix my problem. This forces dropbear to use the ftruncate call instead of ftruncate64 call. Thanks for guiding me through the problem Jacques On Feb 9, 2008 12:30 AM, Rob Landley wrote: > On Friday 08 February 2008 08:44:36 Jacques Verryn wrote: > > On Feb 5, 2008 11:49 PM, Rob Landley wrote: > > > On Tuesday 05 February 2008 10:13:13 Jacques Verryn wrote: > > > > The crux of the problem is if I scp a file from my desktop linux pc > to > > > the > > > > gumstix, the resulting file on the gumstix has zero file length. > > > > The common denominator in the above posts and in my case, is uclibc. > > > > I upgraded from dropbear 0.48.1 to 0.50 due the the scp hang error > that > ... > > [pid 6696] ftruncate64(3, 51539607552) = 0 > > [pid 6696] close(3) = 0 > > [pid 6696] read(0, "\0", 1) = 1 > > [pid 6696] write(1, "\0", 1 > > > > > > The size parameter of the ftruncate64 call is WAY wrong! > > That's certainly a bug, but how would it produce a 0 length file? > (Especially > since the truncate call isn't returning an error...) > > > > > if (count != 0 && wrerr == NO && > > atomicio(vwrite, ofd, bp->buf, count) != count) { > > wrerr = YES; > > wrerrno = errno; > > } > > > > if (wrerr == NO && ftruncate(ofd, size) != 0) { > > run_err("%s: truncate: %s", np, strerror(errno)); > > wrerr = DISPLAYED; > > } > > > > This code has not change in a while. I also verified the 'size' has the > > correct value just before the ftruncate. > > Why is uClibc calling ftruncate64() for this on gumstix? Is that a 64 bit > processor, or does it have large file support? This sounds like a uClibc > issue. What version of uClibc are you using? > In any case, uClibc should be casting size to uint64_t inside the call to > ftruncate. Sounds like a mismatch between the prototype and the actual > syscall... > > Rob > -- > "One of my most productive days was throwing away 1000 lines of code." > - Ken Thompson. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080211/63a5cfde/attachment.htm From rob at landley.net Tue Feb 12 13:00:42 2008 From: rob at landley.net (Rob Landley) Date: Mon, 11 Feb 2008 22:00:42 -0600 Subject: Dropbear 0.50 scp problem. Most probably related to uclibc In-Reply-To: <25e3df530802110544h14203611j3bbaa8d74f9b621f@mail.gmail.com> References: <25e3df530802050813n55e1e43fr6a55f775d2074401@mail.gmail.com> <200802081630.54747.rob@landley.net> <25e3df530802110544h14203611j3bbaa8d74f9b621f@mail.gmail.com> Message-ID: <200802112200.42838.rob@landley.net> On Monday 11 February 2008 07:44:53 Jacques Verryn wrote: > I would also have expected an error from ftruncate64 call. > > For some reason I was forced to compile my uClibc with large file support. > I'm not sure what that reason was since I've been tinkering with the > gumstix buildroot for about a year now. > Changing > #define _FILE_OFFSET_BITS 64 > to > #define _FILE_OFFSET_BITS 32 > in config.h seems to fix my problem. This forces dropbear to use the > ftruncate call instead of ftruncate64 call. > > Thanks for guiding me through the problem > Jacques You might want to send a patch to the uClibc mailing list, or at least notify them of the bug... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From miroslaw.dach at psi.ch Wed Feb 20 01:25:47 2008 From: miroslaw.dach at psi.ch (Dach Miroslaw) Date: Tue, 19 Feb 2008 17:25:47 +0100 Subject: ssh logging without a password Message-ID: <1B4F8000449511488D1A640DD6DECA350E28E4@MAILBOX0A.psi.ch> Hi All, I have tried to setup sshd (dropbear v.049) to accept login from the remote host without giving the password. The idea which I have is as following: I have the client computer A and the server embedded system B which runs dropbear daemon. I would like to login from machine A (being user jane) to B by means of the command: ssh root at B without giving a password. To do so I have generated on machine A (being user jane) access keys by means of ssh-keygen -t dsa. I do not know where to put the file id_dsa.pub since on the B server there is no directory /root/.ssh but just a regular file instead. It seems to be that dropbear accepts the dss key type but on the client one can choose the dsa type (or rsa). Are this keys somehow compatible? I will appreciate very much any hint on the issue I have described above Best Regards Mirek From matt at ucc.asn.au Wed Feb 20 10:33:02 2008 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 20 Feb 2008 10:33:02 +0900 Subject: ssh logging without a password In-Reply-To: <1B4F8000449511488D1A640DD6DECA350E28E4@MAILBOX0A.psi.ch> References: <1B4F8000449511488D1A640DD6DECA350E28E4@MAILBOX0A.psi.ch> Message-ID: <20080220013302.GG5247@ucc.gu.uwa.edu.au> On Tue, Feb 19, 2008 at 05:25:47PM +0100, Dach Miroslaw wrote: > > I do not know where to put the file id_dsa.pub since on the B server there is no directory /root/.ssh but just a regular file instead. > > It seems to be that dropbear accepts the dss key type but on the client one can choose the dsa type (or rsa). Are this keys somehow compatible? /root/.ssh must be a directory - did a file get copied to the wrong place? The .pub file should be copied to (or really appended to) /root/.ssh/authorized_keys - make sure it it isn't writable by anyone else (same for .ssh). Dropbear should support rsa or dsa keys, assuming it's been compiled with normal options. Cheers, Matt From rob at landley.net Wed Feb 20 11:15:41 2008 From: rob at landley.net (Rob Landley) Date: Tue, 19 Feb 2008 20:15:41 -0600 Subject: ssh logging without a password In-Reply-To: <1B4F8000449511488D1A640DD6DECA350E28E4@MAILBOX0A.psi.ch> References: <1B4F8000449511488D1A640DD6DECA350E28E4@MAILBOX0A.psi.ch> Message-ID: <200802192015.41852.rob@landley.net> On Tuesday 19 February 2008 10:25:47 Dach Miroslaw wrote: > Hi All, > > I have tried to setup sshd (dropbear v.049) to accept login from the remote > host without giving the password. > > The idea which I have is as following: > > I have the client computer A and the server embedded system B which runs > dropbear daemon. > > I would like to login from machine A (being user jane) to B by means of the > command: ssh root at B without giving a password. To do so I have generated on > machine A (being user jane) access keys by means of ssh-keygen -t dsa. > > I do not know where to put the file id_dsa.pub since on the B server there > is no directory /root/.ssh but just a regular file instead. You need to have a .ssh directory in the home directory of whatever user you're logging in as. (And that .ssh directory should be permissions 700.) The public key should be in the file "~/.ssh/authorized_keys". The private key should be on the machine you're trying to log in from, as ".ssh/id_dsa". If your root user hasn't got a home directory to put a .ssh directory in, your system is misconfigured. > It seems to be that dropbear accepts the dss key type but on the client one > can choose the dsa type (or rsa). Are this keys somehow compatible? It should be able to autodetect which type you've supplied. Notice how the text line in the file with the key starts with "ssh-dss "? That's a type identifier. Besides, if it just treated it as a big string of hex digits and tried to use an rsa key as dsa or vice versa, it's about as likely to work as using any other thousand-bit-long random number to log in, isn't it? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From ssh at sgi.com Sat Mar 1 01:40:25 2008 From: ssh at sgi.com (Steven Hein) Date: Fri, 29 Feb 2008 10:40:25 -0600 Subject: Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0 Message-ID: <47C83579.4090503@sgi.com> Hello-- I have not seen any new information on this issue since the thread from last December: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2007q4/000672.html Does anyone have any updates or workarounds? I just upgraded to 0.50 about 2 weeks ago and found that this is causing me troubles. Thanks for any info! Steve From ssh at sgi.com Sat Mar 1 06:32:52 2008 From: ssh at sgi.com (Steven Hein) Date: Fri, 29 Feb 2008 15:32:52 -0600 Subject: Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0 In-Reply-To: <47C83579.4090503@sgi.com> References: <47C83579.4090503@sgi.com> Message-ID: <47C87A04.1050606@sgi.com> Steven Hein wrote: > Hello-- > > I have not seen any new information on this issue since the thread > from last December: > > http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2007q4/000672.html > > Does anyone have any updates or workarounds? I just upgraded > to 0.50 about 2 weeks ago and found that this is causing me troubles. > > Thanks for any info! > > Steve > > Just in case it's of value to someone, I'll share what I learned about this problem today. I certainly don't have a root cause, or a quality solution, but I have something that "works for me" at the moment...... I spent some time digging in to this today (rather unscientifically, by sprinkling dropbear_log() messages throughout svr-chansession.c). I found that the child process didn't seem to terminate before that client requested that the session be closed. (Specifically, the child was still running when send_exitsignalstatus() was called, so exitpid was still -1. I couldn't see any obvious reason for this, and the child process always terminated "very soon" (milliseconds) after send_exitsignalstatus() was done. After playing with it for a while, a found a big hack that appears to work for me at the moment: when the exitpid is -1 when entering send_exitsignalstatus(), I simply sleep for 500ms with usleep. What I found is that a child that hasn't yet terminated will always terminate during that usleep(), so the exitpid is set, so the exit status is sent to the client. Also, since the usleep() is interrupted by the arrival of the SIGCHLD signal when the child finally does terminate, it only sleeps for the full 500ms if the child doesn't terminate......so it shouldn't slow things down too much. I don't have an incredible amount of time to help in the debug of this problem.....but this is solidly reproducible case for me. So of there's something I can try to help debug, let me know. BTW, my failing configuration is: Server: custom board w/ FreeScale processor (MPC8358) Linux kernel version 2.6.24 dropbear-0.50 Client: 1U Intel server box (x86_64) SuSE 10.1 OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 And.....for anyone who might be interested, I attached the patch against dropbear-0.50 for my hack. Steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear.patch Type: text/x-patch Size: 909 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080229/af9ed493/attachment.bin From matt at ucc.asn.au Sat Mar 1 11:09:00 2008 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 1 Mar 2008 11:09:00 +0900 Subject: Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0 In-Reply-To: <47C87A04.1050606@sgi.com> References: <47C83579.4090503@sgi.com> <47C87A04.1050606@sgi.com> Message-ID: <20080301020900.GD16629@ucc.gu.uwa.edu.au> On Fri, Feb 29, 2008 at 03:32:52PM -0600, Steven Hein wrote: > Steven Hein wrote: > >Hello-- > > > >I have not seen any new information on this issue since the thread > >from last December: > > > >http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2007q4/000672.html > > > >Does anyone have any updates or workarounds? I just upgraded > >to 0.50 about 2 weeks ago and found that this is causing me troubles. > > ... > I spent some time digging in to this today (rather > unscientifically, by sprinkling dropbear_log() messages throughout > svr-chansession.c). I found that the child process didn't seem to > terminate before that client requested that the session be closed. > (Specifically, the child was still running when send_exitsignalstatus() > was called, so exitpid was still -1. I couldn't see any obvious > reason for this, and the child process always terminated > "very soon" (milliseconds) after send_exitsignalstatus() was done. Yep, that seems to be the cause. I've attached a patch that will wait for he process to exit before closing the channel, which should fix the problem. I've put a testing release at http://matt.ucc.asn.au/dropbear/testing/dropbear-0.51test2.tar.bz2 with that fix and a couple of other things. I'd appreciate if anyone who has had odd channel-closing issues could test that. I suspect that it might alter some behaviour such as 'ssh hostname "sleep 10 & echo hello"', but I can't see a better way to do it - if during cleanup a process's stdin/stdout is closed before the process terminates, then there'll always be that race. It seems safer to just wait for the spawned shell to exit. Cheers, Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: channel-exit-1.diff Type: text/x-diff Size: 1865 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080301/a52d4199/attachment.diff From ssh at sgi.com Tue Mar 4 05:12:05 2008 From: ssh at sgi.com (Steven Hein) Date: Mon, 03 Mar 2008 14:12:05 -0600 Subject: Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0 In-Reply-To: <20080301020900.GD16629@ucc.gu.uwa.edu.au> References: <47C83579.4090503@sgi.com> <47C87A04.1050606@sgi.com> <20080301020900.GD16629@ucc.gu.uwa.edu.au> Message-ID: <47CC5B95.9030509@sgi.com> Matt-- I tested 0.50 with the common-channel.c patch below, and it worked as expected (always returned the remote command's exit code correctly). As you said, it does cause the "sleep 10 & hello" command to return immediately after echoing "hello", leaving the "sleep 10" running on the remote host. Thanks for the quick turn-around! Steve Matt Johnston wrote: > On Fri, Feb 29, 2008 at 03:32:52PM -0600, Steven Hein wrote: > >> Steven Hein wrote: >> >>> Hello-- >>> >>> I have not seen any new information on this issue since the thread >>> >> >from last December: >> >>> http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2007q4/000672.html >>> >>> Does anyone have any updates or workarounds? I just upgraded >>> to 0.50 about 2 weeks ago and found that this is causing me troubles. >>> >>> > ... > >> I spent some time digging in to this today (rather >> unscientifically, by sprinkling dropbear_log() messages throughout >> svr-chansession.c). I found that the child process didn't seem to >> terminate before that client requested that the session be closed. >> (Specifically, the child was still running when send_exitsignalstatus() >> was called, so exitpid was still -1. I couldn't see any obvious >> reason for this, and the child process always terminated >> "very soon" (milliseconds) after send_exitsignalstatus() was done. >> > > Yep, that seems to be the cause. I've attached a patch that > will wait for he process to exit before closing the channel, > which should fix the problem. I've put a testing release at > http://matt.ucc.asn.au/dropbear/testing/dropbear-0.51test2.tar.bz2 > with that fix and a couple of other things. > > I'd appreciate if anyone who has had odd channel-closing > issues could test that. I suspect that it might alter some > behaviour such as 'ssh hostname "sleep 10 & echo hello"', > but I can't see a better way to do it - if during cleanup a > process's stdin/stdout is closed before the process > terminates, then there'll always be that race. It seems > safer to just wait for the spawned shell to exit. > > Cheers, > Matt > > ------------------------------------------------------------------------ > > # > # old_revision [6107b89c1188975d0c60f50621afe593cb6e554f] > # > # patch "common-channel.c" > # from [375ff10b1da7d82baf11af5e032ac82184639ce4] > # to [7370ebc3b83fd52b5114385329e439624ddee60a] > # > ============================================================ > --- common-channel.c 375ff10b1da7d82baf11af5e032ac82184639ce4 > +++ common-channel.c 7370ebc3b83fd52b5114385329e439624ddee60a > @@ -261,6 +261,7 @@ static void check_close(struct Channel * > > /* EOF/close handling */ > static void check_close(struct Channel *channel) { > + int close_allowed = 0; > > TRACE(("check_close: writefd %d, readfd %d, errfd %d, sent_close %d, recv_close %d", > channel->writefd, channel->readfd, > @@ -274,8 +275,17 @@ static void check_close(struct Channel * > { > channel->flushing = 1; > } > + > + // if a type-specific check_close is defined we will only exit > + // once that has been triggered. this is only used for a server "session" > + // channel, to ensure that the shell has exited (and the exit status > + // retrieved) before we close things up. > + if (!channel->type->check_close > + || channel->type->check_close(channel)) { > + close_allowed = 1; > + } > > - if (channel->recv_close && !write_pending(channel)) { > + if (channel->recv_close && !write_pending(channel) && close_allowed) { > if (!channel->sent_close) { > TRACE(("Sending MSG_CHANNEL_CLOSE in response to same.")) > send_msg_channel_close(channel); > @@ -312,9 +322,10 @@ static void check_close(struct Channel * > } > > /* And if we can't receive any more data from them either, close up */ > - if (!channel->sent_close > - && channel->readfd == FD_CLOSED > + if (channel->readfd == FD_CLOSED > && (ERRFD_IS_WRITE(channel) || channel->errfd == FD_CLOSED) > + && !channel->sent_close > + && close_allowed > && !write_pending(channel)) { > TRACE(("sending close, readfd is closed")) > send_msg_channel_close(channel); > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rob at landley.net Tue Mar 4 10:46:56 2008 From: rob at landley.net (Rob Landley) Date: Mon, 3 Mar 2008 19:46:56 -0600 Subject: Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0 In-Reply-To: <47CC5B95.9030509@sgi.com> References: <47C83579.4090503@sgi.com> <20080301020900.GD16629@ucc.gu.uwa.edu.au> <47CC5B95.9030509@sgi.com> Message-ID: <200803031946.56328.rob@landley.net> On Monday 03 March 2008 14:12:05 Steven Hein wrote: > Matt-- > > I tested 0.50 with the common-channel.c patch below, > and it worked as expected (always returned the > remote command's exit code correctly). > > As you said, it does cause the "sleep 10 & hello" > command to return immediately after echoing > "hello", leaving the "sleep 10" running on the remote > host. Which is actually the behavior you want (and what telnet does, and xterm...) It's a longstanding _bug_ that openssh doesn't do that. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From matt at ucc.asn.au Thu Mar 27 22:51:33 2008 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 27 Mar 2008 22:51:33 +0900 Subject: Dropbear 0.51 released Message-ID: <20080327135133.GE13087@ucc.gu.uwa.edu.au> Hi all. I've put up version 0.51 of Dropbear, http://matt.ucc.asn.au/dropbear/dropbear.html as usual. There aren't many changes though it should fix the problems with an exit status not being returned by the server. Cheers, Matt 0.51 - Thu 27 March 2008 - Make a copy of password fields rather erroneously relying on getwpnam() to be safe to call multiple times - If $SSH_ASKPASS_ALWAYS environment variable is set (and $SSH_ASKPASS is as well) always use that program, ignoring isatty() and $DISPLAY - Wait until a process exits before the server closes a connection, so that an exit code can be sent. This fixes problems with exit codes not being returned, which could cause scp to fail. From ron.eggler at novax.com Sat Mar 29 06:02:38 2008 From: ron.eggler at novax.com (Ron Eggler) Date: Fri, 28 Mar 2008 14:02:38 -0700 Subject: ssh-keygen problem Message-ID: <200803281402.38821.ron.eggler@novax.com> Hi, We're using Dropbear 0.48 What i did: I downloaded "openssh-4.6p1.tar.gz" and compiled it on a different system than the target system. I wasn't able to compile a more recent version since it wouldn't find openSSL even tho it is installed (0.9.8 - I tried to pass the correct path with --with-ssl-dir but it wouldn't work). Anyways, I got ssh compiled, I copied the "ssh-keygen" binary onto our target (pc 104, geode) system from where I issued "ssh-keygen -N '' -t dsa -f file" it to create a public key pair, I copied the pub part into the authorized_keys file on our server (OpenSSH_4.3p2, OpenSSL 0.9.7i 14 Oct 2005) but it wouldn't let the client in with out a password, why not??? I'm stuck, I have no idea what's going on. I can get in from a system NOT using Dropbear so the permissions of /root/.ssh and all above/below should be set right, i also can't see any messages in /var/log/messages. I can cat the authorized_keys file and it looks all good.... :o Any hints on this? Is there some version conflict going on or something? Thanks alot! Ron From vapier at gentoo.org Sat Mar 29 12:59:29 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Fri, 28 Mar 2008 23:59:29 -0400 Subject: [patch] fix scp for no-mmu systems Message-ID: <200803282359.30005.vapier@gentoo.org> the current scp code calls fork() in do_local_cmd() and it uses exit() even when vfork-ed. this patch fixes both issues. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080328/f50eeafc/attachment.pgp -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear-uclinux.patch Type: text/x-diff Size: 1102 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080328/f50eeafc/attachment.patch From vapier at gentoo.org Sat Mar 29 13:01:32 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 29 Mar 2008 00:01:32 -0400 Subject: [patch] accept "dbscp" as an alias for "scp" in multimode Message-ID: <200803290001.33444.vapier@gentoo.org> this allows us to have dropbear and openssh installed nicely side-by-side in multimode. we name the dropbear scp binary "dbscp" so it doesnt clobber the openssh "scp". -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080329/2aec55ec/attachment.pgp -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear-multi-dbscp.patch Type: text/x-diff Size: 601 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080329/2aec55ec/attachment.patch From snafu_101 at hotmail.com Sat Mar 29 21:49:35 2008 From: snafu_101 at hotmail.com (John Smith) Date: Sat, 29 Mar 2008 08:49:35 -0400 Subject: Couldn't stat /var/log/lastlog: No such file or directory Message-ID: Hello: I'm using dropbear on an embedded ARM system with an image built with the Angstrom/Open Embedded system. It works wonderfully! However there is a minor annoyance in syslog where dropbear is looking for /var/log/lastlog. How can I make this go away? Is it simply by creating an empty file 'lastlog'? Thanks in advance. snafu _________________________________________________________________ How well do you know your celebrity gossip? http://originals.msn.com/thebigdebate?ocid=T002MSN03N0707A -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080329/24d06fbd/attachment.htm From rob at landley.net Sun Mar 30 02:28:06 2008 From: rob at landley.net (Rob Landley) Date: Sat, 29 Mar 2008 13:28:06 -0500 Subject: Dropbear 0.51 released In-Reply-To: <20080327135133.GE13087@ucc.gu.uwa.edu.au> References: <20080327135133.GE13087@ucc.gu.uwa.edu.au> Message-ID: <200803291328.06641.rob@landley.net> On Thursday 27 March 2008 08:51:33 Matt Johnston wrote: > Hi all. > > I've put up version 0.51 of Dropbear, > http://matt.ucc.asn.au/dropbear/dropbear.html as usual. Out of curiosity, what's left before a 1.0 release? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From roberto.foglietta at gmail.com Mon Mar 31 15:11:45 2008 From: roberto.foglietta at gmail.com (Roberto A. Foglietta) Date: Mon, 31 Mar 2008 09:11:45 +0200 Subject: PATCH: sftp subsystem request via ssh In-Reply-To: <476D4CD2.80300@gmail.com> References: <476D4CD2.80300@gmail.com> Message-ID: 2007/12/22, Roberto A. Foglietta : > Roberto A. Foglietta wrote: > > Hi to all folks, > > > > I develop this patch in order to avoid -s usage when > > > > sftp -s /remote/path/sftp-server -S /local/path/dbclient > > > > now if -s is not specified a subsystem request would be sent > > > > please use this one, the previous was not applying cleanly to 0.50 > Sorry for posting again but I see dropbear 0.51 is out and nothing changed about sftp request (cfr. attached patch). Sombody would like comment this patch? Is there something wrong in it and/or in the way I use sftp? Thanks in advance, -- /roberto -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear_sftp_subsystem_request.patch Type: text/x-patch Size: 445 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080331/c6d12d2c/attachment.bin From iztok.marjanovic at gmail.com Mon Mar 31 22:40:06 2008 From: iztok.marjanovic at gmail.com (Iztok Marjanovic) Date: Mon, 31 Mar 2008 07:40:06 -0700 Subject: how to use --disable-openpty to fix no shell after login Message-ID: <8123ce3a0803310740o7905ca99y7f325ca6852d8b0@mail.gmail.com> Hello, I have the same problem as described by a previous post by Stefan (see below). Stefan fixed his problem by using a --disable-openpty configuration parameter. I do not know where to specify the --disable-openpty. Is this specified in a dropbear config file somwhere? I'm using Dropbear sshd v0.50. Thanks, Iztok Hi, d'uh. couldn't find any errors in the logs, but running it with error reporting to stderr unveiled the problem: [26079] Mar 27 23:32:05 pty_allocate: openpty: No such file or directory [26079] Mar 27 23:32:05 no pty was allocated, couldn't execute so.. configure with --disable-openpty helped and it works perfectly now. Just in case someone else runs into this again. Best regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080331/155d1a5e/attachment.htm From vapier at gentoo.org Mon Mar 31 23:03:45 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 31 Mar 2008 11:03:45 -0400 Subject: how to use --disable-openpty to fix no shell after login In-Reply-To: <8123ce3a0803310740o7905ca99y7f325ca6852d8b0@mail.gmail.com> References: <8123ce3a0803310740o7905ca99y7f325ca6852d8b0@mail.gmail.com> Message-ID: <200803311103.45926.vapier@gentoo.org> On Monday 31 March 2008, Iztok Marjanovic wrote: > I have the same problem as described by a previous post by Stefan (see > below). Stefan fixed his problem by using a --disable-openpty > configuration parameter. I do not know where to specify the > --disable-openpty. Is this specified in a dropbear config file somwhere? why dont you just mount /dev/pts correctly ? and make sure your kernel supports the newer pty stuff ? otherwise you'll just have to deal with the fun problems of old bsd pty and static # of device nodes. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080331/f8bba95d/attachment.pgp From keesan at sdf.lonestar.org Mon Mar 31 23:52:01 2008 From: keesan at sdf.lonestar.org (sindi keesan) Date: Mon, 31 Mar 2008 15:52:01 +0000 (UTC) Subject: Setting up dropbear - beginner's guide Message-ID: I have compiled dbclient scp dropbear dropbearkey for version 0.49, both dynamically against glibc 2.2.5 using gcc 2.95.3 and statically against uclibc 0.9.27. I am not a computer professional and do not have and have never set up openssh. I use a small slackware-based 'basiclinux' that came without ssh. dbclient and scp work fine (kernel 2.4.31). I don't have dropbear working. The instructions in README say to use dropbearkey to generate rsa and dss keys and put them in /etc/dropbear. Do I also need to make and put public keys there? The instructions tell me only how to use dropbear -y to display the public part of the key on the screen. Please could someone write a very brief instruction for beginners on how to set up dropbear, assuming you don't already have openssh keys, to add to or supplement README. If I type dropbear (Enter) and then try to use dbclient or ssh to access my own computer via its IP number (from a shell account or locally using the loopback IP number 127.0.0.1) it won't accept my password after asking for it. ssh tells me Permission denied, please try again. dbclient just asks again for the password. I am trying to access my own computer with dbclient (and eventually access it with ssh from a mac and puTTy from Windows so as to share a modem connection). Do I need both private keys? Using lynx, I cannot choose which topics to receive emails about at the website. Sindi keesan at sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org