[clug] ~/.ssh/authorized_keys and dynDNS

[Michael Cohen]

On Tue, Jul 24, 2007 at 10:20:15PM +1000, Andrew Janke wrote:
> So this all works nicely, but I am paranoid so want to add something like 
> this:
> 
> command="~/bin/vrsync.sh",from="xxxxx.selfip.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding
> ssh-rsa AAAAB3NzaC....
> 
> Note the added from="" thingo.  Now this fails as the hostname does
> not resolve correctly.. I get errors in /var/log/auth.log as such:
> 
> Jul 24 22:14:47 xxxxx sshd[6174]: Authentication tried for xxxx with
> correct key but not from a permitted host
> (host=WW-XX-YY-ZZ.dyn.iinet.net.au, ip=WW.XX.YY.ZZ).

It looks like sshd is trying to do a reverse lookup on your IP. Since
reverse DNS records (ptrs) are managed by your ISP you have no control
over them.

> Is there some way to turn this of in authorized_keys or should I just
> write some other script that updates authorized_keys with the correct
> IP from time to time? (which incidentally is how I currently update

That sounds rather flakey and error prone - you could get locked out. I
personally dont think it makes any sense to restrict by IP address if
you have key only auth - especially not in authorized_keys (its too late
in the authentication sequence).

Typically an SSH request goes through the following steps:

1) TCP connection
2) exchanging keys/protocol negotiations
3) pam authentications (/etc/security/access.conf)
4) shell spawned (.bashrc)

If you are worried about a vulnerability in one of these steps you want
to restrict access to each of those steps, reducing your exposure.

So for example, iptable rules block access at the tcp level - so the bad
guys dont even get a change to talk to the ssh daemon at all.

authorized_keys blocks access at the protocol neg level - so a vuln in
the tcp connection code will still cause compromise because that happens
before authorized_keys is enforced.

pam rules restrict logins at level 3 - so vulns in either tcp connection
or protocol negtiation steps will still get you....

etc, etc - the later you put access controls in the process, the more
exposure you have. I guess the point is that if you want to restrict by
IP address, you should be putting iptable rules, not in authorized_keys.
The reasoning is that the key and ip restriction happen in roughly the
same place in the code so it doesnt actually give you anything more to
restrict by IP at the point, than just key authentication.

I personally use port knocking with knockd - thats very effective and
works very well. It blocks all ips that do not know the knocking
sequence which removes all the script kiddies out there (makes logs much
cleaner). If someone watches the sequence they are able to open the
port, but then you have the usuall ssh key negotiation so thats about
where you were without using knockd.

Michael.