Difference in ECDSA private key format
(I feel sure I've answered essentially this question before, but I can't find a dupe.)
OpenSSL partly created, and supports, two (or four depending how you count) types of PEM formats for private keys.
Your first file, with BEGIN EC PRIVATE KEY (and no Proc-type,DEK-Info inside), is the 'traditional' or 'legacy' format which is specific to one algorithm, EC. It contains the private key in the format defined by SEC1 from SECG and also available as rfc5915, then encoded/wrapped as 'PEM' i.e. base64 with linebreaks and header/trailer lines.
Your second file, with BEGIN PRIVATE KEY, is the 'new' (since about 2000!) PKCS8 format which is generic and covers all algorithms. Actual PKCS8 was first published by RSA Labs and has become harder to find since RSA was acquired by EMC and that by Dell but is also available as rfc5208, again encoded/wrapped in PEM. This format (but not the legacy format) is among several PEM formats which are updated and restandardized in rfc7468 (see section 10, even though the TOC doesn't hyperlink it correctly!)
Although formatted differently, they do contain the same key:
$ cat se218335.a; openssl pkey -in se218335.a -noout -text
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBaYCj/CjZjq9aYehcvyejxqx5WVJ3OnfNbBq2+7iKyJoAoGCCqGSM49
AwEHoUQDQgAE1Rcx8Zo84aqSWqT/7i5NN7p+PI6dRfGdFFJapfcBlMhMjFsJkrxh
vncLphHuZHBoEILRMKf7hfVJ+tMwHMxQMA==
-----END EC PRIVATE KEY-----
Private-Key: (256 bit)
priv:
16:98:0a:3f:c2:8d:98:ea:f5:a6:1e:85:cb:f2:7a:
3c:6a:c7:95:95:27:73:a7:7c:d6:c1:ab:6f:bb:88:
ac:89
pub:
04:d5:17:31:f1:9a:3c:e1:aa:92:5a:a4:ff:ee:2e:
4d:37:ba:7e:3c:8e:9d:45:f1:9d:14:52:5a:a5:f7:
01:94:c8:4c:8c:5b:09:92:bc:61:be:77:0b:a6:11:
ee:64:70:68:10:82:d1:30:a7:fb:85:f5:49:fa:d3:
30:1c:cc:50:30
ASN1 OID: prime256v1
$ cat se218335.b; openssl pkey -in se218335.b -noout -text
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgFpgKP8KNmOr1ph6F
y/J6PGrHlZUnc6d81sGrb7uIrImhRANCAATVFzHxmjzhqpJapP/uLk03un48jp1F
8Z0UUlql9wGUyEyMWwmSvGG+dwumEe5kcGgQgtEwp/uF9Un60zAczFAw
-----END PRIVATE KEY-----
Private-Key: (256 bit)
priv:
16:98:0a:3f:c2:8d:98:ea:f5:a6:1e:85:cb:f2:7a:
3c:6a:c7:95:95:27:73:a7:7c:d6:c1:ab:6f:bb:88:
ac:89
pub:
04:d5:17:31:f1:9a:3c:e1:aa:92:5a:a4:ff:ee:2e:
4d:37:ba:7e:3c:8e:9d:45:f1:9d:14:52:5a:a5:f7:
01:94:c8:4c:8c:5b:09:92:bc:61:be:77:0b:a6:11:
ee:64:70:68:10:82:d1:30:a7:fb:85:f5:49:fa:d3:
30:1c:cc:50:30
ASN1 OID: prime256v1
OpenSSH began using the OpenSSL legacy formats (RSA and DSA as well as EC) decades ago, and ssh-keygen has never been upgraded to write PKCS8, although it as well as the ssh and sshd (and ssh-add) programs can read PKCS8, because they actually call OpenSSL library routines that handle both types. In particular after extracting the pubkey and configuring it, I can use either of your files to authenticate just fine:
$ ssh -i se218335.a localhost echo hi
hi
$ ssh -i se218335.b localhost echo hi
hi
If you are having a problem using the second file and want to solve it, you might ask about that.
The encoding of the OpenSSH keys is just base64 so once they do not have passphrase, you can analyze the content.
The first one:
$ base64 -d | hexdump -C
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAaAAAABNl
Y2RzYS1zaGEyLW5pc3RwMjU2AAAACG5pc3RwMjU2AAAAQQTVFzHxmjzhqpJapP/u
Lk03un48jp1F8Z0UUlql9wGUyEyMWwmSvGG+dwumEe5kcGgQgtEwp/uF9Un60zAc
zFAwAAAAsGt4wBFreMARAAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy
NTYAAABBBNUXMfGaPOGqklqk/+4uTTe6fjyOnUXxnRRSWqX3AZTITIxbCZK8Yb53
C6YR7mRwaBCC0TCn+4X1SfrTMBzMUDAAAAAgFpgKP8KNmOr1ph6Fy/J6PGrHlZUn
c6d81sGrb7uIrIkAAAASZWNkc2Eta2V5LTIwMTkwOTIwAQIDBAUG
00000000 6f 70 65 6e 73 73 68 2d 6b 65 79 2d 76 31 00 00 |openssh-key-v1..|
00000010 00 00 04 6e 6f 6e 65 00 00 00 04 6e 6f 6e 65 00 |...none....none.|
00000020 00 00 00 00 00 00 01 00 00 00 68 00 00 00 13 65 |..........h....e|
00000030 63 64 73 61 2d 73 68 61 32 2d 6e 69 73 74 70 32 |cdsa-sha2-nistp2|
00000040 35 36 00 00 00 08 6e 69 73 74 70 32 35 36 00 00 |56....nistp256..|
00000050 00 41 04 d5 17 31 f1 9a 3c e1 aa 92 5a a4 ff ee |.A...1..<...Z...|
00000060 2e 4d 37 ba 7e 3c 8e 9d 45 f1 9d 14 52 5a a5 f7 |.M7.~<..E...RZ..|
00000070 01 94 c8 4c 8c 5b 09 92 bc 61 be 77 0b a6 11 ee |...L.[...a.w....|
00000080 64 70 68 10 82 d1 30 a7 fb 85 f5 49 fa d3 30 1c |dph...0....I..0.|
00000090 cc 50 30 00 00 00 b0 6b 78 c0 11 6b 78 c0 11 00 |.P0....kx..kx...|
000000a0 00 00 13 65 63 64 73 61 2d 73 68 61 32 2d 6e 69 |...ecdsa-sha2-ni|
000000b0 73 74 70 32 35 36 00 00 00 08 6e 69 73 74 70 32 |stp256....nistp2|
000000c0 35 36 00 00 00 41 04 d5 17 31 f1 9a 3c e1 aa 92 |56...A...1..<...|
000000d0 5a a4 ff ee 2e 4d 37 ba 7e 3c 8e 9d 45 f1 9d 14 |Z....M7.~<..E...|
000000e0 52 5a a5 f7 01 94 c8 4c 8c 5b 09 92 bc 61 be 77 |RZ.....L.[...a.w|
000000f0 0b a6 11 ee 64 70 68 10 82 d1 30 a7 fb 85 f5 49 |....dph...0....I|
00000100 fa d3 30 1c cc 50 30 00 00 00 20 16 98 0a 3f c2 |..0..P0... ...?.|
00000110 8d 98 ea f5 a6 1e 85 cb f2 7a 3c 6a c7 95 95 27 |.........z<j...'|
00000120 73 a7 7c d6 c1 ab 6f bb 88 ac 89 00 00 00 12 65 |s.|...o........e|
00000130 63 64 73 61 2d 6b 65 79 2d 32 30 31 39 30 39 32 |cdsa-key-2019092|
00000140 30 01 02 03 04 05 06 |0......|
The second one:
$ base64 -d | hexdump -C
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAaAAAABNl
Y2RzYS1zaGEyLW5pc3RwMjU2AAAACG5pc3RwMjU2AAAAQQTVFzHxmjzhqpJapP/u
Lk03un48jp1F8Z0UUlql9wGUyEyMWwmSvGG+dwumEe5kcGgQgtEwp/uF9Un60zAc
zFAwAAAAsFhPTMdYT0zHAAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy
NTYAAABBBNUXMfGaPOGqklqk/+4uTTe6fjyOnUXxnRRSWqX3AZTITIxbCZK8Yb53
C6YR7mRwaBCC0TCn+4X1SfrTMBzMUDAAAAAgFpgKP8KNmOr1ph6Fy/J6PGrHlZUn
c6d81sGrb7uIrIkAAAASZWNkc2Eta2V5LTIwMTkwOTIwAQIDBAUG
00000000 6f 70 65 6e 73 73 68 2d 6b 65 79 2d 76 31 00 00 |openssh-key-v1..|
00000010 00 00 04 6e 6f 6e 65 00 00 00 04 6e 6f 6e 65 00 |...none....none.|
00000020 00 00 00 00 00 00 01 00 00 00 68 00 00 00 13 65 |..........h....e|
00000030 63 64 73 61 2d 73 68 61 32 2d 6e 69 73 74 70 32 |cdsa-sha2-nistp2|
00000040 35 36 00 00 00 08 6e 69 73 74 70 32 35 36 00 00 |56....nistp256..|
00000050 00 41 04 d5 17 31 f1 9a 3c e1 aa 92 5a a4 ff ee |.A...1..<...Z...|
00000060 2e 4d 37 ba 7e 3c 8e 9d 45 f1 9d 14 52 5a a5 f7 |.M7.~<..E...RZ..|
00000070 01 94 c8 4c 8c 5b 09 92 bc 61 be 77 0b a6 11 ee |...L.[...a.w....|
00000080 64 70 68 10 82 d1 30 a7 fb 85 f5 49 fa d3 30 1c |dph...0....I..0.|
00000090 cc 50 30 00 00 00 b0 58 4f 4c c7 58 4f 4c c7 00 |.P0....XOL.XOL..|
000000a0 00 00 13 65 63 64 73 61 2d 73 68 61 32 2d 6e 69 |...ecdsa-sha2-ni|
000000b0 73 74 70 32 35 36 00 00 00 08 6e 69 73 74 70 32 |stp256....nistp2|
000000c0 35 36 00 00 00 41 04 d5 17 31 f1 9a 3c e1 aa 92 |56...A...1..<...|
000000d0 5a a4 ff ee 2e 4d 37 ba 7e 3c 8e 9d 45 f1 9d 14 |Z....M7.~<..E...|
000000e0 52 5a a5 f7 01 94 c8 4c 8c 5b 09 92 bc 61 be 77 |RZ.....L.[...a.w|
000000f0 0b a6 11 ee 64 70 68 10 82 d1 30 a7 fb 85 f5 49 |....dph...0....I|
00000100 fa d3 30 1c cc 50 30 00 00 00 20 16 98 0a 3f c2 |..0..P0... ...?.|
00000110 8d 98 ea f5 a6 1e 85 cb f2 7a 3c 6a c7 95 95 27 |.........z<j...'|
00000120 73 a7 7c d6 c1 ab 6f bb 88 ac 89 00 00 00 12 65 |s.|...o........e|
00000130 63 64 73 61 2d 6b 65 79 2d 32 30 31 39 30 39 32 |cdsa-key-2019092|
00000140 30 01 02 03 04 05 06 |0......|
00000147
The key format is described in the OpenSSH repository.
The difference here is that one key has the following bytes 6b 78 c0 11 6b 78 c0 11 and the other 58 4f 4c c7 58 4f 4c c7. These bytes represent two random 32B integers that are same and that are used for verification that the deciphered key is really valid (in case of there is used encryption). See the checkint field in the linked document.
Both of the keys are valid according to the specification (in OpenSSH key format).
For the difference of the PEM format, see the dave_thompson_085's answer. TLDR, one of them is legacy PEM and the other is modern PKCS# 8 format including the same key, where both of them are understood by OpenSSH.