I have downloaded the precompiled binary, and followed the "Manual Installation" instructions, then generated, exported and added the public key to my remote host; but the authentication using the generated key doesn't work. Is there anything else I need to do that is not outlined in Readme?

Looks like it should be possible to use a Cask with the signed release.

https://github.com/caskroom/homebrew-cask/blob/master/doc/development/adding_a_cask.md

When I am trying to import my public key to AWS management console I am getting:

Error importing Key Pair Key is not in valid OpenSSH public key format

Does anyone know what the problem is? Is it possible that AWS does not support ecdsa keys?

OpenSSH now supports ecdsa-sk and ed25519-sk keys. The '-sk' denotes these are stored on a security key, such as a yubikey.

Since sekey itself is also using hardware backed keys, it could be useful to "indicate" as such an generate these keys as the -sk class so that they can be distinguished from other key types.

What do you think?

Hello,

Not sure if anyone else has noticed. After upgrading to Big Sur, sekey is still running and able to list and export keys, but the SSH client is unable to use it to sign the challenge, throwing this error:

debug1: Offering public key: ecdsa-sha2-nistp256 ECDSA SHA256:REDACTED agent
debug1: Server accepts key: ecdsa-sha2-nistp256 ECDSA SHA256:REDACTED agent
sign_and_send_pubkey: signing failed: communication with agent failed
...

This looks very useful, but I get no output from export-key:

Computer:~ tommy$ sekey --export-key "Github work MBP"
Computer:~ tommy$ sekey -l
┌─────────────────────────┬──────────────────────────────────────────────────┐
│          Label          │                        ID                        │
├─────────────────────────┼──────────────────────────────────────────────────┤
│     Github work MBP     │     5db29e0971f6df63f5e1d8eee9880e3c2def29f7     │
└─────────────────────────┴──────────────────────────────────────────────────┘
Computer:~ tommy$ sekey -c key2
Keypair key2 successfully generated
Computer:~ tommy$ sekey -l
┌─────────────────────────┬──────────────────────────────────────────────────┐
│          Label          │                        ID                        │
├─────────────────────────┼──────────────────────────────────────────────────┤
│     Github work MBP     │     5db29e0971f6df63f5e1d8eee9880e3c2def29f7     │
│     key2                │     32135a11baf4c9faf39dd2353b894c7f82c91ac1     │
└─────────────────────────┴──────────────────────────────────────────────────┘
Computer:~ tommy$ sekey --export-key key2
Computer:~ tommy$ 

What am I missing?

This is more of a feature request than a bug. sekey -d for sekey --delete-keypair sekey -e for sekey --export-key sekey -c (create) for sekey --generate-keypair

error: expected ident, found #
   --> /Users/jk/.cargo/registry/src/github.com-1ecc6299db9ec823/bitflags-1.0.1/src/lib.rs:423:29
    |
423 |                               #[allow(deprecated)]
    |                               ^
    |
   ::: /Users/jk/.cargo/registry/src/github.com-1ecc6299db9ec823/bitflags-1.0.1/src/example_generated.rs
    |
4   | / bitflags! {
5   | |     /// This is the same `Flags` struct defined in the [crate level example](../index.html#example).
6   | |     /// Note that this struct is just for documentation purposes only, it must not be used outside
7   | |     /// this crate.
...   |
13  | |     }
14  | | }
    | |_- in this macro invocation

The ssh-copy-id tool is useful to add your public key to a remote server's authorized_keys file. It can be used with SeKey by exporting a public key to a file and then using ssh-copy-id with it.

It would be nice if SeKey made this a bit easier, something like

sekey -u, --upload-key <[USER@]SERVER> <ID>

Some systems (e.g. some old clusters I occasionally need to log in to) don't have a new enough SSH to support ECDSA keys and require RSA.

Since RSA is supported by the Secure Enclave (kSecAttrKeyTypeRSA), I see no reason why not to have RSA support as well.

• [ ] ed25512 w/ option to change rounds
• [ ] ecdsa {384,512}
• [ ] rsa {2048,4096}

Samples on how I create the above now:

ssh-keygen -q -t ed25519 -o -a 100 -N '' -C "will Farrell's MacBook Pro" -f ~/.ssh/id_ed25512
ssh-keygen -q -t rsa -b 4096 -N '' -C "will Farrell's MacBook Pro" -f ~/.ssh/id_rsa
ssh-keygen -q -t ecdsa -b 521 -N '' -C "will Farrell's MacBook Pro" -f ~/.ssh/id_ecdsa

manpage - matching the arguments might be helpful to most users.

I have an M1 macbook air and I've been using sekey on it for a about a year now, but since I upgraded from Big Sur to Monterey I haven't been able to get it to authenticate at all.

From the SSH end, everything is fine until the signing: debug1:

Next authentication method: publickey
debug1: Offering public key: ecdsa-sha2-nistp256 ECDSA SHA256:<VALID_FINGERPRINT_HERE> agent
debug1: Server accepts key: ecdsa-sha2-nistp256 ECDSA SHA256:<VALID_FINGERPRINT_HERE> agent
sign_and_send_pubkey: signing failed for ECDSA "ecdsa-sha2-nistp256" from agent: communication with agent failed

If I run sekey as debug RUST_LOG=debug sekey --daemon I get:

Pipe deleted
binding to /Users/f8/.sekey/ssh-agent.ssh
DEBUG:ssh_agent::agent: handling new connection
DEBUG:ssh_agent::protocol: reading request
DEBUG:ssh_agent::agent: request: RequestIdentities
DEBUG:ssh_agent::agent: handler: Identities([Identity { key_blob: [KEY_BLOB_DATA], key_comment: "ecdsa-sha2-nistp256" }])
DEBUG:ssh_agent::protocol: reading request
DEBUG:ssh_agent::agent: request: SignRequest { pubkey_blob: [KEY_BLOB_DATA], data: [DATA_BLOB], flags: 0 }
DEBUG:ssh_agent::agent: handler: Error { details: "Key not found" }

Everything looks good in the enclave:

 ~ sekey -l
┌───────────────────────┬──────────────────────────────────────────────────┐
│         Label         │                        ID                        │
├───────────────────────┼──────────────────────────────────────────────────┤
│     Kadin SSH Key     │     A_BIG_ID_NUMBER                              │
└───────────────────────┴──────────────────────────────────────────────────┘
➜  ~ sekey -e A_BIG_ID_NUMBER                         
ecdsa-sha2-nistp256 PUBLIC_KEY_THAT_MATCHES_FINGERPRINT

I've tried reinstalling, rebooting, and everything short of deleting my key from the enclave (because that will be a pain).

When the errors above occur, I am never prompted to use touch ID. Touch ID is working in other apps post upgrade, but I did notice that the dialog design changed a bit.

I'm mostly wondering if anyone else has run into this post-moneterey-upgrade before I try something drastic like nuking my key and starting over.

I found some warnings when I built the project (rustc 1.49-beta3 on MacOS BigSur).

One of them seems to be because the use of env:home_dir is deprecated in favour (so far) of the 'home' crate with the same function name. The other warning appears to be because write_all can return an error if an individual write fails, which means the code was ignoring a result, so I added an 'expect' to each of the write_all calls.

This is a feature request to allow authorizing of SeKey key signing operations with an active paired Apple Watch in addition to the Biometric sensors offered by current Macbooks. This would be useful for people who have their laptop closed during use, such as while using a dock/external monitor. Otherwise keys managed by SeKey are unusable due to TouchID being unavailable with the screen closed, and FaceID not yet being a feature that I'm aware of for Macs (though the API exists).

I believe it should be possible to permit users with paired Apple Watches to use them to authenticate use of SSH keys by adding this constraint - https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/3042482-watch around here: https://github.com/sekey/sekey/blob/master/src/keychain.rs#L369

Perhaps allowing its use could be dictated by a flag to the daemon.

I tried getting the code to build locally to add this, but I can't get it to work for me once built + signed, it simply can't access keys - I'm not familiar enough with Rust or the OSX development environment to sort it out currently, I'm afraid.

Also of note, the existing constraint in use is deprecated as mentioned here: https://github.com/sekey/sekey/issues/26#issuecomment-652753697