Thanks - applied with minor changes to the message wording, and to
store the keys under HostKeys/ rather than in the root of the registry
(where, for example, using a hostname that matched an existing setting
name would cause that setting to be overwritten).
On Thu, Jul 11, 2013 at 1:24 PM, Akshay Joshi
<akshay.joshi@enterprisedb.com> wrote:
> Hi Dave
>
> As per your suggestion I have implemented the "SSH Host key verification"
> logic in SSH Tunneling code. Below is the brief description about feature:
>
> When connecting to an SSH server for the first time, the user should be
> presented with a prompt showing the host key, and given the option to accept
> or reject it. If accepted, the key should be cached and the connection
> should proceed. If rejected, the connection should be immediately aborted.
>
> When connecting on subsequent occasions, pgadmin should check the host key
> against the cached copy. If they match, the connection should proceed as
> normal. If they do not match, the user should be presented with a prominent
> warning showing them both the expected and received host keys, and giving
> them the option to reject (the default) or accept the new key. If reject is
> chosen, the connection should be immediately aborted and the cached key
> should not be updated. If accepted, the connection should proceed and the
> cached key should be updated with the new one.
>
> Attached is the patch file, can you please review it. If it looks good to
> you then can you please commit it.
>
> --
> Akshay Joshi
> Senior Software Engineer
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
> Phone: +91 20-3058-9522
> Mobile: +91 976-788-8246
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
