[HN Gopher] TinySSH is a small SSH server using NaCl, TweetNaCl
___________________________________________________________________
TinySSH is a small SSH server using NaCl, TweetNaCl
Author : ThreeHopsAhead
Score : 249 points
Date : 2024-03-24 10:04 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| itpcc wrote:
| Poor, poor site. They got HN hug of death.
| Brian_K_White wrote:
| I can only assume it's idiots downvoting this, who think you
| are bashing the site instead of sympathising with it.
| seniorivn wrote:
| https://github.com/janmojzis/tinyssh
| k8sToGo wrote:
| What is the difference between this and dropbear ssh?
| themoonisachees wrote:
| I don't think there's much of one. The concept in itself isn't
| really useful, I've never seen someone go "you know the real
| problem with sshd? It's too bloated".
|
| It is slightly useful to put in smaller devices that don't have
| much space but I think it still relies on top many linux
| facilities to be an appropriate fix for that too. Still, cool
| project.
| dhon_ wrote:
| I suspect the average openssh-server user just uses it for
| remote terminal access and copying files. Reducing the attack
| surface by dropping features and outdated standards is
| certainly valuable.
| maxcoder4 wrote:
| Dropbear ssh is very useful when you have a full disk
| encryption on a remote server and want to be able to decrypt
| it after a reboot.
| Nextgrid wrote:
| There's technically no reason OpenSSHd can't also be used
| in this context. Maybe 2 decades ago there was a legitimate
| performance/disk space reason which is why Dropbear was
| preferred for this use case (and the convention remains to
| do this day), but nowadays the couple megabytes of
| difference in your initrd between using Dropbear and
| OpenSSH won't matter.
| m45t3r wrote:
| > There's technically no reason OpenSSHd can't also be
| used in this context.
|
| For initrd you generally prefer static binaries. Not
| saying that OpenSSHd doesn't build statically, but having
| less code and dependencies makes it easier to statically
| compile.
|
| But yes, technically there is no reason to not use
| OpenSSHd, but in practice having a smaller and more self
| contained binary helps considering that you would want
| the bare minimum during initrd.
| akerl_ wrote:
| What dependencies does openssh have?
| mkj wrote:
| OpenSSL
| 1oooqooq wrote:
| if you don't care for v1 and odd cyphers, --without-
| openssl
| chasil wrote:
| This server is very restricted compared to dropbear.
|
| -passwords are not allowed, only keys
|
| -only a single AEAD cipher is supported, and a single elliptic
| curve for key exchange
|
| -root cannot be locked out with this server
|
| -the key restrictions available in OpenSSH are not supported
|
| -the server does not use dynamic memory, and has a better
| security record than dropbear
| bjoli wrote:
| It is smaller and supports less features. Dropbear does
| password auth and x11 agent forwarding iirc.
| Columbo818 wrote:
| Dropbear claims to be RFC-compliant, but isnt. Proof here:
| https://www.cvedetails.com/cve/CVE-2021-36369/
|
| TinySSH doesnt claim to be compliant, and isnt. Does less in
| exchange for a reduced attack surface.
| mkj wrote:
| That CVE is a UI confusion issue in the client, I'm not sure
| exactly what bit the reporter thought was non-RFC compliant.
| ThreeHopsAhead wrote:
| dropbear has the goal of being small and light on ressources
| while still providing featurefull ssh support.
|
| tinyssh is small because it only implements a tiny subset of
| SSH that is needed for secure basic SSH connections. It only
| includes few crypto primitives excluding even RSA.
|
| There is considerable overlap in the two and you can reach
| something similar to tinyssh by compiling dropbear with only
| few select features, but tinyssh aims to be as secure and
| attack surface minimized as possible out of the box.
|
| Another notable difference:
|
| > no dynamic memory allocation - TinySSH has all memory
| statically allocated (less than 1MB)
| underdeserver wrote:
| In this day and age it's probably best to use a Rust-based SSH
| server if you're at all replacing the built-in one.
| jddj wrote:
| Can you justify this further in the context of this specific
| offering which appears not to manage dynamic memory?
| mronetwo wrote:
| You don't need further justification if you just agree that
| using Rust makes everything automatically better...
| somehow... and you need to agree with it without evidence.
| hughw wrote:
| I admit I am susceptible to this thinking though.
| latexr wrote:
| In this day and age, it's probably best to understand that
| blindly suggesting something should be in Rust is
| indistinguishable from zealotry. Or from mockery of the people
| who do it.
| FergusArgyll wrote:
| I feel like someone has to say this:
|
| _What about LISP?!_
| pquki4 wrote:
| This kind of comment had become a joke these days, especially
| when you say that under a project written in C. Nobody is going
| to even think about that until Rust has as good portability as
| C.
| yjftsjthsd-h wrote:
| Excellent point; which production-grade rust ssh server would
| you recommend?
| bazzargh wrote:
| A better question to ask would have been, why settle for just
| memory safety - does a formally verified sshd exist? That kind
| of thing seems to be implemented more in OCaml and F#, like
| Project Everest, which has formally verified implementations of
| primitives (HACL) TLS, QUIC, and Signal https://project-
| everest.github.io/ ... ssh is notably missing?
|
| I had a dig and found that ssh had in fact been done 9 years
| ago, tho it doesn't seem to have made it to a distribution:
| it's an offshoot of the CryptoVerif project[1] (which is, maybe
| unsurprisingly, under the umbrella of the same Prosecco team at
| Inria who worked on Project Everest). In 2015 Bruno Blanchet
| and David Cade wrote a paper "From Computationally-Proved
| Protocol Specifications to Implementations and Application to
| SSH"[2] which describes using CryptoVerif to generate an
| implementation of SSH from the spec; the code is in the
| CryptoVerif tarball, but someone's helpfully put that up on
| github if you want a look[3]
|
| The eye opening bits in the paper (given the claims of tinyssh
| to be small at < 100k words): "We have verified that our client
| and server correctly interoperate with OpenSSH...in order to
| give an idea on the amount of code this work represents, the
| CryptoVerif specification amounts to 331 lines of code, and we
| generate from it 531 lines of OCaml, split among multiple
| files. The manually written code representing the primitives
| and the authentication and connection protocols amount to 1124
| lines."
|
| The bad news would be that it's not very performant: 30MB/s
| compared to 90MB/s for openssh on the same hardware, in the
| paper. Since HACL is from the same stable and was designed to
| perform well as well as be verified, it might be worth dusting
| off and seeing if this could be made more usable. The
| implementation probably has value even if just as a test
| oracle.
|
| [1]: https://bblanche.gitlabpages.inria.fr/CryptoVerif/
|
| [2]:
| https://bblanche.gitlabpages.inria.fr/publications/CadeBlanc...
|
| [3]:
| https://github.com/mgrabovsky/cryptoverif/tree/master/implem...
| the official implementation appears to be here now
| https://gitlab.inria.fr/bblanche/CryptoVerif/-/tree/master/c...
| CarRamrod wrote:
| >easy auditable - TinySSH has less than 100000 words of code
|
| Is approximately one hundred thousand words really easily
| auditable?
| latexr wrote:
| > approximately one hundred thousand words
|
| According to the index page, the current release is closer to
| half of that at 62989 words.
|
| Which is (allegedly, don't trust the number too much) as long
| as 2001: A Space Odyssey.
|
| https://www.readinglength.com/book/isbn-0451452739
|
| Not a long book, but in the context of code I wouldn't consider
| that _easily_ auditable.
| rthnbgrredf wrote:
| Well, at least it fits into GPT-4 Turbo context. I think we are
| not far away from a fully automated audit that can at least
| check for 99% of common bugs and security issues.
| edf13 wrote:
| Not really, especially when they have:
|
| > TinySSH has its own crypto library
| tptacek wrote:
| Seems like the wrong question. Rather: if it's easily
| auditable, who's audited it so far?
| loeg wrote:
| I think they're both pretty reasonable questions!
| nemoniac wrote:
| What is a "word of code"? I've seen "lines of code" but what's
| a "word" in C?
| teddyh wrote:
| Maybe _M-x count-words_?
| rand846633 wrote:
| Cool project! There are many use cases where this is a good tool!
| Allways great to have another alternative to some other great
| tools.
| throw0101c wrote:
| Currently Slashdotted:
|
| * https://web.archive.org/web/20240324101238/https://tinyssh.o...
| sylware wrote:
| I am pleased to see another "small"-is-beautifull alternative of
| a critical network protocol, and in plain in simple C (I am sorry
| for the fan boys of absurdely complex computer languages...).
|
| There will be plenty of compiler generated holes, and other
| security issues, but keep your head above the water and fix all
| of them, you are going for the long run there.
|
| We also have drop-bear, which is in between openssh and tinycc if
| I recall properly.
|
| I have to admit... I may deploy tinyssh for my everyday work (I
| rarely code directly on my workstation, usually I am "away" and
| do ssh to it via 4g internet IPv6/ssh).
|
| Now a bit of whining (come on, we are on HN), microsoft github is
| always a bad idea, should move to a fully noscript/basic (x)html
| friendly git repository (aka not gitlab based for instance, yet).
| pquki4 wrote:
| You are fighting a losing battle if you don't want to see
| GitHub links on HN.
| serf wrote:
| it's still worthwhile to point out the issues for people who
| have recently jumped into the occupation/hobby and haven't
| yet had the time to meditate on why Microsoft having the keys
| to the worlds' software kingdom might be A Very Bad THing
| down the line.
| jonathaneunice wrote:
| If neither GitHub nor GitLab, what are you recommending? There
| are a few other non-DIY hosted options, but it's hard for me to
| translate your "fully noscript/basic (x)html friendly" spec
| into an actionable list of options. Or is this a "host it
| yourself" / DIY plea?
| gkbrk wrote:
| Soucehut works with noscript. No need to host or DIY
| anything.
|
| Codeberg has a message that says "This website requires
| JavaScript." but I was able to use it without JS to browse
| around and look at code properly.
| numpad0 wrote:
| tinysshd doesn't implement unsafe features (such as password or
| hostbased authentication)
|
| Isn't password support useful for shared devices, like printers
| and routers? How would one enroll his personal keys on something
| like a car?
| Retr0id wrote:
| The device can generate a fresh keypair and show you the
| private key via a QR code or some other output mechanism. Then
| you can log in and enroll your real keys.
| bretthoerner wrote:
| tinyssh is great. One use case for it that people may not know
| about: using it during Linux boot so you can remotely unlock
| encrypted drives. I have a headless NAS server that uses dm-
| crypt/LUKS under ZFS. When I update my kernel/ZFS I remotely
| reboot the server, wait a few seconds, and then ssh into a
| tinyssh powered encryption key prompt to unlock the drives. (I am
| immediately booted from ssh, as tinyssh exits.) I can then ssh
| again a few seconds later and I'm hitting openssh on a fully
| booted machine that wasn't able to open the drives without my
| intervention.
|
| https://github.com/grazzolini/mkinitcpio-tinyssh
| gymbeaux wrote:
| Usually I use DropBear for this. Do you know if one is
| necessarily better than the other? DropBear I think is what
| RHEL docs recommend for remote boot disk decryption.
| bretthoerner wrote:
| Ah, I've never used DropBear. I don't know how one could be
| better than another for my simple use case, honestly.
| jethro_tell wrote:
| I use normal opensshd for this.
|
| No reason to support two ssh daemons when you can do it with
| one.
|
| The difference in size on your init image is minimal and you
| probably aren't even trying to optimize for space there.
|
| If you don't know the size of your rd off the top of your head
| then it almost certainly doesn't matter.
| bretthoerner wrote:
| All fair, I guess I just landed on mkinitcpio-tinyssh first
| and it was my introduction to the idea, and only took a few
| seconds to setup. I'll switch to openssh if I ever have
| issues, but this has been working fine for many years, so I'm
| no rush.
| jethro_tell wrote:
| Makes sense. Probably more work to go off the beaten path
| then to maintain two configs
| streb-lo wrote:
| Probably not more popular because (for reasons I do not know)
| the mkinitcpio hooks Arch Linux provides are only for tinyssh
| and dropbear:
|
| https://wiki.archlinux.org/title/dm-
| crypt/Specialties#Remote...
| krab wrote:
| A tool based on Dropbear that does exactly this, automatically.
|
| https://github.com/ViktorStiskala/cryptsetup-ssh-unlocker
| teddyh wrote:
| The documentation for _Cryptsetup SSH unlocker_ states " _To
| further limit the attack possibility, you should use
| monitoring and possibly disable SSH unlocker in the case of
| unexpected behavior._ " Mandos has a built-in feature to deal
| with this, enabled by default.
|
| (Again, disclosure: I am the co-author of Mandos.)
| forty wrote:
| Question: when remotely unlock the boot disk via ssh, how do
| you make sure the boot has not been compromised and that you
| are not just sending the password to the bad guys?
|
| At some point I wanted to do something with utrablue [1], to
| work over network rather than Bluetooth, but then it was in go
| and I got lazy suddenly :)
|
| [1] https://github.com/ANSSI-FR/ultrablue
| bretthoerner wrote:
| > how do you make sure the boot has not been compromised and
| that you are not just sending the password to the bad guys?
|
| In my case, I can't. This is a NAS in my house and this is
| mostly to prevent me from having to go to another room and
| plug in a monitor and keyboard. (Also, I've done this from
| across the country after a power outage.)
|
| The threat vectors I'm protecting against are I guess mostly
| theft of the entire machine, or forgetting to wipe the drives
| when I eventually toss them out. Mostly, it's just fun
| practice because I'm a nerd and every drive should be
| encrypted.
|
| For my use-case, the auto-unlock-by-polling-a-specific-LAN-IP
| linked in this thread would probably be fine, for example.
| jethro_tell wrote:
| This is mostly me but the case that's the most common is
| that a disk can't be wiped because its dead. Gotta do that
| before hand.
| aftbit wrote:
| Well you can always drill holes in the platter, or hit
| them with a strong magnet, or just separate them and toss
| them in the trash. Unless you're fighting the NSA, you
| can probably get away with enough physical destruction to
| make recovery challenging.
| jsmith99 wrote:
| This is what a TPM is designed to prevent, but they're not
| very popular in Linux community.
| rand846633 wrote:
| What are the best options to solve this problem? It's a hard
| problem imho for most threat models.
|
| If the booting machine has been compromised and i use my usb
| connected keyboard to enter the full disk encryption key I
| would run into the exact same issues, no?
| fbdab103 wrote:
| If you have physical access, seems way easier to put a
| keylogger directly into the keyboard.
| pmorici wrote:
| TPM and checking your physical security boundary hasn't been
| breached.
| mbreese wrote:
| Isn't there a host SSH key involved?
|
| The server itself may have been physically breached, and if
| so you can't trust anything. But, if your host key matches,
| you should be confident that at least you're logging into the
| correct machine (there was no IP takeover).
| toast0 wrote:
| I have disk encryption on a remote server on cheap low-
| asssurance hosting, and I do it so I don't have to worry
| about what happens when the disks are recycled. If I could
| (easily) automate entering the key on boot, I would (but I'm
| running FreeBSD, so Linux solutions don't help). But I don't
| need to reboot often and the hardware is fairly reliable, so
| eh.
|
| This is for my personal hosting which if someone wants to
| take over, I guess I'd be more curious than upset.
| crote wrote:
| In theory this _should_ be a perfect match for TPM-powered
| secure booting: your machine starts every time with a clean
| TPM, which validates the BIOS into it, which validates the
| bootloader into it, which validates the kernel into it, which
| derives an RSA private key from the resulting TPM state. If
| an attacker compromises it, it 'll present the wrong host key
| and you get a big fat error message.
| teddyh wrote:
| Mandos tries to mitigate this problem by periodically
| checking that the rebooting server is still up. Exactly how
| this is done is configurable, but by default it uses ssh-
| keyscan to check if the server is up and using the SSH server
| key from its normal encrypted root file system. If a server
| is ever down too long (configurable, default 5 minutes), the
| Mandos server will "disable" that server in its server list,
| and not provide the password to that server anymore.
|
| The idea is that you should configure the timeout to be long
| enough to allow for a normal kernel panic and reboot, but
| hopefully short enough that it would be hard for anyone to
| compromise the server in that time. It's not a perfect
| solution, but it's the best anyone has come up with as far as
| I know.
|
| (Disclosure: I am a co-author of Mandos.)
| babuskov wrote:
| I thought that everyone has switched to Clevis + Tang for that?
|
| https://access.redhat.com/documentation/en-us/red_hat_enterp...
|
| It's fully automated and supposed to be much more secure.
|
| Has anyone got experience with it?
| traceroute66 wrote:
| > I thought that everyone has switched to Clevis + Tang for
| that?
|
| Clevis+Tang is good. There's also Keylime which takes a
| different approach to the same[1].
|
| [1] https://keylime.dev/
| soraminazuki wrote:
| IIUC whether that is secure depends on your threat model. For
| example, how good is automated unlocking compared to
| unencrypted drives in a homelab setup?
| slug wrote:
| For debian/ubuntu users, there's also dropbear-initramfs
| package with same functionality (works with any fs
| luks/ext4/lvm/zfs/etc).
|
| https://packages.debian.org/bookworm/dropbear-initramfs
| https://packages.ubuntu.com/jammy/dropbear-initramfs
| justin_oaks wrote:
| I've used this for several years now. It works well and is
| relatively easy to set up.
| teddyh wrote:
| Note: Mandos is also in Debian and Ubuntu.
|
| (Obligatory disclaimer: I am a co-author of Mandos)
| orev wrote:
| This is more or less the RedHat based solution to do this using
| openssh: https://github.com/gsauthof/dracut-sshd
| https://copr.fedorainfracloud.org/coprs/gsauthof/dracut-sshd...
| teddyh wrote:
| There's a _non-interactive_ solution to rebooting safely with
| encrypted disks: Mandos <https://www.recompile.se/mandos>
|
| Reboot your server while you sleep!
|
| Disclosure: I am a co-author of Mandos.
| jethro_tell wrote:
| This is really cool. I'm going to give this a try!
| jvanderbot wrote:
| The license is "CC0 1.0 Universal"
|
| In light of this post outlining a bug in early CC licenses:
| https://doctorow.medium.com/a-bug-in-early-creative-commons-...
|
| Discussed here: https://news.ycombinator.com/item?id=39610509
|
| Does this need updating?
|
| EDIT: based on some discussion, it does need updating, but not
| for the reason I thought. I filed a suggestion here:
| https://github.com/janmojzis/tinyssh/issues/85
| gkbrk wrote:
| Is that necessarily a bug? If you use Disney content without a
| license they won't give you a 30-day period to keep mis-using
| it. Same with using Oracle software. Why should people who
| create CC content provide such a grace period?
| jvanderbot wrote:
| Validity of the post aside, there are real-world examples of
| this license being abused by third parties. Given the cost is
| very low to just change the license, I think it might be
| worth considering.
| skissane wrote:
| To be clear, the issue we are talking about here does not
| exist for the CC0 license TinySSH is using. CC0 lacks a
| termination clause, it wouldn't make sense for it to have
| one. It only exists for other CC licenses, like the
| (earlier versions of) CC-BY(-NC/-SA).
|
| CC0 has _other_ issues - some people (e.g. Red Hat Legal)
| are concerned about its language explicitly excluding
| patent and trademark rights, and think that is legally
| inferior to other public domain declarations (such as The
| Unlicense) which don 't mention that topic at all.
|
| In a declaration/license in which patents and trademarks go
| unmentioned, if the original author sues you on those
| grounds, you can try to argue that by releasing the
| software they gave you an implied patent/trademark license
| - that argument may or may not win in Court, but at least
| it has a chance. With language in the declaration/license
| explicitly excluding patents and trademarks (like CC0 has),
| that argument is likely dead-on-arrival.
| saagarjha wrote:
| Because people who create CC content typically do so because
| they want it to be available to good-faith uses, which may
| not always follow the exact requirements of the license by
| accident
| jasomill wrote:
| For the reason given by Doctorow in the linked article:
|
| _If you put a CC license on your work, its explicit message
| is, "I want you to re-use this." Not "I am a pedantic asshole
| with a fetish for well-formed attribution strings." The point
| of CC is not to teach the world to write attribution strings:
| it is to facilitate sharing and re-use. If you are a good-
| faith user of CC licenses, then your response to an incorrect
| attribution string should be a request to correct it, not a
| threat to sue for $150,000 in statutory damages._
| fanf2 wrote:
| Not for that reason.
|
| The copyleft trolls that Doctorow wrote about are using a
| termination clause in attribution-required CC licences.
| (Remember, there are lots of different CC licences with varying
| requirements on licensees.) CC0 doesn't impose requirements on
| licensees nor does it have a termination clause, so it isn't
| affected by these trolls.
|
| However, CC0 is not good as a software license. It is
| explicitly restricted to being a _copyright_ license. If there
| are patents covering the software, CC0 does _not_ give you
| permission to exercise the patented invention.
|
| It's better to use 0BSD or MIT-0 instead, which grant
| permission to use the software without weird exceptions.
| jvanderbot wrote:
| I copied your comment to
| https://github.com/janmojzis/tinyssh/issues/85
|
| If author/maintainer doesn't frequent HN, perhaps discussion
| there might get some action.
| fanf2 wrote:
| You can find a more authoritative but longer explanation in
| an OSI FAQ about CC0 https://opensource.org/faq#cc-zero and
| the related discussion
| http://lists.opensource.org/pipermail/license-
| review_lists.o...
| makeworld wrote:
| 0BSD and MIT-0 don't mention patents explicitly though, few
| licenses do. I only know of two:
| https://blueoakcouncil.org/list
| fanf2 wrote:
| They don't mention copyright explicitly either.
| skissane wrote:
| > It's better to use 0BSD or MIT-0 instead, which grant
| permission to use the software without weird exceptions.
|
| 0BSD and MIT-0 are zero attribution ultra-permissive
| copyright licenses, aka public domain-equivalent copyright
| licenses.
|
| CC0 is a public domain declaration with a fallback copyright
| license for jurisdictions (such as Germany) which don't
| recognise public domain declarations.
|
| There is a big technical difference between the two, in some
| jurisdictions (such as the US) - CC0 puts something in the
| public domain, MIT-0/0BSD technically doesn't. A real
| difference in theory, maybe not much in practice.
|
| If the author really cares about the public domain part,
| something like Unlicense is a better option than MIT-0/0BSD -
| an actual public domain dedication, without the
| patent/trademarkconcerns which exist regarding CC-0.
|
| If they want to make the maximum possible number of people
| happy, they could even use disjunctive licensing, e.g. CC-0
| OR Unlicense OR MIT-0
| Hendrikto wrote:
| Shame that it does not support ed25519-sk. Apart from that, it
| looks very promising.
| yodon wrote:
| Is NaCl still a thing? Genuine question as I've not heard it
| mentioned in years.
|
| [edit added] For those, like me, who thought this was using
| Google's NaCl (sandboxed C++), it's actually using Daniel
| Bernstein's NaCl (cryptography library).
| cchance wrote:
| Cool but something i saw that was weird, this may be the first
| repo i've ever seen to advertise ... words of code, i've always
| seen secure repos advertise their "in only X LOC" seeing words of
| code as a metric was funny
| creshal wrote:
| It's unusual, but IMO makes sense, as it encapsulates
| complexity better than LOC do, because the latter are more
| sensitive to formatting preferences etc.
|
| Books are also measured in words too (also for category
| thresholds, e.g. between a novella and a full novel), so
| there's precedent too.
| oxryly1 wrote:
| Made it seem like it was written in Forth.
| fbdab103 wrote:
| The Wren language[0] uses semicolons as its size metric:
| Wren is small. The VM implementation is under 4,000 semicolons.
| You can skim the whole thing in an afternoon. It's small, but
| not dense. It is readable and lovingly-commented.
|
| [0] https://wren.io/
| justin_oaks wrote:
| Semicolons seems an odd metric since complexity is often
| introduced by if-else branches, while loops, and function
| declarations. Each of those doesn't involve semicolons.
| keepamovin wrote:
| I like this person's work. Check it out:
|
| https://github.com/janmojzis
|
| - _tinyssh_ - TinySSH is a small server with less than 100,000
| words of code. Language: C. Stars: 1.1k. Forks: 65.
|
| - _acmeshell_ - Shell-style client for LetsEncrypt. Language:
| Python. Stars: 31. Forks: 6.
|
| - _dq_ - Recursive DNS /DNSCurve server and command-line tool to
| debug DNS/DNSCurve. Language: C. Stars: 23. Forks: 1.
|
| - _pstree_ - Unix process tree viewer. Language: C. Stars: 14.
| Forks: 2.
|
| - _ntpserver_ - Pure python NTP server. Language: Python. Stars:
| 11. Forks: 3.
|
| - _httpfile_ - Httpfile is an HTTP server derived from
| publicfile-0.52.
|
| A collection of tiny, standard net utils and servers. Gives the
| impression the person does it to _craft_ something, and to
| understand. Inspiring and impressive!
| 1oooqooq wrote:
| some of those look like spoofs?
| Panino wrote:
| > dq - Recursive DNS/DNSCurve server and command-line tool to
| debug DNS/DNSCurve
|
| I use dqcache, the DNSCurve-aware recursive resolver from the
| dq package, and love it.
| vzaliva wrote:
| It looks like a good choice for access to small embedded devices.
| Except the missing port forwarding feature.
| traceroute66 wrote:
| I don't see anyone sensible replacing OpenSSH with anything else
| for two fundamental reasons:
|
| 1. OpenSSH has more eyes on it and more deployments than almost
| any other piece of non-OS/kernel software on the planet. By this
| stage in its life, it is very mature. Look at the vulnerability
| database, OpenSSH has not had a serious _REMOTE_ vulnerability
| for a long time, all the recent vulnerabilities require the
| attacker to have some form of pre-existing host access
| (https://www.openssh.com/security.html).
|
| 2. OpenSSH comes from the house of OpenBSD. Those guys are
| serious about writing secure code and have a well-established
| track record. These days you can also compile OpenSSH against
| LibreSSL instead of OpenSSL.
|
| Instead of replacing OpenSSH, most people would be better off
| spending their time switching OpenSSH to key-based-auth only and
| then making a few simple configuration changes to further harden
| OpenSSH. Starting with the config ideas proposed by Mozilla[1]
| and adding in options such as the built-in rate-limiting config
| options (PerSourceMaxStartups, PerSourceNetBlockSize and
| friends).
|
| [1] https://infosec.mozilla.org/guidelines/openssh
| wibblewobble125 wrote:
| Bad reasons to trust code:
|
| * "Many __informal__ eyes have probably looked at it"
|
| * Lack of recent __number__ of (known) vulnerabilities
|
| * "Serious guys" (appeal to authority)
|
| I think you're using short-hand, but perhaps the short-hand
| should be different. E.g.
|
| * A list of audits by date, independent organization, is
| provided __here__ which is evidence of review
|
| * The vulnerability acknowledgement, correction and release
| process is prompt, accurate and detailed, which is documented
| __here__
|
| * XYZ coding, testing, fuzzing, proving, bounty, integration
| with other systems, documentation, defaults etc. practices are
| used in the interest in hardening the code, limiting moving
| parts, attack radius, etc.
| aAaaArrRgH wrote:
| Given that it's a small SSH server, I wonder how feasible it
| would be to rewrite it in a memory-safe language. C doesn't feel
| like the most security-conscious (and, quite frankly, legible)
| language in this day and age.
___________________________________________________________________
(page generated 2024-03-24 23:00 UTC)