On 26/11/2012, at 9:01 PM, Makarius <[email protected]> wrote: > On Sun, 25 Nov 2012, Gerwin Klein wrote: > >> On 20/11/2012, at 11:23 PM, Makarius <[email protected]> wrote: >> >>> There is this recurrent game to have the isatest user do many manual ssh >>> logins to update known_hosts. Getting tired of it, I just did some reading >>> of man ssh_config and some googling. This resulted the following >>> ~isatest/.ssh/config: >>> >>> Host * >>> #see >>> http://linuxcommando.blogspot.fr/2008/10/how-to-disable-ssh-host-key-checking.html >>> StrictHostKeyChecking no >>> UserKnownHostsFile=/dev/null >>> >>> Maybe it helps in other situations, too. Or maybe there is an ssh expert >>> saying that this is really really bad. >> >> ssh does check these keys for a reason, it is now easy for another host to >> pretend to be one of the servers isatest wants to access. On the other hand, >> it's unclear what an attacker would gain from having isatest run a large >> isabelle session. There are easier ways to do that ;-) > > Do these attacks also work from the free net outside TUM?
Unclear to me. You would probably have to spoof DNS on a fairly far-reaching level to exploit this from outside TUM. My guess would be that this is a lot harder than actually getting to the server itself. But I'm not really an ssh expert. > The reasoning (or rather hope) behind the above was that for doing real > non-sense you would have to be on the local network at TUM. So it is > basically a switch back towards the old-fashioned ways of rsh. I'm fine with that part. I mainly don't want to get the warning emails for each session. Maybe we should just leave off the line with /dev/null. > BTW, the local network is totally insecure if accessed from inside. There are > many ways to do non-sense, but we better don't explain that here. Better not ;-) Cheers, Gerwin ________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. _______________________________________________ isabelle-dev mailing list [email protected] https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
