SSH utilizes several tricks to make sure it knows who you are. One of those is a combination of checks that ensure you are you by exchanging data that must be private to the user on each end.
When both hosts know each other by their respective canonical names, and these names are also listed in each others' .[rs]hosts files, and all the permissions are correct, you can SSH from one host to another without a password.
When both hosts know each other by their respective canonical names, and these names are also listed in each others' .[rs]hosts files, and all the permissions are correct, you can SSH from one host to another without a password.When both hosts know each other by their respective canonical names, and these names are also listed in each others' .[rs]hosts files, and all the permissions are correct, you can SSH from one host to another without a password.Every hose must have a public host key, which is a (usually) 1024 bit identifier. Every user is assumed to also have one. Each account for a given user should have a different key, as there is no advantage to sharing one, as it is paired with the hostname during checks.
When both hosts know each other by their respective canonical names, and these names are also listed in each others' .[rs]hosts files, and all the permissions are correct, you can SSH from one host to another without a password.
When both hosts know each other by their respective canonical names, and these names are also listed in each others' .[rs]hosts files, and all the permissions are correct, you can SSH from one host to another without a password.When both hosts know each other by their respective canonical names, and these names are also listed in each others' .[rs]hosts files, and all the permissions are correct, you can SSH from one host to another without a password. When you attempt to form an SSH connection, these public keys are traded, along with the canonical hostname of each end. If your end doesn't know the remote end, it will warn you, and offer to add it to the local known_hosts file for you. If the remote end doesn't know you, it cannot proceed with the next step: RSA authentication RSA authentication uses the well-known .rhosts file, or alternately the lesser-known (and SSH-specific) .shosts file. These files list hosts (and possibly users) who are allowed to connect to the account without entering a password. Originally this was used for rsh, which is so notoriously insecure that many sysadmins simply disable it. It's now used in conjunction with SSH's public key swapping to provide easy, yet secure access. When both hosts know each other by their respective canonical names, and these names are also listed in each others' .[rs]hosts files, and all the permissions are correct, you can SSH from one host to another without a password. | SSH Authentication |
Most home Internet access for people these days comes in the form of dialup lines, which due to the limited number of IP addresses usually hand them out from a small pool of addresses. This means that every time you connect, you get a new IP address, and thus a new hostname. This wreaks havoc with SSH because the public host keys are related to the hostname. If there's no entry for the hostname you're currently at, you can't get password-less authentication. Listing all possible IP addresses isn't much of a solution, since many providers have dozens of Class C ranges, and at roughly 340 bytes each, that would make the known_hosts file quite large and slow. | So what's the problem? |
Relief is spelled dynssh, a script I (omega) wrote to deal with this, back when I was stuck with a dynamic IP address. It pairs with another script on the server, called dynssh-server to make rewriting of the remote configuration files automatic. Every time you change addresses, just run dynssh to connect to the server and rewrite the right files. The previous hostname is kept both locally and remotely, for authentication purposes as well as making the rewrite of the files possible. | Solution |
First, grab bootstrap.sh and put them somewhere in your path on your local machine. Run it, with the name of the remote host you wish to connect to as the only argument. It will generate a personal key for you if necessary, contact the server, record the necessary public keys, and set up the previous host files. Once that has run, you can ssh freely to the server, until your IP changes. When it does, make sure dynssh.sh is in your path, and call it with the hostname of the server. It will call SSH with the appropriate information, ask for your remote password, and reconfigure things as necessary. You can then go back to using ssh as much as you like. | How? |
dynssh has been certified 100% bug-free by the Supreme Overlord of Software..... HAH! It's a shell script, and a lame one at that. There are a couple functional problems I should fix someday, namely support for multiple roaming hosts. I haven't actually tried it, but I'm pretty sure running bootstrap a second time from a separate machine would do reasonably bad things to the setup. You can try it if you want, but I'm not guaranteeing anything yet. If you find any other bugs, first spend a little time looking at it (if you know shell), then e-mail me at omega@seul.org with whatever information you have. I have better things to do than maintain lame shell code... ;-) | Bugs |