All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
SECURITY NOTICE : Update Dropbear in Deb6 Stable from Deb6 Testing
Dropbear home page
http://matt.ucc.asn.au/dropbear/dropbear.html
"Security update 2012.55 — releases from 0.52 to 2011.54 are potentially vulnerable to code execution as root by an authenticated user if a command="..." option is used in authorized_keys. Release 2012.55 fixes the problem."
Debian stable (squeeze) is running Dropbear sshd v0.52.
Debian testing (wheezy) includes Dropbear sshd v2012.55
Luckily, you can install Dropbear sshd v2012.55 from the testing repo on your stable system without breaking anything.
Short version
1) Add testing to your /etc/apt/sources.list
2) Create an /etc/apt/preferences file that tells apt the priority order for version control between stable, testing, unsable.
3) apt-get update
4) apt-get install dropbear/testing
Long version
Read and learn
http://jaqque.sbih.org/kplug/apt-pinning.html
Have fun and stay safe kids!
Credits go to John H. Robinson, IV jaqque@debian.org for the doc on apt pinning.
Comments
More good reading to compare dropbear package dependencies between stable and testing ...
http://packages.debian.org/squeeze/dropbear
http://packages.debian.org/wheezy/dropbear
Thanks rajprakash.
Maybe compiling from source can be better :P
thanks for the info! updating right now...
Done
Thank you
Could someone explain that, as I don't understand it please?
If you want to use your private key to connect to an SSH server (usually a better option than a password), you upload your public key to a file on the remote server; it usually goes in ~/.ssh/authorized_keys, though it can be named something else if you customize your settings in
/etc/ssh/sshd_config
. Each public key you want to accept is put on its own line, and at the beginning of the line you can specify options that apply to that specific key.The
command="[command]"
option can be used to force a specific command to be run when a user connects; they can't do anything else (e.g., can't get a general shell, can't run any other command they specify). It can actually be kind of tricky to really lock this down (see this O'Reilly chapter for examples of how to use it, or this cached version since O'Reilly is under maintenance right now), but it can be a useful option for limiting access and increasing security. Apparently there was a bug in dropbear related to this option.For more information, you can search for
forced command ssh
and there are some good examples/information out there.Using "command=" in authorized_keys is a custom configuration, which only you (or a user on your system) would have put in place. Look for it:
And for the root user:
If you don't find any instances, don't get your knickers in a knot. There will probably be an updated dropbear package in a few days.
The fix for this is now in squeeze (stable).
Seeing as packages in Debian Testing receive no security updates whatsoever (aside from whatever happens to trickle down from Debian Experimental), you should never be upgrading to anything in Debian Testing from Stable for a security fix.
Considering just how long it took from the backported fix being prepared by the package maintainer on 28 Feb to the i386/amd64 packages being uploaded to squeeze (some time over the past few days) I think, in this particular instance, moving to a newer version wouldn't have been an unreasonable decision if you were affected by the bug.
Dropbear is a relatively obscure program and so it misses out on some of the attention that more popular stuff gets. One thing I've learned now is that Debian security support is not all that it's cracked up to be.
Agree. That's exactly why I upgraded from testing.