I would like ssh to provide host verification using a key in the destination user account (as an alternative to using a key installed by the system administrator). It is not unusual to connect to systems where the user has an account but does not control the system (e.g., accounts provided by schools, employers, and other institutions or an account on a virtual server at an ISP), and the institution may occasionally migrate the accounts to new hardware while neglecting to migrate the host keys. This feature would also be useful on development systems where the user reinstalls the OS frequently (but retains the user data, possibly on a storage volume separate from the OS). If the destination account files contained a key (with permissions granting access to sshd but denying access to other users), sshd could access the key and use it to authenticate to the client ssh.
This isn't possible without breaking the guarantees that host key checking is supposed to provide. For the behaviour that you want, ssh would have to ignore a host key verification failure at connection time, proceed with authentication and fetch (presumably using sftp) the host key from the target system. This is a substantial amount of work but, worse, it would require ssh to complete authentication to a system that it does not trust. Completing authentication means sending user credentials to the remote server. This would allow phishing or connection spoofing by hostile servers.
The second paragraph in the preceding comment contemplates an implementation in which the ssh client does the work of retrieving the key and verifying it. That is not necessary. When initially contacting the server, the client would supply the name of a user on the server system. The ssh server would read a key from that user’s files and use it in the normal authentication process instead of the usual system host key.
closing resolved bugs as of 8.6p1 release