petesea at bigfoot.com
2007-Jan-23 03:22 UTC
Move servers public/private keys to a new host
Is it possible to move a server's public and private keys from one host to another? Or perhaps a better way to ask what I really want... is it possible to configure a server on a new host to return the same public key it did on the old host? I'm in the process of migrating our CVS server from a Solaris host to a Linux host (this weekend) and I just realized the hostkey is going to change. I tried copying the old host's pub/priv keys to the new host, but when I start sshd on the new host (using -ddd) I get: debug3: Not a RSA1 key file /usr/local/etc/ssh/old_ssh_host_rsa_key debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Could not load host key: /usr/local/etc/ssh/old_ssh_host_rsa_key The biggest problem is with all our Windows users. Since they only use SSH (really plink) for CVS access, the CVS command fails if plink detects the hostkey has changed. This is really because the cvs command will fail if it gets ANY response it doesn't understand. Many (most) of our Windows users use various GUI CVS clients that often hide any output plink might display, but even if they DO happen to see any output, 99% wouldn't know what to do based on the error. I'm trying to avoid a barrage of tech support calls the day after the server changes.
petesea at bigfoot.com wrote:> Is it possible to move a server's public and private keys from one host to > another? Or perhaps a better way to ask what I really want... is it > possible to configure a server on a new host to return the same public key > it did on the old host?Yes, you can move them. All you need to do is copy the files over. Make sure they are in the right place and away you go. If the keys were actualy tied to the hardware this would be more difficult but they aren't.
Circa 2007-01-22 22:22 dixit petesea at bigfoot.com: : Is it possible to move a server's public and private keys from one host to : another? Or perhaps a better way to ask what I really want... is it : possible to configure a server on a new host to return the same public key : it did on the old host? : : I'm in the process of migrating our CVS server from a Solaris host to a : Linux host (this weekend) and I just realized the hostkey is going to : change. : : I tried copying the old host's pub/priv keys to the new host, but when I : start sshd on the new host (using -ddd) I get: : : debug3: Not a RSA1 key file /usr/local/etc/ssh/old_ssh_host_rsa_key : debug1: PEM_read_PrivateKey failed : debug1: read PEM private key done: type <unknown> : Could not load host key: /usr/local/etc/ssh/old_ssh_host_rsa_key Apparently sshd on the Linux host is unable to read the key in .../old_ssh_host_rsa_key. What SSH server were you using on the Solaris host? Does old_ssh_host_rsa_key have the proper BEGIN and END lines around it? For example: # head -1 /etc/ssh/ssh_host_rsa_key -----BEGIN RSA PRIVATE KEY----- # tail -1 /etc/ssh/ssh_host_rsa_key -----END RSA PRIVATE KEY----- # Is openssl able to read the key? For example: # openssl rsa -text -noout -in /etc/ssh/ssh_host_rsa_key |head -1 Private-Key: (2048 bit) # How did you copy the key from the Solaris machine to the Linux machine? Is it possible the key got corrupted or truncated in transit? : : The biggest problem is with all our Windows users. Since they only use : SSH (really plink) for CVS access, the CVS command fails if plink detects : the hostkey has changed. This is really because the cvs command will fail : if it gets ANY response it doesn't understand. : : Many (most) of our Windows users use various GUI CVS clients that often : hide any output plink might display, but even if they DO happen to see any : output, 99% wouldn't know what to do based on the error. : : I'm trying to avoid a barrage of tech support calls the day after the : server changes. : _______________________________________________ : openssh-unix-dev mailing list : openssh-unix-dev at mindrot.org : http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev : -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+
petesea at bigfoot.com
2007-Jan-24 03:47 UTC
Move servers public/private keys to a new host
OK.... never mind, I panicked too soon. My cut and paste of the private key missed a few bits on the cut and/or the paste. Once I got the private key correct everything started to work. On Mon, 22 Jan 2007, petesea at bigfoot.com wrote:> Is it possible to move a server's public and private keys from one host to > another? Or perhaps a better way to ask what I really want... is it possible > to configure a server on a new host to return the same public key it did on > the old host? > > I'm in the process of migrating our CVS server from a Solaris host to a Linux > host (this weekend) and I just realized the hostkey is going to change. > > I tried copying the old host's pub/priv keys to the new host, but when I > start sshd on the new host (using -ddd) I get: > > debug3: Not a RSA1 key file /usr/local/etc/ssh/old_ssh_host_rsa_key > debug1: PEM_read_PrivateKey failed > debug1: read PEM private key done: type <unknown> > Could not load host key: /usr/local/etc/ssh/old_ssh_host_rsa_key > > The biggest problem is with all our Windows users. Since they only use SSH > (really plink) for CVS access, the CVS command fails if plink detects the > hostkey has changed. This is really because the cvs command will fail if it > gets ANY response it doesn't understand. > > Many (most) of our Windows users use various GUI CVS clients that often hide > any output plink might display, but even if they DO happen to see any output, > 99% wouldn't know what to do based on the error. > > I'm trying to avoid a barrage of tech support calls the day after the server > changes. >