I'm working at the UofA, and we use openssh all over the place (actually
it's the only remote connection tool we use within our groups domain of
influence. Save pop I suppose...). Anyways, for various reasons we have
UseDNS set to ``yes''. This however is about 50% of our connection
problems
that our users have. Cable and even the DSL ISP's around here suck when it
comes to managing and actually keeping their DNS up-to-date.
Now, if the ssh client had a cookie of sorts (public key?) that it always
sent (generated on first startup) when it connected to the server, I could
envision a scenario where you would cache the tuple <username, cookie, IP,
DNS>. The <username, cookie> portion would be a "hard key",
where both
would need to match in the database. The <IP, DNS> portion should be
configurable, in our case we would want at least one to match, and upon
a mismatch in either the DNS or IP (DHCP client, or DNS fuckup), to add
that entry into the database as well. Each entry in the database would
have a lifetime, and this lifetime would be updated each time you hit the
entry in the database.
If your tuple does not exist in the database, I could see sshd spitting
back "Sorry, you're coming from a host/etc that you don't usually
come
from, please connect to https://foo.org/blahonga to authenticate further."
and then closes the connection. Then on that web-site (or whatever the
admin makes it spit back), you have a means to administer the cache entries.
"So, you're coming in from a web cafe? Ok, set timeout to 1
day.", etc...
Is this sort of thing doable? Is it desirable? Was the above clear?
--Toby.
