ie a name starting with a letter. This is to prevent problems with older software (eg MTA's). It's not a hard requirement.
There's also some "prior art" e.g. 3com.com.
Re:SRP is the secure one - cryptographic reasons
on
SSH v. SRP
·
· Score: 1
This is why SSH flashes up big warnings saying "THIS SERVER IS UNAUTHENTICATED: REALLY PROCEED?" when you log on to a server the client hasn't seen before. To which everyone just presses "yes", defeating the so-called security
That behaviour is optional. You can enforce good host key hygiene by adding "StrictHostKeyChecking yes" to/etc/ssh_config.
StrictHostKeyChecking
If this flag is set to "yes", ssh ssh will never automatically add host keys to the $HOME/.ssh/known_hosts file, and refuses to connect hosts whose host key has changed. This provides maximum protection against trojan horse attacks. However, it can be somewhat annoying if you don't have good/etc/ssh/ssh_known_hosts files installed and frequently connect new hosts. Basically this option force the user to manually add any new hosts. Normally this option is set to "ask", and new hosts will automatically be added to the known host files after you have confirmed you really want to do that. If this is set to "no" then new host will automatically be added to the known host files. The host keys of known hosts will be verified automatically in either case.
For those that haven't seen it, distributed.net's crypto-cracking client has multiple "cores", from which it selects the fastest one for a given processor.
I ran a comparison between three machines (MII@233MHz, K6-3@400MHz and Celeron@300MHz). Remombering that they're all x86 architecture machines, there's some huge variations:
The point of this? Imagine what your run-time optimising compiler could do when it knows the exact charateristics of the chip it's running on, as opposed to those of the chips it might run on. I know this is an extreme case, but there can be significant differences.
Slashdot Mirror
Chuckle.
You'll probably find your browser ate a couple of angle brackets in the perl statement. It should read:
perl -e 'while(<>){print pack("H32",$_)}'
RFC1034 suggests labels of the form:
::= < letter> [ [ < ldh-str> ] < let-dig> ]
< label>
ie a name starting with a letter. This is to prevent problems with older software (eg MTA's). It's not a hard requirement.
There's also some "prior art" e.g. 3com.com.
That behaviour is optional. You can enforce good host key hygiene by adding "StrictHostKeyChecking yes" to /etc/ssh_config.
StrictHostKeyChecking
If this flag is set to "yes", ssh ssh will never automatically add host keys to the $HOME/.ssh/known_hosts file, and refuses to connect hosts whose host key has changed. This provides maximum protection against trojan horse attacks. However, it can be somewhat annoying if you don't have good /etc/ssh/ssh_known_hosts files installed and frequently connect new hosts. Basically this option force the user to manually add any new hosts. Normally this option is set to "ask", and new hosts will automatically be added to the known host files after you have confirmed you really want to do that. If this is set to "no" then new host will automatically be added to the known host files. The host keys of known hosts will be verified automatically in either case.
The argument must be "yes", "no" or "ask".
For those that haven't seen it, distributed.net's crypto-cracking client has multiple "cores", from which it selects the fastest one for a given processor.
I ran a comparison between three machines (MII@233MHz, K6-3@400MHz and Celeron@300MHz). Remombering that they're all x86 architecture machines, there's some huge variations:
core MII K63 Celeron
#0 175 569 354
#1 426 648 70
#2 359 617 841
#3 520 547 694
#4 374 602 693
#5 362 704 712
Notice that the largest is a ten-fold difference!
The point of this? Imagine what your run-time optimising compiler could do when it knows the exact charateristics of the chip it's running on, as opposed to those of the chips it might run on. I know this is an extreme case, but there can be significant differences.