Comment 10 for bug 524226

Colin-

Thanks for the comment. I agree that such a script should undergo a *thorough* review before being accepted into our openssh-server package.

I also see your point, that ssh-copy-id is doing it's work over ssh itself.

In the default configuration, ssh-import-id works against Launchpad.net, over SSL, with a valid certificate. SSL should prevent both eavesdropping and tampering, end-to-end, between the client and the server, and the server should be authenticated to the client (assuming a valid certificate and a 3rd party certificate authority). An invalid certificate will fail the wget, and prevent a key from being written. This would mean that we'd need to keep our certificate current for Launchpad.net, which I'd hope is a safe assumption. And anyone modifying their URL parameter would need to expect the same from their keyserver.

The SSL assumption is a safe one (in my opinion), as it is the same assumption we make as we conduct all sorts of private, critical business over https everyday.

Also, this script runs as a non-privileged user, modifying their own authorized_keys file, obviously something they could do on their own. I don't think it does anything special, tricky, or exceptional in this way.

Finally, I'd argue that the utility is non-intrusive. It doesn't change the behavior of anything else in SSH, or interrupt any other operations.

I'm certainly willing to work the FFe end of this and try to get it accepted ASAP (Alpha3?), as it's something I really believe can make our Ubuntu Server EC2/UEC images stand out among available images. If that means this script should live in one of our cloud-* packages for Lucid, so be it.

I just thought that openssh-server would be the appropriate home for such a utility (eventually), and I thought I'd start a conversation here.

Thanks,
:-Dustin