Hi.

With respect to the creation of SSH server keys in postinst, may I suggest the
following:
- not create ssh1 keys at all... actually I've never seen them auto-created,
  but code seems to be there
  This is mainly for security reasons... if someone really want's ssh1, he shoul
  manually create the keys.

- specify bit sizes
  Also for security reasons, use the highest bit sizes possible for the respective
  algorithm,... it should have basically no performance impact, and if someone
  really thinks he wants a weaker key,.. he still can manually create it
  That is
  rsa2: -b 4096
  dsa: -b 1024
  ecdsa: -b 521 (no typo)

- use the FQDN as comment
  I always found it handy to have the full hostname on the server keys as comment, i.e.
  -C "$(hostname -f)"
  without username, as e.g. root@$(hostname -f), would be the personal key of the user
  root.


Cheers,
Chris.

Control: retitle -1 openssh-server: fine-tune server key creation

Done in 1:7.1p2-2 (see #811265).

ssh-keygen's defaults are fine, especially nowadays that it defaults to
3072 bits for RSA keys.  For the same sorts of reasons that I laid out
in https://bugs.debian.org/1094246#10, I don't think it's necessary to
override them here.

This seems probably reasonable.  The only thing I was wondering was
whether there were any (minor) privacy implications to recording that
information?  I guess not but I'm not certain.

Well, I guess there *might* be, but only if someone hands out the
public keys somehow (and than he should know what he's doing?!).

Or is the comment ever transmitted as part of the protocol? Maybe as
part of the hostkeys@openssh.com" protocol extension?

But even then, to use that an "attacker" would likely already know the
host anyway.


In general I think Debian should also consider privacy (and e.g.
disable things like programs automatically using gravatar or so, per
default).... but this here would seem very minor to me.
But I'd also be fine if you'd object.


Maybe one could make the host keys' comments a debconf question of very
low priority, which defaults to the user@fqdn, but gives a warning that
this might leak the name?



Cheers,
Chris.