AES is a symmetric encryption algorithm, while RSA is an asymmetric algorithm and are designed for different purposes. AES is useful for the message transmission in real time, like the established SSH connection. In order for a symmetric key algorithm, like AES to work both sides have to use the same key. One of the the problem is, how do both sides get the key in the first place. This is different than the authentication key. In SSH, the session keys are generated, they are not the same key used repeatedly. This is where asymmetric (public key) ciphers like RSA come in to play, which are very good at sending a message one way. SSH then uses the Diffie-Hellman protocol to transfer the shared secret key, like the AES ciphers.

ECC encryption seems to be showing some promise, yet it is still very new having been implmented in openSSH 5.7, which was released only released in January. Support for this protocol may yet be limited as well as being a little new for conservative applications.

3 members found this post helpful.

ecc is used for the public/private keys in openssh instead if RSA. also you must have a version of openSSL that supports ECC for it to work. both keys are modified slightly as they are both currently used.

# cat id_ecdsa.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAFJSNBBHt68UfLxSazUihGvq2/vDZhqoxr/kbZOKUqJvefajyexB9/7sCLnWPXraCa6nEcSplBpwAiOvKbJfrsp+h3HAE=


# openssl x509 -in cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a5:19:d7:29:84:63
Signature Algorithm: ecdsa-with-SHA1
Issuer: C=US, ST=SC, L=CHS, O=Internet Widgits Pty Ltd
Validity
Not Before: Apr 15 21:17:20 2011 GMT
Not After : Feb 2 21:17:20 2014 GMT
Subject: C=US, ST=SC, L=CHS, O=Internet Widgits Pty Ltd
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:a6:49:79:0f:ce:c6:19:ae:30:47:ee:dc:f9:bf:
1a:2f:2a:4a:27:e1:7a:8c:b3:64:47:11:24:66:65:
dc:08:93:92:0f:77:de:c0:5f:1b:21:26:69:58:ff:
81:dd:0d:d1:c8
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Subject Key Identifier:
CA:CE:04:18:F9:51:6E:E3:C9:E3:57:9D:90:BB:F33
X509v3 Authority Key Identifier:
keyid:CA:CE:04:18:F9:51:72:C9:E3:57:9D:90:BB:F3 3

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: ecdsa-with-SHA1
30:46:02:21:00:ae:a0:1b:04:04:3d:57:17:3f:2f:30:49:a6:
61:c0:bc:90:83:af:f7:e2:55:d1:9a:4c:02:b5:ae:94:d6:99:
27:e8:09:bb:b0:8e:bc:3f:66:c1:7e:40:96:d5:e3:31:90:f9
-----BEGIN CERTIFICATE-----
MIIB3DCCAYKgAwIBAgIJAKUZ1ymEY/1PMAkGByqGSM49BAEwSzELMAkGA1UEBhMC
VVMxCzAJBgNVBAgMAlNDMQwwCgYDVQQHDANDSFMxITAfBgNVBAoMGEludGVybmV0
IFdpZGdpdHMgUHR5IEx0ZDAeFw0xMTA0MTUyMTE3MjBaFw0xNDAyMDIyMTE3MjBa
VQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjO
l6JtrNwIk5IPd97AXxshJmlY/4HdDdHIo1AwTjAdBgNVHQ4EFgQUys4EGPlRbuPe
GUNyyeNXnZC789MwHwYDVR0jBBgwFoAUys4EGPlRbuPeGUNyyeNXnZC789MwDAYD
VR0TBAUwAwEB/zAJBgcqhkjOPQQBA0kAMEYCIQCuoBsEBD1XFz8vMEmmYcC8kIOv
9+JV0ZpMArWulNaZKwIhANZJDtHLu4LnUCvz1BxAJ+gJu7COvD9mwX5AltXjMZD5
-----END CERTIFICATE-----

ECC if different because ecc supports many different ciphers.

# openssl ecparam -list_curves
secp112r1 : SECG/WTLS curve over a 112 bit prime field
secp112r2 : SECG curve over a 112 bit prime field
secp128r1 : SECG curve over a 128 bit prime field
secp128r2 : SECG curve over a 128 bit prime field
secp160k1 : SECG curve over a 160 bit prime field
secp160r1 : SECG curve over a 160 bit prime field
secp160r2 : SECG/WTLS curve over a 160 bit prime field
secp192k1 : SECG curve over a 192 bit prime field
secp224k1 : SECG curve over a 224 bit prime field
secp224r1 : NIST/SECG curve over a 224 bit prime field
secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
prime192v2: X9.62 curve over a 192 bit prime field
prime192v3: X9.62 curve over a 192 bit prime field
prime239v1: X9.62 curve over a 239 bit prime field
prime239v2: X9.62 curve over a 239 bit prime field
prime239v3: X9.62 curve over a 239 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
sect113r1 : SECG curve over a 113 bit binary field
sect113r2 : SECG curve over a 113 bit binary field
sect131r1 : SECG/WTLS curve over a 131 bit binary field
sect131r2 : SECG curve over a 131 bit binary field
sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
sect163r1 : SECG curve over a 163 bit binary field
sect163r2 : NIST/SECG curve over a 163 bit binary field
sect193r1 : SECG curve over a 193 bit binary field
sect193r2 : SECG curve over a 193 bit binary field
sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect239k1 : SECG curve over a 239 bit binary field
sect283k1 : NIST/SECG curve over a 283 bit binary field
sect283r1 : NIST/SECG curve over a 283 bit binary field
sect409k1 : NIST/SECG curve over a 409 bit binary field
sect409r1 : NIST/SECG curve over a 409 bit binary field
sect571k1 : NIST/SECG curve over a 571 bit binary field
sect571r1 : NIST/SECG curve over a 571 bit binary field
c2pnb163v1: X9.62 curve over a 163 bit binary field
c2pnb163v2: X9.62 curve over a 163 bit binary field
c2pnb163v3: X9.62 curve over a 163 bit binary field
c2pnb176v1: X9.62 curve over a 176 bit binary field
c2tnb191v1: X9.62 curve over a 191 bit binary field
c2tnb191v2: X9.62 curve over a 191 bit binary field
c2tnb191v3: X9.62 curve over a 191 bit binary field
c2pnb208w1: X9.62 curve over a 208 bit binary field
c2tnb239v1: X9.62 curve over a 239 bit binary field
c2tnb239v2: X9.62 curve over a 239 bit binary field
c2tnb239v3: X9.62 curve over a 239 bit binary field
c2pnb272w1: X9.62 curve over a 272 bit binary field
c2pnb304w1: X9.62 curve over a 304 bit binary field
c2tnb359v1: X9.62 curve over a 359 bit binary field
c2pnb368w1: X9.62 curve over a 368 bit binary field
c2tnb431r1: X9.62 curve over a 431 bit binary field
wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field

when you generate the private key it has a extra section to specify the curve used


# cat key.pem
-----BEGIN EC PARAMETERS-----
rRggqsdfgsdfgMssw== << curve type
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIGk7veSN5+1ApwDyep5Pxyrn/DJfPfEFIKxn6sdajfsdfsdffjjGSM49
aaaaaaaaQgAEpkl5DaskdlfjlksdfjlskdfjfjfjjLNkRxEkZmUrTqIE6uV07bMS
KZeibazcskdlfjsdlfksdlfjSZpWP+B3Q3RyA==
-----END EC PRIVATE KEY-----

Its fine to use with SSH currently but i would not recommend it for SSL certs for a web server yet. As only a custom beta build of chrome supports ECC SSL certificates. Most browsers do not know how to handle it yet. Apache must also be patched to handle ECC

Please, please, please reassure me and tell me I'm not hacked again?


Attached is my sshd_config as I just copied it using grep

By the way, RSA authentication on my personal account (as opposed to a root-account) works now, so I guess it's safe to toggle the setting for PasswordAuthentication now?

Is it safe to attach my /etc/passwd as well for checking by you guys?

Attached Files

sshd_config.txt (2.8 KB, 22 views)

I've downloaded your sshd_config file a couple of times, and it does have seem to have some extra garbage in it, but it is text that could have been caused by being opened and saved in an word processor. It doesn't look harmful. Looking at just the configuration, nothing odd seems to be there. What I would do would be to add an AllowUsers directive to the file and then restart sshd. For example:

AllowUsers martinm


would only allow martinm to use SSH. Obviously you would use the correct login name you use.

There is probably no need to post /etc/passwd. Look in it and see if there are users there that don't look right.

Also check your logs for SSH sessions. If you can account for all of them, I wouldn't worry.

1 members found this post helpful.

If you made changes to these files, which you would have as you configured your SSH server and added your users, you will get alerts like this. Sometimes they happen almost immediately, sometimes they are delayed. Given what you have been through recently, you should review the files to be safe, but chances are there is nothing wrong.

Handog's suggestion of setting the login user is most excellent and is a suggest that is often times overlooked.

Also as a reminder, if you are concerned about your IP address changing be sure you remove that restriction in Iptables after you have your SSH squared away.

IMHO this also emphasizes the use of making (remote!) daily backups and being able to use them later on for verification purposes.

Also there comes a point where checking details is good but one gets wamped and overview gets lost. So unless we move the topic of hardening the server to a separate thread here are some general security and hardening checklists to help re-focus this thread back on post-incident, post-re-installation tasks: CERT Steps for Recovering from a UNIX or NT System Compromise, CERT UNIX Configuration Guidelines, Securing Debian Manual and the CIS Debian Benchmark v1.0.0.

Together the three (historical!) CERT documents mentioned in this thread provide steps for hardening either directly or or by reversing what's sought for. While being one of the oldest, the still comprehensive Securing Debian Manual provides a good overview of all tasks involved and finally the CIS Debian Benchmark should give you an overview of the most important hardening changes as per the CIS. Before you start out best make a baseline copy of all configuration files and run both a local GNU/Tiger scan and a remove OpenVAS (or Nessus?) scan providing you with more baseline data. After making changes running a diff on the configuration files should provide you with an overview of changes to check in case something was forgotten and rerunning those scans the same but from a local and remote viewpoint.

1 members found this post helpful.

One thing that I suggest doing is ... commit all of your configuration-file changes to a version control system, such as "git" or "SVN" or even "CVS." Put the version control repositories away from those systems, and keep backups that are locked in a physical vault. (If you use USB sticks, use several.)

1 members found this post helpful.