`opkssh login` command cannot override existing id_ecdsa

[KieranP]

It appears that using opkssh login cannot override any existing id_ecdsa and id_ecdsa.pub files in ~/.ssh. This is good, because this would have been quite troublesome if it did and I had not had those ssh keys backed up. However, this blocks the use of the login command for those with existing keys.

I recommend that, instead of erroring out, if both id_ecdsa and id_ed25519 are in use, the login command write the ssh key to a new unique filename, e.g. id_opkssh and id_opkssh.pub and print some setup instructions to include adding IdentityFile to each ssh host that needs to use opkssh. And if id_opkssh exists, always update that, even if id_ecdsa/id_ed25519 don't exist.

This would be my preferred approach IMO (i.e. always using id_opkssh)

[EthanHeilman]

@KieranP That's an excellent idea, would you be willing to put together a PR that adds that functionality?

@Foxboron Is hard at work getting ssh agent support in opkssh which should address this problem for people that are using ssh agent. However not everyone is running ssh agent. Having an alternative file name and message telling you how to point ssh at that file would help in this cases.

#6

[mvanderlee]

I'd expand on this and just make the key name configurable via a CLI argument, with id_ecdsa being the default value.
Having a default fallback would just move the problem, so I'd rather see a validation step before triggering the login flow.

opkssh login --key-name id_ecdsa_client1

Optionally we can just ask the user for confirmation on overwrite, but even if approved by the user, I'd copy a backup to /tmp/. We'd just need to ensure we don't overwrite old backups, so either a numeric postfix or timstamp postfix would be required.
This would also imply a --overwrite type flag that would skip the asking for permission.

If we can detect if an existing key was created by opkssh, and potentially even metadata, then we can show that to the user as well, and if not opkssh, show a bigger or red warning.

Pseudocode example

should_overwrite = False
if file(args.key_name).exists:
    should_overwrite = ask_user_for_overwrite_confirmation()
    if should_overwrite:
        move_old_key_to_tmp_as_backup_and_tell_user()  
    else:
        exit()

login()

Warning example for opkssh created keys:

Warning: SSH key created by opkssh detected. User: abc@google.com, Age: 36hr ago
Would you like to overwrite this key? (y/N)

Warning example for non opkssh keys:

#####################################################
Warning: SSH key not created by opkssh detected!
Overwriting this could mean losing access to servers.

Would you like to overwrite this key? (y/N)
#####################################################

[mvanderlee]

Actually, key_name is too limiting. Should be key_path so that the user could specify say ~/.ssh/opkssh/id_ecdsa_client1
This does mean that opkssh should be able to create directories and set their permissions as well.

[markafarrell]

This should already be possible. #111

[mvanderlee]

This should already be possible. #111

Nice!

[EthanHeilman]

@mvanderlee Checking in on this issue. Does #111 or #122 fix this? Can i close this ticket or is this something more that would be useful to add to opkssh?

[mvanderlee]

@EthanHeilman #111 has certainly solved it for me