I have had one machine suffer from this problem.
error: symbol not found: 'grub_divmod64_full' Entering rescue mode... grub rescue>
See Bug#630226#20 for a comment about it.
If you forget to update grub before the Wheezy upgrade then you will need to boot rescue media and save yourself afterward. Boot the debian-installer in rescue mode and then run these commands.
mount -a grub-install /dev/sda grub-install /dev/sdb
So this must be a good thing! Just don't freak out if you find your $HOME/.ssh/known_hosts file logging ecdsa-sha2-nistp256 lines instead of the previous ssh-rsa lines.
I read some fud concerning putty.exe. I tested putty.exe. Debian configures all three types of keys including ecdsa, dsa, and rsa. Putty negotiates and uses "rsa2". Works for me.
The Debian package changelog says:
* Generate ECDSA host keys on fresh installations. Upgraders who wish to
add such host keys should manually add
HostKey /etc/ssh/ssh_host_ecdsa_key
to /etc/ssh/sshd_config and run
ssh-keygen -q -f /etc/ssh/ssh_host_ecdsa_key -N "" -t ecdsa
In Wheezy 7 logcheck now reports "preauth" messages. Here are some examples.
Dec 7 15:49:42 havoc sshd[7575]: Received disconnect from 114.80.246.178: 11: Normal Shutdown, Thank you for playing [preauth] Dec 10 12:05:45 havoc sshd[6580]: Received disconnect from 134.147.203.117: 11: Bye [preauth] Dec 24 11:33:05 havoc sshd[410]: Received disconnect from 183.136.213.228: 11: Normal [preauth] Jan 6 17:23:01 havoc sshd[7799]: Received disconnect from 93.115.240.26: 14: Unable to connect using the available authentication methods [preauth] Jan 27 18:57:23 havoc sshd[12969]: Received disconnect from 209.167.16.251: 11: [preauth] Jan 29 05:31:38 havoc sshd[30706]: Received disconnect from 130.207.203.56: 11: These aren't the droids we're looking for. [preauth]
These now appear in Wheezy 7 and therefore logcheck now reports them. These are from attacks poking at the system using the C program examples provided with ssh for connecting to an sshd by program. The string that is logged is any string the attacker chooses. The top four are the most common because they appear in the provided examples. The rest are typical modifications from attackers. Many other strings are seen depending upon the attacker because the string logged may be any string the attacker chooses. I find it somewhat dangerous that they can write anything to the log file. It makes it more difficult to ignore. The non-limited size makes this a possible denial of service attack vector.
This logging has been in the sshd code for a long time. However it wasn't being logged since ssh started using "privilege separation". It previously failed to log "preauth" messages from the privilege separation user. Damien Miller responded to my information request with this answer .
The only thing to have changed semi-recently is that we improved logging of preauthentication messages in privsep mode in the 5.9 release to no longer need a /dev/log inside the privsep chroot. If your old OpenSSH version was <5.9 and the /var/empty chroot didn't have a /dev/log in it then you may have been missing these messages.
And that is exactly the case we had in Squeeze where /var/run/sshd is empty and did not have a /dev/log and therefore preauth messages from the privsep user were not logged. But with sshd post openssh version 6.x now these messages are logged.
Here is a logcheck pattern to avoid noise from the common set of messages that I am seeing from attackers.
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd\[[0-9]+]: Received disconnect from [^ ]+: [[:digit:]]+: (|Bye|Normal|Normal Shutdown, Thank you for playing|Unable to connect using the available authentication methods) \[preauth\]$
Or you could choose to ignore any string by using a ".{0,255}" pattern. To limit memory use it is always a good idea to avoid the ".*" pattern and use a length limited pattern. That length limit is simply to ignore most typical patterns. The actual limit is syslogd dependent and usually much larger. The default rsyslogd size is 2k in the $MaxMessageSize configuration parameter.
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd\[[0-9]+]: Received disconnect from [^ ]+: [[:digit:]]+: .{0,255} \[preauth\]$
Between util-linux 2.17.2-9 and 2.20.1-4 getty has changed and it now clears the screen. This seems like a good thing on the surface until you find out that it destroys the boot time messages including any errors that are on the screen at the time. To prevent this a new option --noclear has appeared.
1:2345:respawn:/sbin/getty --noclear 38400 tty1
There has been a change to the way dynamic shared objects link. Previously they were automatically daisy chained. If a lib referenced another lib them you could reference only the first and the second would pull in all of the other dependencies. Now all libs need to be explicitly linked into your executable. I think. The changes are a little confusing to me but I think that is the change. And if so then I think it is a good change. It will help prevent creeping featurism where dependencies creep in outside the control of applications. See http://wiki.debian.org/ToolChain/DSOLinking.
After complaints in Bug#605130 that found during testing package purges that sudo didn't remove /etc/suders (who ever purges sudo in a real system?) the file was changed. Upgrades mean this file is thrashed. But along with this comes /etc/sudoers.d/ which is where local content can be placed so as to avoid future upgrade thrash.
/etc/sudoers should now contain a secure_path statement due to changes in the compiled in default now requiring it.
So on the one hand you can now move your entire configuration file into /etc/sudoers.d/local-sudoers and avoid thrashes from future package upgrades. (Were you ever thrashed by past upgrades? Yes, once when the "env_keep += HOME" became required.) But then you lose the ability to easily edit the file with visudo. That is annoying for random systems not using an infrastructure for system configuration. So I will probably continue to use /etc/sudoers on most systems, push through this thrash, and just keep hitting the thrash in the future.
In Wheezy the bootlogd is broken out into a separate package. If you want bootlogs then you need to install the new package.
apt-get install bootlogd