Dropbear SSH, a lightweight alternative to OpenSSH(librebyte.net)
librebyte.net
Dropbear SSH, a lightweight alternative to OpenSSH
https://www.librebyte.net/en/network/dropbear-ssh-a-lightweight-alternative-to-openssh/
109 comments
A long time ago, when I tried something like that, I was stymied because the SSH server did not have permissions to write to any directory which the document readers etc. could see.
Is this sort of thing still a problem? How did you get around it?
Is this sort of thing still a problem? How did you get around it?
I haven't used SimpleSSHD but I use Termux, which gives me a "normal" terminal (no root required).
Since Android 8 I've lost write access to general locations in the sd-card but I still have read access, as well as read+write on the internal storage.
It has an ssh server which can be nice if you want to edit some files on the phone remotely but that's not needed for rsync. I have a shortcut on the home screen which triggers a script that runs an rsync command for photos and other stuff I want to backup. Also use it to reverse-sync a folder from my NAS, want to send a file to the phone? But the file in that folder and run the script.
Since Android 8 I've lost write access to general locations in the sd-card but I still have read access, as well as read+write on the internal storage.
It has an ssh server which can be nice if you want to edit some files on the phone remotely but that's not needed for rsync. I have a shortcut on the home screen which triggers a script that runs an rsync command for photos and other stuff I want to backup. Also use it to reverse-sync a folder from my NAS, want to send a file to the phone? But the file in that folder and run the script.
I think that you need to run the command "termux-setup-storage" to be able to r/w again:
https://wiki.termux.com/wiki/Termux-setup-storage
https://wiki.termux.com/wiki/Termux-setup-storage
Thanks, doesn't work though. I have write access to the private directory for termux on the sdcard but nothing else (which unfortunately breaks my usage, I'll report it to them any day to see if a fix is possible).
This is the way Termux works so far, External storage: Storage on external SD cards. Each app has a private folder on the external SD card, and interchange between them needs to use a special API not yet available in Termux.
https://wiki.termux.com/wiki/Internal_and_external_storage
https://wiki.termux.com/wiki/Internal_and_external_storage
It worked fine in Android 7, when I updated to 8 my scripts started getting permission-denied errors on writes.
I don't see anything in that link that says that sdcard (outside private folder) is read-only.
The way I read "Each app has a private folder on the external SD card, and interchange between them needs to use a special API not yet available in Termux." is that I can't read another applications private folder, but I'm not trying to - I just want (write+delete) access to the publicly accessible parts of the sdcard (lots of other applications do this, and termux did in Android 7).
I don't see anything in that link that says that sdcard (outside private folder) is read-only.
The way I read "Each app has a private folder on the external SD card, and interchange between them needs to use a special API not yet available in Termux." is that I can't read another applications private folder, but I'm not trying to - I just want (write+delete) access to the publicly accessible parts of the sdcard (lots of other applications do this, and termux did in Android 7).
Well I have Android 7 and termux works in the way you described at first: I have write access to the private directory for termux on the sdcard but nothing else... other applications can access every DIR in sdclard due implements SAF: https://developer.android.com/guide/topics/providers/documen... and I think this what termux doc refers to.
It was never an issue for me. Giving the SimpleSSHD docs a quick glance, the app itself does not operate as root, although its packaged subcomponents like rsync optionally can depending on what shell you point them to.
My phone isn't rooted. Everything in /storage/emulated/0 backs up without issue. Obviously not a full system backup, but all my data none the less.
With regards to write permission, I've only ever issued any writes to my image folders to prune photos or screenshots older than xx days that have already been backed up. On that note, freeing up 20GB of space instantly with a single command is incredibly satisfying (compared to the MTP hell alternative).
My phone isn't rooted. Everything in /storage/emulated/0 backs up without issue. Obviously not a full system backup, but all my data none the less.
With regards to write permission, I've only ever issued any writes to my image folders to prune photos or screenshots older than xx days that have already been backed up. On that note, freeing up 20GB of space instantly with a single command is incredibly satisfying (compared to the MTP hell alternative).
If you only need a shell, adb does that, as well as blazing fast file transfer (for the standards of MTP).
For sure, although I think it isn't as well suited to being a remote daemon. With SimpleSSHD, all concerns are compartmentalized into an app, you get rsync out of the box plus a nice minimalist UI for monitoring. Then adb can be left disabled, and its configuration untouched.
If your phone is rooted, you can use e.g. Linux Deploy to install a full Linux distribution. Then, you can set up regular ol' OpenSSH, mount /sys and /data under the Linux chroot, and rsync as usual.
I use this method to rsync to btrfs snapshots (+ raw copies of non-filesystem partitions) to make daily incremental backups of the entire phone. (Restoring said backups is a bit more involved, but I verified it's doable.)
I use this method to rsync to btrfs snapshots (+ raw copies of non-filesystem partitions) to make daily incremental backups of the entire phone. (Restoring said backups is a bit more involved, but I verified it's doable.)
I'd backup to a more reliable filesystem than btrfs. In my experience you will eventually randomly lose data with btrfs. I have lost all trust in it.
Backups are by definition redundant, however, btrfs is still the only Linux filesystem with its featureset. Let me know when ZFS on Linux supports shrinking or cloning file ranges.
https://news.ycombinator.com/item?id=16494370
https://news.ycombinator.com/item?id=16494370
This is an Android problem that is sold as a feature by Google... still a problem on my version of Android (in Android 5.0 and later, an app can request the permission for reading/writing to a folder on the SD card though: https://metactrl.com/docs/sdcard-on-lollipop/ )
I use the Syncopoli app which can do this on a scheduled basis. It uses Dropbear internally and is also on F-Droid. You do need a SSH server but you can limit the wireless networks it syncs on, so it needn't be public.
Great idea, I'd grown too reliant on Google Photos and always hated that. I should set this up.
Is there an equivalent for iOS?
Lol
Let’s keep in mind the user story: “Being able to wirelessly perform an incremental backup of all your photos and data is life-changing”
The LOL is telling your Mom about DropbearSSH when this is now how iCloud Photos and Files just works. The equivalent goal is baked in.
You can still use cables or local WiFi via iTunes, but now all media and files sync over-the-air as files, along with an incremental backup of all state.
For the first time in last fall’s iPhone hardware upgrade, I didn’t use a wired backup/restore and every app’s and settings worked, along with device config. I’ve had an iPad Pro unexpectedly need replacing, no wired backup/restore needed. All my stuff syncs across all devices including desktop, all ambiently available.
The life changing part is confidence it’s working to the point of not having to think about it any more.
// Note: Photos and media end up as originals on Mac, along with all files. Those all backup in turn to Backblaze, for loss scenarios not covered by rsync style replication.
The LOL is telling your Mom about DropbearSSH when this is now how iCloud Photos and Files just works. The equivalent goal is baked in.
You can still use cables or local WiFi via iTunes, but now all media and files sync over-the-air as files, along with an incremental backup of all state.
For the first time in last fall’s iPhone hardware upgrade, I didn’t use a wired backup/restore and every app’s and settings worked, along with device config. I’ve had an iPad Pro unexpectedly need replacing, no wired backup/restore needed. All my stuff syncs across all devices including desktop, all ambiently available.
The life changing part is confidence it’s working to the point of not having to think about it any more.
// Note: Photos and media end up as originals on Mac, along with all files. Those all backup in turn to Backblaze, for loss scenarios not covered by rsync style replication.
Everything in iCloud, including your encrypted messages, are easily accessible to Apple[0] and will be released without a fight, despite Apple's vaunted privacy stance. (Perhaps that social contract has some fine print if the CEO of your company looks at your files and decides you're guilty without wasting time with 'a jury of your peers' and all that nonsense.)
Android (with Google) offers the same functionality (AFAIK) as iCloud, but sometimes you just prefer that your private photos remain just that.
0. https://news.vice.com/en_us/article/xwm4ya/paul-manafort-may...
Android (with Google) offers the same functionality (AFAIK) as iCloud, but sometimes you just prefer that your private photos remain just that.
0. https://news.vice.com/en_us/article/xwm4ya/paul-manafort-may...
Any data you sync to a cloud provider is subject to subpoena by LEO.
tarsnap/cryptfs should really be SOP when uploading anything to cloud.
bjoli(1)
Despite how inappropriate this comment is its cynicism is appreciated. I like my iPhone but I miss Android for things like this.
That said, I think it might be possible but I think you might have to shim it and wouldn’t have direct access to the file system under the photos.
That said, I think it might be possible but I think you might have to shim it and wouldn’t have direct access to the file system under the photos.
Thank you for your thoughtful contribution.
Open Terminal managed to sandbox a busybox like suite (grep, curl, gzip…). And a scripting language to boot.
rsync limited to the app's directory + shared folders such Photos, iCloud drive, etc would be pretty useful, even without full file system access.
iOS's restrictions are loosening up, vide Files.app
Open Terminal managed to sandbox a busybox like suite (grep, curl, gzip…). And a scripting language to boot.
rsync limited to the app's directory + shared folders such Photos, iCloud drive, etc would be pretty useful, even without full file system access.
iOS's restrictions are loosening up, vide Files.app
As an iOS user this is an appropriate response.
iLol :)
For non-jailbroken devices that wouldn't be possible in the same way, but an app could certainly implement SSH with libraries (photos, contacts, etc) exposed as a filesystem and interpret a set of commands (like rsync).
It's somewhat flaky, but you can also mount your phone as a local FS over USB debugging, requires a wired connection though: https://github.com/spion/adbfs-rootless
It's possible on most devices to use adb over the network. It's a separate toggle in the de developer settings as it exposes the adb port to all network interfaces (think WiFi, LTE, Bluetooth, etc.)
Use `adb connect <ip>` to connect to your device over WiFi and you should be able to use this tool without having a wired connection to the phone.
What do you use to have rsync on your phone?
And did you have to root your phone to achieve any of this?
Also, is there a tool to use duckdns or similar to assign a hostname to your phone?
And did you have to root your phone to achieve any of this?
Also, is there a tool to use duckdns or similar to assign a hostname to your phone?
1) SimpleSSHD includes rsync.
2) No.
3) Haven't looked into dynamic DNS yet; only using the setup with local wifi currently.
2) No.
3) Haven't looked into dynamic DNS yet; only using the setup with local wifi currently.
I use acrosync, a rsync UI, pretty limited but works... I'm gonna try your sshd to see if it's better.
Love it, works like a charm.
Since the phone's IP address can be expected to change, you can't really use that to choose the right key to present, or to verify the host fingerprint right?. How do you work around this?
You can set a static IP in your wireless settings.
Or ‘better’ fix an IP to your device MAC in your dhcp settings.
Usually not needed, since your router will usually try to assign a fixed address for already known devices.
Not all routers support this. In fact at work we've got a router that seems to black-hole anything whose source or destination isn't in the DHCP table (TP-Link 480t+).
In the end I solved this by accessing this only while I'm tethered, that fixes the phone's IP address.
Too bad there doesn't seem to be an option to select keys according to host key instead of hostname or alias.
In the end I solved this by accessing this only while I'm tethered, that fixes the phone's IP address.
Too bad there doesn't seem to be an option to select keys according to host key instead of hostname or alias.
A word of caution: Many (most) IRC spambot detectors check if your connecting IP is also running a Dropbear SSHd service. This can cause you to be k-lined in some instances, and it's not immediately obvious to basically everyone why the anti-spambot bots are flagging your connection. Of course, this isn't Dropbear SSHd's fault. Just something you might want to keep in mind if you use both of these things.
It is because dropbear is very common in embedded systems. They are commonly riddled with vulnerabilities, so they are getting hacked almost as soon as they are publicly reachable. This is not because of dropbear, but because they are typically configured with weak credentials that are newer changed. I guess IRC servers see a lot of spam from such devices, so they just drop all systems which has dropbear.
It's probably also because of dropbear since embedded devices often run old versions and dropbear seemed to be vulnerable to severe vulnerabilities in the past:
https://www.cvedetails.com/vulnerability-list/vendor_id-1580...
https://www.cvedetails.com/vulnerability-list/vendor_id-1580...
Huh, what kind of dodgy IRC servers have you been on ;) ? I've never encountered that in years of IRCing from hosts running Dropbear, though I could see it happening.
Heh I should be more precise. During the summer storm season (for example the attacks last week across most of the popular networks), most networks deploy spambot countermeasures that they don't typically run on a normal day. But when they flip the switch, it tests new connections only. So for example I use ZNC and essentially never disconnect. But I disconnected to renew my LetsEncrypt certs during this time and then was k-lined on reconnection on a couple of networks.
If anyone is interested in other lightweight tools to complement a minimal embedded linux distro, check out Troglobit's GitHub repo: https://github.com/troglobit. He has a collection of tiny apps perfect for embedded systems, such as...
- mdnsd (not in Busybox),
- merecat httpd (much more full-featured than busybox httpd)
- inadyn dynamic DNS updater
- finit (IMO much nicer than busybox's runsv)
- watchdogd
- uftpd
- ntpd (with ipv6 support!)
This is great, thanks for sharing!
Very common in embedded devices. This link isn't working at the moment, so here's a link to the actual project: https://matt.ucc.asn.au/dropbear/dropbear.html
I followed that literarary-clock kindle tutorial at the weekend, and I think dropbear was the SSH client the networking hack used. Makes sense if it's designed to be low-resource.
Dropbear works well for preboot LUKS unlocking with remote servers.
Currently, all my remote servers of any import use LUKS to encrypt the PVs. My /boot is a tiny unencrypted filesystem containing just the kernel, and an initrd, which prompts for my decryption key before booting. (afaict, the standard setup)
For remote servers, I reboot them and then have to use a serial console to type in the LUKS password.
Are you saying that with this, I could put an ssh server in the initrd (and I guess I'd have to make sure network was up as well), that I could log in to to provide my LUKS password???? Because that would be ... beautiful.
For remote servers, I reboot them and then have to use a serial console to type in the LUKS password.
Are you saying that with this, I could put an ssh server in the initrd (and I guess I'd have to make sure network was up as well), that I could log in to to provide my LUKS password???? Because that would be ... beautiful.
For Ubuntu or Debian the dropbear-initramfs package should handle most of it, it looks like https://hamy.io/post/0005/remote-unlocking-of-luks-encrypted... is an alright run through.
Another approach is to use something like OpenWRT as a bootloader then pivot_root into the real distribution after unlocking it - not sure there are any good instructions online for that though. I'm using it on a Raspberry Pi colocated 14000km away for https://dropbear.nl, it works pretty well. Kexec is great for remote kernel upgrades too.
Another approach is to use something like OpenWRT as a bootloader then pivot_root into the real distribution after unlocking it - not sure there are any good instructions online for that though. I'm using it on a Raspberry Pi colocated 14000km away for https://dropbear.nl, it works pretty well. Kexec is great for remote kernel upgrades too.
You are rocking my world. :D
When I first started switching my VPSs to having full disk encryption, I think it was around lenny though it might have been squeeze. Anyway, me and another peer thought it would be good practice to, while we figured we'd never cover every possible surface, find a standard deployment for debian VMs where even though we have no physical access to the hosts, wherever possible minimized the ability of an employee at a hosting company accessing our precious, precious bits.
The memory hadn't come back when I wrote my first comment, but one of the ideas we had at the time was shoving sshd inside the initrd! But we concluded it would be hard -- involving not only making a static build of sshd (which I did some eons ago when I had foolish opinions concerning /bin /usr/bin) but also probably trimming code away from it or adding executable compression, and modifying the initrd creation scripts....either way -- too much complexity.
So I went the route previously described. Now I learn that not only is there an ssh implementation which i can statically link into a tiny binary (which helps some other projects...), but someone went threw the trouble of making a modified initrd package with it!
Fantastic. Look for an email from me soon offering help on a specific project I noticed on your github...
I'm well aware of building my own scripts that use chroot/pivot_root tricks -- I personally like using them for making small boxes that run everything from ram and keep no persistent state.
But just out of random curiosity, what's the advantage of using OpenWRT?
When I first started switching my VPSs to having full disk encryption, I think it was around lenny though it might have been squeeze. Anyway, me and another peer thought it would be good practice to, while we figured we'd never cover every possible surface, find a standard deployment for debian VMs where even though we have no physical access to the hosts, wherever possible minimized the ability of an employee at a hosting company accessing our precious, precious bits.
The memory hadn't come back when I wrote my first comment, but one of the ideas we had at the time was shoving sshd inside the initrd! But we concluded it would be hard -- involving not only making a static build of sshd (which I did some eons ago when I had foolish opinions concerning /bin /usr/bin) but also probably trimming code away from it or adding executable compression, and modifying the initrd creation scripts....either way -- too much complexity.
So I went the route previously described. Now I learn that not only is there an ssh implementation which i can statically link into a tiny binary (which helps some other projects...), but someone went threw the trouble of making a modified initrd package with it!
Fantastic. Look for an email from me soon offering help on a specific project I noticed on your github...
I'm well aware of building my own scripts that use chroot/pivot_root tricks -- I personally like using them for making small boxes that run everything from ram and keep no persistent state.
But just out of random curiosity, what's the advantage of using OpenWRT?
> But just out of random curiosity, what's the advantage of using OpenWRT?
I can't remember the exact reason, maybe it was because then the "bootloader" is completely decoupled from the main OS which makes upgrading kernels etc easier. It was about 5 years ago I set it up.
I should add, all the Debian initramfs work has been contributed by various people over the years - full credit to people such as the Debian maintainers, currently Guilhem Moulin.
I can't remember the exact reason, maybe it was because then the "bootloader" is completely decoupled from the main OS which makes upgrading kernels etc easier. It was about 5 years ago I set it up.
I should add, all the Debian initramfs work has been contributed by various people over the years - full credit to people such as the Debian maintainers, currently Guilhem Moulin.
> should add, all the Debian initramfs work has been contributed by various people over the years
Oh certainly, I would have assumed it was.
All I know for sure is that many moons ago I would have loved this feature, could have probably done it myself at great great great effort but didn't want to, and now, hey, here it is :) progress!!
As for decoupling and lowering complexity... <tiny voice> occasionally i miss LILO... </>
I've been paging through the code (dropbear) so far, very clear. Glad that there's TCP forwarding, as it opens the door to another possible solution in search of a problem. Namely, with USB over IP tunneled through dropbear, a user would have the ability to plug in a yubikey or some sort of challenge response device. ; )
Also, I sent you a note.
Oh certainly, I would have assumed it was.
All I know for sure is that many moons ago I would have loved this feature, could have probably done it myself at great great great effort but didn't want to, and now, hey, here it is :) progress!!
As for decoupling and lowering complexity... <tiny voice> occasionally i miss LILO... </>
I've been paging through the code (dropbear) so far, very clear. Glad that there's TCP forwarding, as it opens the door to another possible solution in search of a problem. Namely, with USB over IP tunneled through dropbear, a user would have the ability to plug in a yubikey or some sort of challenge response device. ; )
Also, I sent you a note.
I've set my Ubuntu server up with dropbear-initramfs almost 2 years ago, but a few months ago, it stopped working. Since 18.04 was imminent, I decided to wait and not fix it, and hope my new UPS keeps it running.
Yes you can and start whatever program you want, take i look at better-initramfs (https://github.com/slashbeast/better-initramfs), although it is more for gentoo/funtoo.
Basicaly when linux boot from initrd it starts "/init" executable and chroots to your system (ok, it is using pivot_root and it is slightly more complex), but idea it is same as manually mounting filesystems and doing chroot then starting executable /bin/init
Basicaly when linux boot from initrd it starts "/init" executable and chroots to your system (ok, it is using pivot_root and it is slightly more complex), but idea it is same as manually mounting filesystems and doing chroot then starting executable /bin/init
There's also an example script on the Gentoo wiki that might serve as a good starting point:
https://wiki.gentoo.org/wiki/Custom_Initramfs/Examples#Simpl...
Yes, basically.
(Shameless plug:)
For automatic unlocking at unattended reboots of LUKS-locked remote servers, see Mandos: https://www.recompile.se/mandos
For automatic unlocking at unattended reboots of LUKS-locked remote servers, see Mandos: https://www.recompile.se/mandos
Yes, this is devilish clever stuff :)
This is how I've used it as well. (Initram luks shim, I call it)
How's that work? Are you unlocking, say, a rootfs on boot or something entirely different? I'm curious about the use case and the method.
Huh, this sounds too good to be true.
Remote FDE? Yes please!
Remote FDE? Yes please!
I believe Dropbear still has limited to no SFTP support but otherwise I've been very happy with it.
Dropbear is the default SSH server for DietPi[0], a lightweight image for Raspberry Pi and other (mainly single board) computers.
[0] https://dietpi.com/
Dropbear is the default SSH server for DietPi[0], a lightweight image for Raspberry Pi and other (mainly single board) computers.
[0] https://dietpi.com/
Check out the security track record before using this. There have been occasional RCE's.
Often used with ARM, why is it never used by default on X86/X64 distros? I would think that the "lightweight" alternative would be lean and mean, kind of like Nginx vs Apache.
Nginx won because it was faster, simpler and more easily extended, not because it was "lightweight" per se.
In comparison, dropbear doesn't really do anything that ssh doesn't, and lags in a bunch of esoteric features that "most" people don't use but that inevitably some people do. Who wants to use a distro where one's preferred ssh-agent feature or X11 forwarding inexplicably doesn't work?
Dropbear is small and builds cleanly everywhere, so it's what you pick if you're size constrained or just need "an ssh" for your embedded environment and don't want to bother integrating something larger. No one specifically wants it at the command line on their "Linux" system.
In comparison, dropbear doesn't really do anything that ssh doesn't, and lags in a bunch of esoteric features that "most" people don't use but that inevitably some people do. Who wants to use a distro where one's preferred ssh-agent feature or X11 forwarding inexplicably doesn't work?
Dropbear is small and builds cleanly everywhere, so it's what you pick if you're size constrained or just need "an ssh" for your embedded environment and don't want to bother integrating something larger. No one specifically wants it at the command line on their "Linux" system.
Dropbear author here.
It used to have one unique feature, but OpenSSH has copied it now[0] :)
[0] https://manpages.debian.org/stretch/openssh-client/ssh.1.en....
It used to have one unique feature, but OpenSSH has copied it now[0] :)
dbclient host1,host2,user@host3
[0] https://manpages.debian.org/stretch/openssh-client/ssh.1.en....
Just want to say thanks for your work!
When I was elbow-deep in CLFS[1], I never ran into trouble getting Dropbear to compile and work with my fledgling Linux Distro, and upon reflection that is quite an accomplishment and something I'm thankful for.
Dropbear "just worked", and it worked well. It was the first "portal" into my Distro, and I can still remember SSH'ing into my system for the first time and being completely amazed it worked at all, let alone returned a shell prompt!
Open Source projects don't get enough appreciation, and our Open Source hero's, such as yourself, get even less. Thank you for Dropbear!
[1] http://trac.clfs.org/
When I was elbow-deep in CLFS[1], I never ran into trouble getting Dropbear to compile and work with my fledgling Linux Distro, and upon reflection that is quite an accomplishment and something I'm thankful for.
Dropbear "just worked", and it worked well. It was the first "portal" into my Distro, and I can still remember SSH'ing into my system for the first time and being completely amazed it worked at all, let alone returned a shell prompt!
Open Source projects don't get enough appreciation, and our Open Source hero's, such as yourself, get even less. Thank you for Dropbear!
[1] http://trac.clfs.org/
So... are you an Australian? Only Australians know how deadly dropbears are.
Hi,
First of all, thank you for creating Dropbear SSH. I would love to try it. I am currently using OpenSSH with PAM (Google Authenticator) and Ed25519. Does Dropbear support both PAM and Ed25519?
First of all, thank you for creating Dropbear SSH. I would love to try it. I am currently using OpenSSH with PAM (Google Authenticator) and Ed25519. Does Dropbear support both PAM and Ed25519?
PAM support is fairly rudimentary and only supports username/password. ed25519 isn't supported - a few people have wanted it I might add it at some point. I haven't seen a real reason to go with that over ecdsa.
The reason to use Ed25519 over ECDSA is that ECDSA can't be used unless you have a good CPRNG. Just ask Sony what happens if you reuse a nonce with (EC-)DSA.
True, that could be a good reason.
Forgot to mention and can't edit in the previous comment, there's a PoC ed25519 implementation I need to look at merging.
Hey! I love Dropbear for embedded! Sending you a long-distance highfive!
It doesn't do privilege separation and it's had a few security issues (like CVE-2016-7409). I also think that some of the more exotic features are missing.
https://matt.ucc.asn.au/dropbear/CHANGES
https://matt.ucc.asn.au/dropbear/CHANGES
Not "default" per se, but Alpine Linux gives you the pick of openssh or dropbear when you install the system, and doesn't appear to have a preference which you use. If course, Alpine is borderline embedded, so not exactly a counterpoint.
I believe Alpine Linux offers it in the installer.
Does this have anything to do with http://bearssl.org/ ?
No, Bear SSL is recent, DropBear has existed for a very long time.
I needed a ssh server with some tweaks a few years ago. I must say that the dropbear code was very neatly written, easy to read and easy to understand. It made me to choose dropbear instead of openssh for my tweaks.
I would have used dropbear on my main machine as well, but it doesn't seem to support ~/.ssh/config
I would have used dropbear on my main machine as well, but it doesn't seem to support ~/.ssh/config
Archived: http://archive.is/9lu2S
I recall I've had trouble finding good documentation on the equivalent of OpenSSH features in Dropbear. Stuff like restricting the client IP or disabling port forwarding... lesser-used features like these. It's been a while though.
The general pattern used by most of these "lightweight" implementations of system software is granular compile-time options for every additional bit of functionality.
https://busybox.net is a good example of this.
https://busybox.net is a good example of this.
Dropbear SSH is also shipped into OpenWrt. It works great, including ssh keys, useful for ssh/scp automation.
Used Dropbear on many occasion on both iOS and Android, very quality this one
"resource limit reached"
When publishing something on hn kills it.
[deleted]
Dropbear has been created in 2002.
From the project ChangeLog:
```
[..]
0.28 - Sun Apr 6 2003
- Initial public release
Development was started in October 2002
```
..why is it surfacing now on HN? O_o
From the project ChangeLog:
```
[..]
0.28 - Sun Apr 6 2003
- Initial public release
Development was started in October 2002
```
..why is it surfacing now on HN? O_o
I mean it's good to remind people of older and less-known projects, but Dropbear is quite common for embedded Linux applications.
OpenWRT uses it for example.
OpenWRT uses it for example.
> Resource Limit Is Reached :\
Thank you to all these projects for delivering me from the clutches of MTP, I am indebted.