[lug] making mistakes, in hurry, ssh2 keys
D. Stimits
stimits at idcomm.com
Mon Dec 10 12:50:13 MST 2001
Ok, I'm in a hurry, trying not to make mistakes, but I am anyway. I
cannot seem to get this right. I'm using ssh with protocol 2 on both
linux and a remote site. A while back I changed my local machine name
(many months ago), and kept my original key. This worked great, my ssh
access worked fine. Now it doesn't. I found out that it is rejecting my
key, probably because my machine name now differs from what is in the
key. These are connected between via (keep in mind my linux ssh client
is ssh2 only, and the server accepts protocol 2 only):
ssh -l <myloginname> -c 3des -m hmac-md5 <remote_address>
This is the recommended command from the site I am going to that used to
work ok. My usual command that has worked for a very long time (and is
now bugging the *rap out of me):
ssh -t -2 -l <my_login_name> <remote_address>
Or also without the "-t" worked fine.
Then it stopped working over the weekend, and mysteriously started
working after a couple of days. This was a few weeks ago. Now it is
doing it again, verbose ssh reveals what looks like key rejection. I
want to compare the public key I have shown as acceptable at the remote
site to the public key I am using locally to get in (this is all
password auth, but it seems keys are needed on top of this, and it will
not accept a password unless the key is *also* ok). In theory my public
key locally was inserted into the accepted keys at the remote site.
I *think* that I need to compare my local ~/.ssh/identity.pub or
~/.ssh/id_dsa.pub with one line of content on the remote machine's
~/.ssh/authorized_keys2. I am using ssh client locally to go to remote
site shell. I can verify that my local identity.pub matches the remote
authorized_keys. I can also verify that any local id_dsa.pub matches my
remote ~/.ssh/authorized_keys2.
I am assuming this means it is rejecting my keys because my machine name
locally now does not match the machine name in the key, despite the keys
matching. Does this sound correct? Can I not use the authorized key with
a new machine name if my private and public keys did not change? My
internal address will not resolve on the Internet on the local system,
so I did not think it mattered, any local machine name is bogus anyway.
And since I have been making mistakes all morning trying to do this, and
am in somewhat of a hurry, can anyone recommend the way to update both
the ssh1 and ssh2 keys? I don't seem to be doing anything right today.
D. Stimits, stimits at idcomm.com
More information about the LUG
mailing list