Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
  • I am a linux newbie. I plan on generally using OpenSSH
  • I have spent a number of hours & I can't seem too quickly find the answer
  • I have briefly read some on IETF, however I will be honest its WAY too in-depth & I get lost in the text
  • I have searched this site for the following & didn't find an answer quickly: SSH RSA bad, openssh protocol 2, SSH2 authentication, among others I have forgotten
  • I have searched this site which which says SSH2 only uses DSA (as does this site). It also says SSH2 only uses hosts keys; whereas SSH1 uses server & host keys; that confuses me a little bit
  • This ubuntu page suggests DSA is less secure & suggets to use RSA; nothing is said about SSH2
  • The openbsd man page for sshd_config (which openssh's website links to) under HostKey says RSA1 is only for SSH1; however RSA, dsa, or ecdsa is for SSH2
  • I believe after assembling this question that SSH2 may be coined specifically by SSH Communications Security for their implementation of Secure Shell Protocol 2. As noted above those when I speak of SSH, I plan to only use OpenSSH

How to tell what cipher an existing key is

I have a working key I created with the default options (I entered no arguments) in 'OpenSSH_5.5p1 Debian-4ubuntu6, OpenSSL 0.9.8o 01 Jun 2010'. I can tell its RSA from numerous things (the filename, first lines in .pub key, in the private key); only place I can confirm the bit-strength (I think its called) is when I created it showed the randomart in top showed 2048. How do I know if its RSA1 or RSA2, or regular RSA

Please set me straight as I want the most secure way to do ssh :)

share|improve this question
    
Are you referring to host keys or user keys? –  mgorven Feb 22 '13 at 19:55
    
I am a bit confused on that. What I will tell you is that I needed this to script a file transfer to a customers server. I basically created the key as I noted above, copied the id_rsa.pub file to the customers server manually, renamed it to auhtorization_keys, chmod 700 .ssh folder, 600 file; then I successfully used scp in the script & all is fine. I want to make sure I am using best protection. Per a verbose log I did on scp it seems it is using Protocol 2. Thus I can say it accepts the default OpenSSH RSA key –  gregg Feb 22 '13 at 20:07
    
I think I get it: Host keys are those initial ones generated when connecting for the first time. I am speaking of the user keys... –  gregg Feb 26 '13 at 16:29

2 Answers 2

up vote 2 down vote accepted

TLDR: Use 2048bit RSA keys.

Unless you're using an ancient SSH client or server, you'll be using protocol version 2.

While the DSA and RSA algorithms are comparable in terms of strength, DSA keys may only be 1024bit when used by SSH whereas RSA keys are not limited. 1024bit keys are becoming insecure with the computing power available today, and so you want at least 2048bit, which means RSA. (There also used to be patent issues with RSA which caused DSA to be recommended, but these are no longer the case.)

Pretty much all servers will accept DSA and RSA keys. (Some specific keys are blacklisted due to a Debian bug, but there aren't any disallowed ciphers.) ECDSA is the new hotness, but not all servers support it yet and so it isn't widely usable. Once that changes ECDSA will probably be the way to go.

You can usually tell the type of key by the filename, which is usually id_dsa, id_rsa or id_ecdsa. The file command can also inspect the contains to determine the type:

% file id_rsa
id_rsa: PEM RSA private key

To determine the key length you can use the openssl command:

% openssl rsa -in id_rsa -noout -text | head -n1
Enter pass phrase for id_rsa:
Private-Key: (4096 bit)
% openssl dsa -in id_dsa -noout -text | head -n1
read DSA key
Private-Key: (1024 bit)
share|improve this answer
    
I try to give as much info as possible for fear that my question will be closed. Appreciate the response though, you answered only the first question in the title; would you be willing to answer the other two? –  gregg Feb 26 '13 at 16:26
1  
@gregg See my edit. You should put all questions in the question body, we don't look in the title for actual questions. –  mgorven Feb 26 '13 at 16:42
    
Thanks for that addition. File command did confirm. However it doesn't show number of bits; anyway to confirm that after key creation? I did some manual math (8bits to the character if I rememeber correctly) & wc command, but it didn't add up –  gregg Feb 26 '13 at 18:25
    
@gregg See my edit. –  mgorven Feb 26 '13 at 18:31
    
From this post (serverfault.com/questions/325467/…) it appears an easier way way is to do (the first characters are the bit-length): ssh-keygen -lf id_rsa –  gregg Feb 26 '13 at 19:15

Unless you're worried about eavesdropping from someone with the resources of the NSA, it doesn't really matter. Yes, some algorithms or key lengths have theoretical vulnerabilities that might be exploited, but in practice it's very unlikely that they will be exploited against you unless you're concealing extremely valuable data, and in any case as a "Linux newbie" you're almost certain to have much worse security holes than that.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.