8 ms·
TinySSH is a small SSH server using NaCl, TweetNaCl
- w4rh4wk5 12y agodon't we already have dropbear for such tasks, would it be better to "extend" / "improve" dropbear?
- exabrial 12y ago> simple configuration - TinySSH can't be misconfigured CHALLENGE ACCEPTED!
- nitrogen 12y agoIs TweetNaCl deliberately 32-bit or LLP64 only? One of the first lines is typedef unsigned long u32; but on 64-bit LP64 systems (like Linux), long is 64-bits. See http://tweetnacl.cr.yp.to/20140427/tweetnacl.c http://tweetnacl.cr.yp.to/20140427/tweetnacl.c
- sanxiyn 12y agoYes, TweetNaCl is. TweetNaCl's goal is to be auditable, not to be portable. On the other hand, TinySSH actually includes a configuration mechanism to detect integer sizes, and modifies TweetNaCl accordingly, so TinySSH is not 32-bit/LLP64 only.
- bluetech 12y agoAre you sure? The TweetNaCl paper says u32 is an unsigned >= 32-bit (see towards the end): http://tweetnacl.cr.yp.to/papers.html http://tweetnacl.cr.yp.to/papers.html
- Nursie 12y agoI wonder why not just use stdint.h, it's got what you need. ..
- deleted 12y ago[deleted]
- Nursie 12y agoYes, I did see that post. The multiple statements per line thing is really fishy for a security critical piece of infrastructure.
- friendlypedant 12y agoThis is essentially just a bikeshed. "Wait, this code is hard to understand and requires deep domain knowledge. Better nitpick the code style instead. Also, bikesheds should clearly be orange. Green is way too fishy."
- Nursie 12y agoI have domain knowledge and I've read a lot of code in my time. The style in use there is peculiar. That doesn't mean it is malicious or incorrect but it might make it easier to hide if it was. Sorry you don't see that.
- edwintorok 12y agostdint.h is C99 and while I'd love to believe that every C compiler is C99 capable by now, I don't know if that is actually the case. Does stdint.h exist on Win32 these days?
- Nursie 12y agoMicrosoft's poor support for standard C is no excuse not to use these types everywhere else and either define them yourself on windows or get stdint from boost, from one of the stdint.h replacements or <cstdint> from MSVC 2012. IMHO, of course.
- friendlypedant 12y ago
- kzrdude 12y agoThey seem to mask u32 values just fine everywhere, so u32 being larger than it has to is no problem. ulong is as you know the smallest type that's always guaranteed to be at least 32 bits.
- awda 12y agoNo it isn't. The only guarantees you have about the size of long are that it is at least as large as (greater than or equal) a normal int. And a normal int is greater than or equal as big as a short.
- pbsd 12y agoC99 standard [1], §5.2.4.2.1 says otherwise. Int must acommodate at least 16 bits, long 32 bits, and long long 64 bits. C89 [2], §2.2.4.2 says the same thing but omits long long, so tweetnacl's u64 may not exist (this was the case with MSVC not too long ago). Additionally, char is required to be at least 8 bits by the C standard, but tweetnacl assumes exactly 8. Some oddball architectures have larger character types, but POSIX mandates 8. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf [2] http://nepsweb.co.uk/langstand/isoC/gordon/ansi-c89w.txt http://nepsweb.co.uk/langstand/isoC/gordon/ansi-c89w.txt
- awda 12y agoThis code is attempting to be portable to C89, or why not just use C99's stdint.h? I don't believe your statement "C89 says the same thing," do you have a source to point to? Do you have the section number in the latest freely available C99 working draft? The "Types" section (which 6.something in the draft) simply says what I said earlier about scalar rank. And 5.4.4.2.1 doesn't seem to exist in the draft.
- pbsd 12y agoSorry, I mistyped the section number. Updated the parent comment with corrections and links. I assume the intent of tweetnacl is to be C89-compatible, but due to the long long (and char, although that one's pretty pedantic) issue there's little guarantee of success.
- eliteraspberrie 12y agoThe name is a little confusing. The way u32 is used in TweetNaCl, it doesn't have to be exactly 32 bits, only at least 32 bits.
- awda 12y agotypedef uint_least32_t u32;
- chronid 12y agoSomeone know how it compares with dropbear [1]? 1. https://matt.ucc.asn.au/dropbear/dropbear.html https://matt.ucc.asn.au/dropbear/dropbear.html
- girvo 12y agoCurious as to whether something like this would be good for embedded work, as I'm working on a "modern" HP 200LX[0] running RetroBSD[1] possibly, all off a PIC micro controller (!) and want to work out how to get some form of SSH into it. Will be interesting to attempt to port it regardless of what happens though! ---- [0] http://en.wikipedia.org/wiki/HP_200LX http://en.wikipedia.org/wiki/HP_200LX [1] http://retrobsd.org/wiki/doku.php http://retrobsd.org/wiki/doku.php
- zokier 12y agoDropbear is usually the ssh-server of choice for small systems: https://matt.ucc.asn.au/dropbear/dropbear.html https://matt.ucc.asn.au/dropbear/dropbear.html Quick check shows that both compile to about 220K without any tuning on x86_64. While I wouldn't use that figure as serious comparison, it shows that they are in the same ballpark in size.
- sanxiyn 12y agoI find use of TweetNaCl curious. For curve25519, why wouldn't one use http://code.google.com/p/curve25519-donna/ http://code.google.com/p/curve25519-donna/ instead? djb's cryptography is great, but djb's implementations leave something to be desired.
- beagle3 12y agoWhat do they leave to be desired? Style is a personal preference, of course - but merit? Every single djb implementation I've seen (a lot of them) is fast, efficient, secure, and clear, once you get his style.
- friendlypedant 12y agoMostly his disregard for packaging conventions and unwillingness to acomodate them. The code is usually A grade, but the odd use of the filesystem, runtime configs, daemons etc. means it will never get into any mainstream distro without heavy patching. There's a reason why libsodium's tag line is "P(ortable|ackageable) NaCl-based crypto library". The word of distros/packagers isn't gospel, but it counts for a lot, considering that (for better or worse) most people won't even think about using something not available as a package.
- beagle3 12y agoI've been doing "apt-get install daemontools daemontools-run" since forever on Ubuntu; it might take a little longer to get into the repositories, but it does get into mainstream distros with almost no patching -- comparable, IIRC, to packages of similar size and complexity that do not have an upstream debian packaging.
- pjscott 12y agoThe usual problem with DJB's implementations is not that they're incorrect or slow or insecure -- far from it! -- but that they're awkward to integrate with the rest of the world, may require weird build configurations, and are hard for anybody else to modify. Well, TweetNaCl is really easy to integrate with the rest of the world, since it's just a single portable .c file, and the speed is surprisingly good, and its functionality and API are stable enough that you probably don't need to modify it. So, I don't see the problem here. If these guys had tried to cobble together a replacement for NaCl out of pieces like the curve25519-donna code, that would be a problem, because there's more potential to screw that up.
- beefhash 12y agoDaemontools and inetd? May I ask where the systemd socket activation support is?
- pjscott 12y agoIt's easy, and requires no modification to TinySSH. See here: http://0pointer.de/blog/projects/inetd.html http://0pointer.de/blog/projects/inetd.html
- mhogomchungu 12y agoHow is code like below "easily auditable"? keydir = *++argv; if (!keydir) die_usage(); or if (*x == 'v') { if (flagverbose >= 2) flagverbose = 3; else flagverbose = 2; continue; } why put multiple statements on the same line if you have nothing to hide?[1] [1] https://www.kernel.org/doc/Documentation/CodingStyle https://www.kernel.org/doc/Documentation/CodingStyle
- colomon 12y agoIt's an SSH server. If dealing with simple cases of more than one statement on the same line is the worst bit of auditing it, it is indeed an easily auditable SSH server. (Not that I would have written either line that way, mind you. But there's no real challenge understanding them.)
- deleted 12y ago[deleted]
- hf 12y agoThe answer seems to me quite simple: because they have a different coding style. Just as no one is bound to K&R or the GNU style, nothing suggests that crypto code needs to follow Linux kernel conventions. Value consistency above everything. Honestly, I am not convinced that the peculiar if-style isn't actually helping readability and refactoring. Note, that a Apple-style "goto break" bug might be harder to construct, when your one-line if's look like this: some_code; if (something) die(message); other_code; Now the surrounding indentation does not suggest that there's an extendable block where there in fact isn't, as with Kernel style: some_code; if (something) die(message); other_code; To be perfectly honest, the authors' style reminds me a bit of my younger self's style: keep logically connected pieces of code tightly together. You (presumably) and I have beaten ourselves into submission to the Linux style; the authors' haven't. On a side note: your second example even seems to suggest that the authors made some effort at additional readability by refraining from using the ternary operator construct.
- yp_all 12y ago"You (presumably) and I have beaten ourselves into submission to the Linux style; the authors' haven't." An awakening! Is it really so terrible to have things compile quickly and without the usual ./configure nonsense? It seems there are an infinite number of ways an author can organise her project using ./configure; for every one I have to spend time figuring out what they have done. One of my favourite aspects of djb's build approach (which is what is being used here) is that it's easier (than with the popular build systems) to change compiler and linker options and make static binaries: in most cases, simple edit the conf-* files. Thankfully, authors who use djb's approach usually do not vary much from the model. This means less time spent figuring out how things are organised. I like (portable) open source software that compiles quickly and cleanly. djb has continued to deliver on this point. Nice to see someone discovering this build system for the first time.
- wolf550e 12y agoWhich ssh clients can connect to this? For example, can putty connect to this?
- throwaway2048 12y agoOnly 6.5/6.6 versions of the OpenSSH client can connect to this server. 6.5 is the first (and as far as I know only) ssh client that introduced chacha20 and ed25519 support.
- tinco 12y agoWhat use is an sshd that doesn't support SCP? I think to most people that is a core feature, I'd be surprised if it wasn't a requirement for git for example. It sounds like it's small enough perhaps for a direct port to a safe language like rust, that would be interesting (to me at least).
- xiaq 12y agoUse this as a poor man's scp: tar c path/to/files | ssh host tar x
- baudehlo 12y agoThis should work perfectly well with rsync -e ssh. Which is what you should use anyway.
- X-Istence 12y agoGit doesn't require scp.
- thristian 12y agoTo be fair, OpenSSH's sshd doesn't have support for scp either. scp invokes ssh to connect to the target host and launches another scp instance there to talk to. There's no reason that wouldn't work with TinySSH too.
- hf 12y agoOutstanding! Not only are the slightly mysterious authors of this project not inventing their own crypto, they rely on djb's[0] much acclaimed NaCL/TweetNaCl. The codebase is accordingly small: $ wc -l source/*/*c | tail -n1 11308 total $ wc -l source/crypto/*c | tail -n1 1293 total The first line suggests a measure of total code ballast, whereas the second incantation might hint at the amount of core crypto code. The latter might be a good starting point for any auditing endeavours. Incidentally, I am impressed by the spirit of organisation that the source tree permeates. Both crypto/ and tinyssh/ source trees sport corresponding -test directories and a debian/ tree has already been added. Initially, I felt irritation by the consistent lack of documentation (no README, no AUTHORS, almost no comments, it seems). Browsing the source, however, I grow convinced that this from a conviction that out-dated or redundant documentation is the greater evil. [0] Daniel J Bernstein - author of qmail, daemontools and long-time promoter of full disclosure. https://en.wikipedia.org/wiki/Daniel_J._Bernstein https://en.wikipedia.org/wiki/Daniel_J._Bernstein
- auvrw 12y agothis is pretty slick. i'm glad people are making more modular implementations of the programs that i depend upon in addition to creating fancy new programs that i might find useful. for comparison, the openbsd version of openssh's sshd compiles just under 20k lines, and the openbsd version is supposed to be much smaller than the "portable" version of openssh.
- thirsteh 12y agoYou may actually be underselling djb: He both knows how to write quality software, and is arguably the most productive cryptographer around.
- akerl_ 12y agoAwesome! A few questions/thoughts: Right now, you're suggesting it be downloaded via HTTP, which isn't exactly the best way to get my secure daemons. Any chance you could move that to HTTPS? Semi-related: any chance you'll be making a repo available in some form? (I'm preferential to GitHub, but really anything that lets us follow source changes and open bug reports would rock) I would love to see an audit of this by some 3rd party entity. Glad to see folks working to build new tools from such solid building blocks!
- friendlypedant 12y agoEvery function name in tinyssh/buf.c starts with an underscore... To quote the standard: "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces. ... If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined." -- ISO/IEC 9899:1999, Section 7.1.3 Reserved Identifiers
- invernomut0 12y agoRob Landley doesn't seems to be too excited about it http://www.landley.net/notes.html#31-03-2014 http://www.landley.net/notes.html#31-03-2014