On Fri, Nov 29, 2013 at 4:13 PM, Carl Hartung wrote:

This background information is too ambiguous. Has the hardware been upgraded and not the OS? What OS version is presently installed on the old machine? Was it installed 'fresh' or has there been an upgrade path?

The old hardware is still running but very aged. It has come a long way from many previous OpenSuSE versions to currently still at 11.0 32bit. The new hardware is running with clean install of 12.3 64bit

When you actually swap the machines out, you can assign the new machine the same hostname as the original, can't you? I'm not saying this is necessary, but if it can be done, why not do it?

Yes I can of course try swapping out the things, but I kind of want to have new fresh current config files at least (with their respective security settings that probably the old system doesnt have, AllowRootLogin and or similar) without me needing to remove all deprecated stuff manually or adding the new default stuff manually. So thats why I would like to use the old machine keys on the new system, this would describe my needs probably best I think. Maybe just keeping the new "ecdsa" files on the new machine and transport the old other host key files over, would do best for me I suppose. Maybe I am also remembering the install times of OpenSuSE where it also says with what kind of hashing algorithm the local passwords are being saved (currently SHA512), but this is probably a different story, and I wonder how secure safe or long and hard the old sshd host keys were when they got created back then, compared to the keys in the new 12.3 vanilla install. I would like to have best of both worlds, keeping the warnings and changes to end-users to a minimum (ssh warnings and alert such as fingerprint or key changed and mand-in-the-middle-attack), but still having a good situation regarding security settings. Thank you. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Nov 29, 2013 at 7:16 PM, Allen Wilkinson wrote:

In my recent experience between Suse 11.1 and 12.3, the /etc/ssh config files use different ciphers (found via diff'ing the files), hence the keys generated are incompatible. I haven't spent time to fix this yet. I'd welcome news if others have found a fix.

Ah yes, I was about to ask into this kind of direction. With what tool can I actually do a technical analysis or check on these private-key files, what kind of crypto or hashes or whatever (I am pretty much a layman with these kind of things) are being used in them, the strength in bits or all these and similar technical details? Thank you. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 29 Nov 2013, James Knott wrote:

Allen Wilkinson wrote:

...

In my recent experience between Suse 11.1 and 12.3, the /etc/ssh config files use different ciphers (found via diff'ing the files), hence the keys generated are incompatible. I haven't spent time to fix this yet. I'd welcome news if others have found a fix.

While the different versions may generate use different ciphers when creating a key, does that make any difference to users? IIRC, different ciphers can be selected when creating a key, but any cipher should be usable. --

If the public key of the client machine was created using a cipher not accessible to the server machine, then how can the server translate the key to validate a client login? (I am talking about automated passwordless logins) --- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

I need to be clearer. The 12.3 machine is the client machine trying to rsync with an 11.1 machine running the relevant sshd. I created new keys on the 12.3 machine (after fresh install) and put them in ~/.ssh/athorized_keys file on the 11.1 machine. But the 11.1 machine can't understand the keys of the 12.3 machine, when the 12.3 machine tries to login ssh or rsync to the 11.1 machine. This is because the 11.1 machine doesn't have the same ciphers as the 12.3 machine. All are using ssh2. Copying older keys doesn't relate to this case that I can see. Thanks, Allen ---- Address: Allen Wilkinson (cell) (216) 548-2349 1286 Yellowstone Road Cleveland Heights, OH 44121 USA (INTERNET) aw(at)chaff(dot)biz +++++++ On Wed, 4 Dec 2013, John M Andersen wrote:

On Friday, November 29, 2013 04:58:38 PM Allen Wilkinson wrote:

...

On Fri, 29 Nov 2013, James Knott wrote:

...

Allen Wilkinson wrote:

...

In my recent experience between Suse 11.1 and 12.3, the /etc/ssh config files use different ciphers (found via diff'ing the files), hence the keys generated are incompatible. I haven't spent time to fix this yet. I'd welcome news if others have found a fix.

While the different versions may generate use different ciphers when creating a key, does that make any difference to users? IIRC, different ciphers can be selected when creating a key, but any cipher should be usable.

If the public key of the client machine was created using a cipher not accessible to the server machine, then how can the server translate the key to validate a client login? (I am talking about automated passwordless logins) ---

There hasn't been any loss of cyphers, that I can recall. they are all still available, even those that are no longer recommended.

Newer installations no longer have ssh1 turned on by default, but that is a one-line fix in sshd_conf if you want to still support that.

--

...

From the Myth of Me -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/4/2013 4:22 PM, Allen Wilkinson wrote:

I created new keys on the 12.3 machine (after fresh install) and put them in ~/.ssh/athorized_keys file on the 11.1 machine.

But the 11.1 machine can't understand the keys of the 12.3 machine, when the 12.3 machine tries to login ssh or rsync to the 11.1 machine. This is because the 11.1 machine doesn't have the same ciphers as the 12.3 machine.

No, something else is wrong, because I have FAR older (10.2) machines running which can understand the keys of my far newer 12.3 machine. In fact I have keys of various lengths in my 10.2 ~/.ssh/authorized_keys. All I did was copy my PUBLIC key from 12.3 into Authorized keys on 10.2. I believe if you check the cyphers both versions have the same capabilities, and even if not you could choose default ciphers in your 12.3 to match what you were using previously. But this has never been necessary as the protocol negotiates the cypher. You also have the capability of copying the PRIVATE key from another machine into your 12.3 machine's `/.ssh directory. (You can have multiple private keys in there, and it will try them one at a time unless you specify to rsync which key to use.). -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/05/13 01:22, Allen Wilkinson wrote:

I need to be clearer.

The 12.3 machine is the client machine trying to rsync with an 11.1 machine running the relevant sshd.

I created new keys on the 12.3 machine (after fresh install) and put them in ~/.ssh/athorized_keys file on the 11.1 machine.

But the 11.1 machine can't understand the keys of the 12.3 machine, when the 12.3 machine tries to login ssh or rsync to the 11.1 machine.

Are your new keys of type ecdsa? (Check the start of your public key file, it names the type.) That type was not supported in 11.1, but in later versions. If that's the case, use option "-t rsa" when generating the keys with ssh-keygen. Keys produced that way work on 11.1 as well. This has nothing to do with ssh cyphers used for communication encryption, btw. HTH, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/05/2013 10:36 AM, jdd wrote:

Le 05/12/2013 15:31, David C. Rankin a écrit :

...

Simply copy or (rsync -av) the files from old to new computer. NOTE the file

notice that copying files from an old user to a newe user/machine may not work if the user UID is not the same. I use to move the passwd file entirely to keep them, but have only a handfull users :-)

jdd

Correct you are. I have gotten so used to using setup scripts with fixed UID/GID pairs (e.g. groupadd -g <####>; useradd -u <#####> -g <groupname>), that the UID mismatch completely slipped my mind. I haven't tested the impact of a mismatch on ssh connections, but a good consideration to check if things don't work. I gave up moving passwd files a few years ago when there was a change in (? pam or shadow?) or one of the supporting packages that changed the information in passwd or shadow. Since then I just have a bash script with all users/UID and groups/GID that I use to regenerate users and groups. Mindnummingly bland: #!/bin/bash [[ $UID -eq 0 ]] || { echo -e "\n ERROR: You must be root to run this script, \$UID: $UID can't...\n" exit 1 } ## normal groups to add to system groupadd -g 1000 skyline groupadd -g 1030 sharp <snip> ## users to add to groups gpasswd -a david skyline gpasswd -a david sharp <snip> useradd -u 1030 -g sharp -c "Sharp AR-M355N FTP" -M sharp echo -e "\n Setting password for user sharp FTP:" pwexit=1 while [[ $pwexit != 0 ]]; do passwd sharp pwexit=$? done unset pwexit <snip> A little slower to write the script the first time, but every install thereafter, user/group setup is a breeze --and-- I no chance of getting bitten by updates in passwd,pam,shadow,etc.... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org