OpenSSL vulnerability

[rescdsk]

There's a problem in Debian's version of OpenSSL, with a predictable random number generator. The announcement is here: http://lists.debian.org/debian-security-announce/2008/msg00152.html . The problem makes key material, such as OpenVPN keys and SSH public-key authentication keys, vulnerable, and you need to replace the keys generated with old versions.

Does this problem exist on Ubuntu too?


EDIT bodhi.zazen: Adding information so that people do not need to read the entire thread for some basic information.

1. There are a few tools to check your ssh keys, most are affected so be warned.

ssh-vulnkey is included in the update of openssh-server.

On a Debian/Ubuntu box with ssh server installed :

sudo apt-get update && sudo apt-get dist-upgradeapt-get dist-upgrade will install the packages (apt-get upgrade *may* show the packages are held).

You can then run :


sudo ssh-vulnkey -aIf you see "Not Blacklisted: xxx.yyy.zzz /path/to/key" you are ok.

The update will regenerate your server keys

2. If you are updating ssh keys on a remote server, be careful. When the ssh keys are regenerated *some* users have lost the ssh connection. If you use keys to ssh into the server, first make sure you have alternate access to the server (temporarily allow logins with password ?) until new keys are in place.

EDIT 2 bodhi.zazen: for clarification :

This vulnerability affects more then ssh, ntp, imap, pop, smtp, tls, certificate authorities for pgp, openVPN, web servers with SSL, and more. Basically, anybody that used an SSL key generated.

More info can be found at http://www.debian.org/security/key-rollover/

~ Thanks Conficio (http://ubuntuforums.org/member.php?find=lastposter&t=793517) for the clarification and link

bodhi.zazen

[Monicker]

http://www.ubuntu.com/usn/usn-612-1
http://www.ubuntu.com/usn/usn-612-2


Edit: URL modified to reflect change in Ubuntu, which also gives more detail about regenerating keys.

[Tuna-Fish]

Is there a fast way to tell a computer to regenerate all the keys? How should I start doing it?

[SuperMike]

This came in the news today:

http://lists.debian.org/debian-security-announce/2008/msg00152.html

I hope we see a patch in Ubuntu soon.

[yaztromo]

Is there a fast way to tell a computer to regenerate all the keys? How should I start doing it?

I'd like to know this too.

I've upgraded the packages on my server, but do I need to do anything else?

[jojo4u]

Just watch for http://www.debian.org/security/key-rollover/

EDIT: Does dowkd.pl from the Debian advisory find something for you? The program is a bit too quiet for my taste (no output).

[yaztromo]

Is there a fast way to tell a computer to regenerate all the keys? How should I start doing it?

Okay here's how I did it for SSH. Not the most elegant way but it works.

1. Login as root or use sudo.
2. Copy your ssh configs so you can put them back later:

cp /etc/ssh/ssh_config ./
cp /etc/ssh/sshd_config ./
3. Remove purge openssh-server:

apt-get purge openssh-server
4. Reinstall openssh-server:

apt-get install openssh-server
5. While installing watch for the following output. If you see it then all is good:

Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
6. Move back your old configs:

mv sshd_config /etc/ssh/
mv ssh_config /etc/ssh/
7. Restart sshd

/etc/init.d/ssh restart

Note this won't work for feisty since it has no "apt-get purge", you will need to manually delete the keys in /etc/ssh/ instead.

[jojo4u]

OK, found some old keys (gutsy or older=) and ran


perl dowkd.pl file /media/ACERDATA/LINUX/etc/ssh/*key*

/media/ACERDATA/LINUX/etc/ssh/ssh_host_dsa_key:12: warning: unparsable line
...
/media/ACERDATA/LINUX/etc/ssh/ssh_host_dsa_key.pub:1: weak key
/media/ACERDATA/LINUX/etc/ssh/ssh_host_rsa_key:1: warning: unparsable line
...
/media/ACERDATA/LINUX/etc/ssh/ssh_host_rsa_key.pub:1: weak key

[todb]

How to use dowkd.pl as a quick sniff test for machines you control or are responsible for:



todb@mazikeen:~/Desktop$ perl dowkd.pl host 10.10.10.54
# 10.10.10.54 SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1
# 10.10.10.54 SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1
10.10.10.54: weak key
10.10.10.54: weak key




todb@mazikeen:~/Desktop$ perl dowkd.pl host planb-security.net
# planb-security.net SSH-2.0-OpenSSH_5.0
# planb-security.net SSH-2.0-OpenSSH_5.0


(No hits == good)


..and for files:


todb@mazikeen:~/Desktop$ perl dowkd.pl file ~/.ssh/*
/home/todb/.ssh/known_hosts:13: weak key
/home/todb/.ssh/known_hosts:14: weak key
/home/todb/.ssh/known_hosts:22: weak key

..etc.

hth. have fun regenerating.

-tod

[jojo4u]

EDIT: The new openssh-server package fixes your keys.

About scanning your localhost for weak keys some additions to todb's post:


> perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1
# localhost SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1
localhost: weak key
localhost: weak key

> perl dowkd.pl file /etc/ssh/*key*
/etc/ssh/ssh_host_dsa_key:0: open failed: Permission denied
/etc/ssh/ssh_host_dsa_key.pub:1: weak key
/etc/ssh/ssh_host_rsa_key:0: open failed: Permission denied
/etc/ssh/ssh_host_rsa_key.pub:1: weak key

After upgrade of openssh-server


> perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.1
# localhost SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.1

> perl dowkd.pl file /etc/ssh/*key*
/etc/ssh/ssh_host_dsa_key:0: open failed: Permission denied
/etc/ssh/ssh_host_dsa_key.broken:0: open failed: Permission denied
/etc/ssh/ssh_host_dsa_key.pub.broken:1: weak key
/etc/ssh/ssh_host_rsa_key:0: open failed: Permission denied
/etc/ssh/ssh_host_rsa_key.broken:0: open failed: Permission denied
/etc/ssh/ssh_host_rsa_key.pub.broken:1: weak key

[todb]

By the way, there's an overly restrictive dependency for openssh-server:



todb@mazikeen:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run `apt-get -f install' to correct these.
The following packages have unmet dependencies:
openssh-server: Depends: openssh-client (= 1:4.6p1-5ubuntu0.2) but 1:4.6p1-5ubuntu0.3 is installed
E: Unmet dependencies. Try using -f.
todb@mazikeen:~$


This should be fixed when the package is fixed to correct the bad template bug.

[rescdsk]

Any ideas about how to check for bad OpenVPN keys? dowkd.pl doesn't seem to be able to read the key/pem/csr/crt/whatever files.

[CheShA]

I presume they are hurriedly pushing out an update which has something to do with the broken version of ssh that the repos are currently trying to feed me. Bad time to try upgrading... :(




Unpacking openssh-server (from .../openssh-server_1%3a4.6p1-5ubuntu0.3_amd64.deb) ...
Template #4 in /var/lib/dpkg/tmp.ci/templates has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.
dpkg: error processing /var/cache/apt/archives/openssh-server_1%3a4.6p1-5ubuntu0.3_amd64.deb (--unpack):

[Joshua Swink]

Help, openssh-server won't upgrade:


Selecting previously deselected package openssh-server.
(Reading database ... 170739 files and directories currently installed.)
Unpacking openssh-server (from .../openssh-server_1%3a4.6p1-5ubuntu0.3_i386.deb) ...
Template #4 in /var/lib/dpkg/tmp.ci/templates has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.
dpkg: error processing /var/cache/apt/archives/openssh-server_1%3a4.6p1-5ubuntu0.3_i386.deb (--unpack):
subprocess pre-installation script returned error exit status 255
Errors were encountered while processing:
/var/cache/apt/archives/openssh-server_1%3a4.6p1-5ubuntu0.3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


A workaround would be greatly appreciated. This is in Ubuntu 7.10.

[DarkHelmet]

I just tried the upgrade as well, and the install script for openssh-server is not working.

below is the error I get:

root@keekles:/etc/apache2/mods-enabled# apt-get install openssh-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
ssh-askpass xbase-clients rssh molly-guard
The following packages will be upgraded:
openssh-server
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0B/250kB of archives.
After unpacking 4096B of additional disk space will be used.
Preconfiguring packages ...
openssh-server template parse error: Template #4 in /tmp/openssh-server.template.37030 has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.

(Reading database ... 32381 files and directories currently installed.)
Preparing to replace openssh-server 1:4.6p1-5ubuntu0.2 (using .../openssh-server_1%3a4.6p1-5ubuntu0.3_i386.deb) ...
Template #4 in /var/lib/dpkg/tmp.ci/templates has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.
dpkg: error processing /var/cache/apt/archives/openssh-server_1%3a4.6p1-5ubuntu0.3_i386.deb (--unpack):
subprocess pre-installation script returned error exit status 255
Errors were encountered while processing:
/var/cache/apt/archives/openssh-server_1%3a4.6p1-5ubuntu0.3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@keekles:/etc/apache2/mods-enabled#

[todb]

Correct. Please see Comment 11 (http://ubuntuforums.org/showpost.php?p=4949533&postcount=11). openssh-server's deb package is currently nonfunctional for at least two reasons, so you'll want to wait a bit before trying to upgrade.

[sunbird]

I am not running ssh server, just the client, and I have some trouble with the upgrade.

I downloaded the packages listed here (http://www.ubuntu.com/usn/usn-612-1) and all of them installed except for libcrypto0.9.8-udeb_0.9.8g-4ubuntu3.1 for which I get the following:



$ sudo dpkg -i libcrypto0.9.8-udeb_0.9.8g-4ubuntu3.1_amd64.udeb
(Reading database ... 115335 files and directories currently installed.)
Unpacking libcrypto0.9.8-udeb (from libcrypto0.9.8-udeb_0.9.8g-4ubuntu3.1_amd64.udeb) ...
dpkg: error processing libcrypto0.9.8-udeb_0.9.8g-4ubuntu3.1_amd64.udeb (--install):
trying to overwrite `/usr/lib/libcrypto.so.0.9.8', which is also in package libssl0.9.8
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
libcrypto0.9.8-udeb_0.9.8g-4ubuntu3.1_amd64.udeb


Any help?

[rescdsk]

I am not running ssh server, just the client, and I have some trouble with the upgrade.




$ sudo dpkg -i libcrypto0.9.8-udeb_0.9.8g-4ubuntu3.1_amd64.udeb


Any help?

That one is a udeb --- those are used in the installer, you don't need them on a complete system.

[glotz]

At http://www.ubuntu.com/usn/usn-612-2 it says you'll have to jump thru 5 hoops because of this problem. What about the millions of users that don't happen to read this announcement?

[fishtoprecords]

anyone know where to find the magic fix program:
ssh-vulnkey

as mentioned in the releases.

[murchball]

I'm confused. I just did an apt-get update and apt-get upgrade but for some reason it's holding back openssh-client and openssh-server. Is this because they're still working on a patch for the patch?

[sunbird]

That one is a udeb --- those are used in the installer, you don't need them on a complete system.

Eek! Didn't know that. And I thought I was missing something important. :KS

[jojo4u]

anyone know where to find the magic fix program:
ssh-vulnkey

as mentioned in the releases.


`--> wajig whichpkg ssh-vulnkey
File Path Package
================================================== =========-=================
INSTALLED
/usr/bin/ssh-vulnkey openssh-client
/usr/share/man/man1/ssh-vulnkey.1.gz openssh-client

`--> wajig status openssh-client
Package Installed
=======================-===============
openssh-client 1:4.7p1-8ubuntu1.1

[Kimos]

Okay here's how I did it for SSH. Not the most elegant way but it works.

...

I'm pretty sure there's an easier way. For SSH2:

sudo ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
sudo ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa

I'll give it a shot when I get home. I'm not entirely confident that I should try overwriting my SSH keys while using an SSH session.

[Monicker]

I'm confused. I just did an apt-get update and apt-get upgrade but for some reason it's holding back openssh-client and openssh-server. Is this because they're still working on a patch for the patch?

The update is not on all of the mirror repositories yet. You can get from the main repository though.

[whoop]

i ran "sudo ssh-vulnkey -a". It gave me no output at all. What does this mean?
Has anybody succesfully re-generated their keys yet using ssh-keygen? And what was the exact method used?

Cheers

[tubezninja]

I'm confused. I just did an apt-get update and apt-get upgrade but for some reason it's holding back openssh-client and openssh-server. Is this because they're still working on a patch for the patch?

Not sure why apt-get is doing that, but I solved the problem by logging in at the console and doing the following:


sudo apt-get purge openssh-client openssh-server
sudo apt-get install openssh-client openssh-server

It installed, along with ssh-vulnkey, and generated new keys.

[Valliant]

Just looking for a bit of clarity here.

After patching, I'm going to have to repurchase all my CA provided SSL certificates aren't I?

[randyrick]

https://lists.ubuntu.com/archives/ubuntu-security-announce/2008-May/000705.html

http://lists.debian.org/debian-security-announce/2008/msg00152.html

I went ahead & dist-upgraded and during the upgrade SSH keys were regenerated, nice.

Does this mean everything I generated an SSL certificate for should also be recreated???

[Dr Small]

Most likely. I would at least for added security.
I just got done recreating my SSH keys :)

[twisted_steel]

This page has some additional info on steps to check for vulnerable ssh keys and regenerate them.

http://www.ubuntu.com/usn/usn-612-2

[DigitalDuality]

d

[twisted_steel]

well i've recreated my keys, following this tutorial:

http://www.howtoforge.com/ssh_key_based_logins_putty_p4

(i have access to a windows box and 3 linux boxes) as of now.

Anyways,

i allowed port 22 in iptables to come from the internal address (the win box) i'm trying it from.

My hosts.allow file has an entry to allow sshd from said internal address.

my sshd config is set to allow the user

my fail2ban shouldn't be getting in the way as far as i know.

And putty in windows is still kicking me an error that the server rejected the connection and for the life of me i can't figure out why.

Do you know if PuTTY is set to automatically drop the connection if the host key has changed? The Ubuntu updates regenerated the SSH host keys.

EDIT:
What is the error that you are getting from PuTTY? Maybe it still has the old user keys on the server?

[DigitalDuality]

i messed up something with the updates in synaptic i think, as i hit "cancel" on every prompt it gave my about the keys as i wasn't ready to regenerate them yet, but as it stands, but then i tested and noticed my win/putty connection didn't work any longer so i re-installed it.

now in /etc/ssh is see ssh_host.rsa_key, dsa_key, dsa_key.pub, rsa_key.pub and *.broken for each that i just listed.

I manually recreated the keys for the particular user (authorized_keys2)

i'm still not quite sure what's wrong. The private key is imported into putty, putty always notified me if locations change or if i've changed keys before.

/var/log/auth.log is showing a couple of lines such as:

sshd: refused connect from ::key (::key)

(key being put of the key)

[randyrick]

Thanks for the good info.

[sinling]

I have a question, if i used the affected openssl and openvpn. Do i really need to regenerate all the key for my openvpn server and client?

From what i know, if my vpn user want to openvpn back to my central server they need to key in the passphrase. So will it save the time from redo everything from scratch? I know the server key file is vulnerable but i do not want to regenerate 100+ user key in 1 day. That is pain.
Any advise or tips for avoid the regenerate process for openvpn?

BTW, i can avoid ubuntu openvpn "vuln check" by compile the openvpn from source provide by openvpn. :D

thanks.

Note: I don't think it is very "vulnerable". Because the user still need to "authenticate" to the key. I have do md5sum and openssl-vulnkey to the client secret key with old (vulnerable) and new (libssl updated) and compare with the openssl blacklist. 2 generate key have "5" bit same when i compare with black list data.And you still need to key in the passphrase for the checking. So my guess is, it is not very serious problem as it describe or i might be wrong. But, it is good to upgrade it to new version. Unpredictable is always better than predictable. lol!
My tips is, always secure you secret key. And if you think u have been compromised, remove it and generate a new key.


I almost change my mind to move back to Centos / FC .... almost...

[sunbird]

After patching, I'm going to have to repurchase all my CA provided SSL certificates aren't I?

Some CAs will allow you to revoke your certificates and reissue them without charge. You will need to look at the specific contract/terms for your CA, which should be available somewhere on their website or by contacting support.

[p_quarles]

Thread stickied. This will be temporary, most likely.

EDIT: And merged with similar thread.

[CheShA]

Just looking for a bit of clarity here.

After patching, I'm going to have to repurchase all my CA provided SSL certificates aren't I?

No you're not, mate. This is related to SSL encryption keys you have generated youself. If your CA has suffered in any way because of this problem then they should reissue your SSL certs free.

[masmad]

I have to say I'm a bit confused about this. The USN description says:

Once the update is applied, weak user keys will be automatically rejected where possible (though they cannot be detected in all cases).

Does that mean that the ssh-vulnkey tool can't locate all the keys on a filesystem and thus might fail, or does it mean that the tool can't be 100% sure whether a key is reliable?

So far I've gotten three different results running ssh-vulnkey on different machines: a key can be "Compromised", "Not Blacklisted" or "Unknown".

man ssh-vulnkey doesn't explain what these mean. It does say "This tool may be useful in checking for such keys." May.

Does "Unknown" mean the same as "Not Blacklisted"?
A blacklist either contains (in this case) a key or it doesn't.

If I've understood correctly and ssh-vulnkey can't be relied upon to verify the key, then why not just change the keys by default? Or ask the user during the upgrade?

[marcusherou]

Do this on all servers
From: http://www.softec.st/en/OpenSource/DevelopersCorner/HowToRegenerateNewSsh.html

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa

[TeaSipper]

How would I best update SSH and its keys on a colocated server which can only be accessed through SSH? I'd rather not visit the datacenter.

The server is running Ubuntu 7.10

[davidshere]

I saw that there were some problems with upgrading openssh-server... upgrades crashing and what not. But I haven't seen anyone say that it worked fine for them, so I thought I'd post and say that I have run upgrades to openssh-server on six different machines, two Hardy, three Gutsy, and one Feisty, and have had no problems. The Hardy machines and one of the Gutsy machines asked me to re-create the keys, I hit "enter" and everything completed with no problems.


I'm confused. I just did an apt-get update and apt-get upgrade but for some reason it's holding back openssh-client and openssh-server. Is this because they're still working on a patch for the patch?

Some packages are held back when you upgrade from the command line and not held back when you upgrade from the GUI... I've never figured out why. Upgrading from the GUI wil solve this, or if you only have a terminal prompt, try this:


sudo apt-get dist-upgrade

I run this complete command:

sudo apt-get update && sudo apt-get dist-upgrade && sudo apt-get dist-upgrade

[murchball]

dist-upgrade took care of it on my 64 bit desktop. The upgrade rebuilt my keys and then running ssh-vulnkey reported that both keys are not blacklisted. Now on to the rest of my systems....

[rescdsk]

Has anyone fixed the "duplicate template" problem yet?



Template #4 in /var/lib/dpkg/tmp.ci/templates has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.


I regenerated my own openssh-server keys before trying to upgrade, though I don't see how that could make the pre-install crash.

[sunbird]

After patching, I'm going to have to repurchase all my CA provided SSL certificates aren't I?

Look on your CA website for the contract that governs your CA. It should have a clause on revocations. For example, this is the .pdf for ipsCA's contract (http://certs.ipsca.com/Store/CPSIPSCAv2Abril2002.pdf) (only in Spanish) and it clearly provides that if there's a problem with the certificate that makes it untrustworthy, you get a new one for free.

This is page 45-46, which talks about the reasons why a certificate may be revoked:


Los Certificados deberán ser revocados cuando concurra alguna de las circunstancias siguientes:
*snip*
Por cualquier causa que razonablemente induzca a creer que el servicio de certificación haya sido comprometido hasta el punto que se ponga en duda la fiabilidad del Certificado.

Rough translation: The certificate may be revoked when ... there's something that makes you reasonably believe that the certificate has been compromised to the point that it is not reliable.

And then on page 47 it says:


La revocación del Certificado por causa no imputable al Suscriptor originará la emisión de un nuevo Certificado a favor del Suscriptor por el plazo equivalente al restante para concluir el período originario de validez del Certificado revocado.

Rough translation: If the revocation of the certificate is not the fault of the subscriber (that's you), then you get a new certificate with the same validity period as the old one.

Obviously, you have to check with the contract governing your CA, but you will probably find something similar, so check with your CA before paying for new certs.

And, of course, if you use CAcert (http://www.cacert.org/) you can generate a new one for free, but users have to import the CA cert root certificate or they get nasty warnings.

[TeaSipper]

How would I best update SSH and its keys on a colocated server which can only be accessed through SSH? I'd rather not visit the datacenter.

The server is running Ubuntu 7.10

To answer my own question for people with the same problem: I ran apt-get dist-upgrade (normal upgrade did not work) and wasn't disconnected in the process. A new host key was automatically generated.

Before this I first enabled password authentication in sshd to be sure I would be able to connect if my key was blacklisted. To do this set "PasswordAuthentication" to yes in /etc/ssh/sshd_config and restart with "sudo /etc/init.d/ssh restart". If you always use public key authentication I suggest to disable password authentication again after the upgrade.

[forek]

What other programs use OpenSSL to generate key pairs?


gnupg?
firefox?
thunderbird?
gnome-keyring?
pidgin-otr?
etc.?

[yaztromo]

Why does updating from the update-manager require a system reboot. Nowhere in the USN notices does a reboot get mentioned. I'm loathe to have to remotely reboot my server, even after regenerating my keys, but I'm wondering whether I should now...

[MountainX]

How do I add the new SSH key (for my server) to my /home/computeruser/.ssh/known_hosts file? When I open the file it doesn't appear to be intended to be human readable.

Thanks


$ ssh myuser@10.10.x.x
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
XX:XX:XX...
Please contact your system administrator.
Add correct host key in /home/myuser/.ssh/known_hosts to get rid of this message.
Offending key in /home/myuser/.ssh/known_hosts:1
RSA host key for 10.10.x.x has changed and you have requested strict checking.
Host key verification failed.

[p_quarles]

If you get rid of the old key, it should ask you if you want to keep the new key the next time you log in. The warning indicates that the problematic entry is the first one in the file, so if you have multiple keys, you can just delete the first one.

[sunbird]

How do I add the new SSH key (for my server) to my /home/computeruser/.ssh/known_hosts file? When I open the file it doesn't appear to be intended to be human readable.



ssh-keygen -R [HOSTNAME]


From man ssh-keygen:



-R hostname Removes all keys belonging to hostname from a known_hosts file.


And, then, as stated by p_quarles, it should ask you to verify the new key the next time you log in.

[whoop]

Just to inform everybody. I updated my machine with ssh server on it and it did all the work for me. I did not have to regenerate any keys (I did not use ssh-keygen or anything)... when I tried to log in I got:


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@

I removed .ssh directory from my client and tried again, it worked. I ran ssh-vulnkey on the dsa and rsa keys and they came back "not blacklisted"

So how come everybody is talking about this ssh-keygen stuff? I don't get it, please explain. I did not use it and I seem to be safe, and furthermore my keys where changed by an update.

[sunbird]

Just to inform everybody. I updated my machine with ssh server on it and it did all the work for me. I did not have to regenerate any keys (I did not use ssh-keygen or anything)

The regeneration instructions are for those who have ssh keys for use with openssh-client. The openssh-client update will not regenerate keys for you (or at least, when I updated yesterday it did not).

[schallstrom]

Does anyone know whether the pidgin-otr plugin uses the ssl lib to generate keys?

(Sorry if this was asked before, I searched the forums for "ssl otr" and got no relevant results)

[whoop]

The regeneration instructions are for those who have ssh keys for use with openssh-client. The openssh-client update will not regenerate keys for you (or at least, when I updated yesterday it did not).

Thanks for that clarification.
Didn't I regenerate those keys by deleting my .ssh directory on the machine with which I log in to the ssh service?

[ecmerkle]

Has anyone fixed the "duplicate template" problem yet?



Template #4 in /var/lib/dpkg/tmp.ci/templates has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.


I regenerated my own openssh-server keys before trying to upgrade, though I don't see how that could make the pre-install crash.

I haven't been able to upgrade openssh-server because I can't get around this duplicate template problem. I have two hardy boxes that upgraded fine, but my gutsy box gives me the duplicate template error. I've tried to apt-get upgrade, and I've also tried to apt-get purge followed by apt-get install.

I'd appreciate any tips.

[twisted_steel]

Does anyone know whether the pidgin-otr plugin uses the ssl lib to generate keys?

(Sorry if this was asked before, I searched the forums for "ssl otr" and got no relevant results)

It looks like libotr uses libgcrypt for all of the crypto stuff. I searched through the source code (http://www.cypherpunks.ca/otr/#downloads) for both libotr and pidgin-otr and didn't find 'ssl' anywhere that mattered. Libgcrypt (http://directory.fsf.org/project/libgcrypt/) looks like it is based off of GnuPG. So I think you are safe. Hopefully someone more qualified will step in :)

[exp(x)]

I have the free version of NX installed from here (http://www.nomachine.com/download-package.php?Prod_Id=6), and 'sudo ssh-vulnkey -a' gives me:


COMPROMISED: 1024 1d:78:60:c5:30:2d:1d:99:32:f9:9c:85:88:2d:9c:ce no-port-forwarding,no-agent-forwarding,command="/usr/NX/bin/nxnode"

How do I fix this? I completely removed my old packages and installed new ones, but that didn't work.

[Mr. Picklesworth]

Okay, I can sort of waddle my way around PGP (GPG?), but this one is way over my head.
I have an SSH key for Launchpad and bzr stuff. Running ssh-vulnkey, I have this (asterisks are mine)...
"COMPROMISED: **** **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:** /home/dmccall/.ssh/id_rsa.pub"

Security notice USN-612-2 tells me to "destroy the key". The first thing that springs to mind is to delete .ssh/id_rsa*, but I know with PGP that is a Very Bad Idea to delete my own private key because I remain at risk of it being compromised. The correct solution there is to create a revocation certificate, etc.
In this case, I am rather lost since I cannot find such an option and all my Googling takes me to convoluted security bulletins.

Help, please :)

[sinling]

The attack will take effective if you have authorized_keys being set? Or Openssh is vulnerable even you using password and id authentication?

Can someone please confirm this?

[p_quarles]

Okay, I can sort of waddle my way around PGP (GPG?), but this one is way over my head.
I have an SSH key for Launchpad and bzr stuff. Running ssh-vulnkey, I have this (asterisks are mine)...
"COMPROMISED: **** **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:** /home/dmccall/.ssh/id_rsa.pub"

Security notice USN-612-2 tells me to "destroy the key". The first thing that springs to mind is to delete .ssh/id_rsa*, but I know with PGP that is a Very Bad Idea to delete my own private key because I remain at risk of it being compromised. The correct solution there is to create a revocation certificate, etc.
In this case, I am rather lost since I cannot find such an option and all my Googling takes me to convoluted security bulletins.

Help, please :)
The difference here is that there are no centralized RSA keyservers as there are with PGP keys. The vulnerability of an SSH key extends only to the services for which you used the key -- in this case, Launchpad and Bazaar. Basically, the first thing you should do is generate new key pairs, and replace the compromised public keys with the newly-generated ones.

In other words, destroy both parts of any compromised keypairs. The public keys are -- in light of this problem -- worthless as a means of preventing others from authenticating into a server on which they are used.

[Cache22]

I have the free version of NX installed from here (http://www.nomachine.com/download-package.php?Prod_Id=6), and 'sudo ssh-vulnkey -a' gives me:


COMPROMISED: 1024 1d:78:60:c5:30:2d:1d:99:32:f9:9c:85:88:2d:9c:ce no-port-forwarding,no-agent-forwarding,command="/usr/NX/bin/nxnode"

How do I fix this? I completely removed my old packages and installed new ones, but that didn't work.


I had a similar problem getting the NX keys corrected, I found instructions on their web site a few minutes ago, and it appears to have fully fixed it.

http://www.nomachine.com/news-read.php?idnews=237

[crash369]

running ssh-vulnkey gives me this:


$ sudo ssh-vulnkey -a
Not blacklisted: 2048 <key> /etc/ssh/ssh_host_rsa_key.pub
Not blacklisted: 1024 <key> /etc/ssh/ssh_host_dsa_key.pub
COMPROMISED: 1024 <key> root@<host>
Not blacklisted: 1024 <key> /usr/NX/home/nx/.ssh/authorized_keys2


Where is this compromised key? There is only a known_hosts file in /root/.ssh/ and no key file.

[Cache22]

running ssh-vulnkey gives me this:


$ sudo ssh-vulnkey -a
Not blacklisted: 2048 <key> /etc/ssh/ssh_host_rsa_key.pub
Not blacklisted: 1024 <key> /etc/ssh/ssh_host_dsa_key.pub
COMPROMISED: 1024 <key> root@<host>
Not blacklisted: 1024 <key> /usr/NX/home/nx/.ssh/authorized_keys2


Where is this compromised key? There is only a known_hosts file in /root/.ssh/ and no key file.

Appears there is a service running as root using SSH, one example that could cause this is nx server, see my post above for the link to fix it if you have that installed. If that isn't it, start turning off some services and re-running the ssh-vulnkey command until the root@<host> line disappears, then you'll know the culprit.

[Mark_in_Hollywood]

From

ArsGeek

Severe OpenSSL vulnerability reported - affects many Debian based (i.e. Ubuntu) distros

http://www.arsgeek.com/?p=3970

1. Is this true?
2. How does a newbie go about dealing with this?

[rlsharpton]

Well, keys being "much more common" is a relative term, you're still dealing with a pretty random number.. however it is a vulnerablity. How do you deal with it? Same as most security issues, just keep your system updated with the patches. If you upgrade to the suggested openssl version then no problem, also I don't think.... don't quote me, but a default install of ubuntu doesn't have the openssl server enabled, so the user would have had to enable it and therefor should have at least the basic understanding of what it is doing. Just MHO.

[RequinB4]

From: http://ubuntuforums.org/announcement.php?f=326

If


ssh-vulnkey


Gives you errors, you probably don't have it installed :)

Also,

The problem can be corrected by upgrading your system to the following package versions:

Ubuntu 7.04: libssl0.9.8 0.9.8c-4ubuntu0.3
Ubuntu 7.10: libssl0.9.8 0.9.8e-5ubuntu3.2
Ubuntu 8.04 LTS: libssl0.9.8 0.9.8g-4ubuntu3.1

[Golem XIV]

1. Yes, it's true, it's been all over the web for the last couple of days

2. Just update your system through the normal means. The fix was released yesterday, so if you saw the little red icon in your Notification Area and you clicked on it and updated your system, there you go.

[dublued]

heh... i saw the articles come up on digg and reddit yesterday for the first time. a couple of hours later there was an update for it. if it was windows, it would've taken a few months or longer for an update.

[schallstrom]

1. Yes, it's true, it's been all over the web for the last couple of days

2. Just update your system through the normal means. The fix was released yesterday, so if you saw the little red icon in your Notification Area and you clicked on it and updated your system, there you go.

If you use key based authentication for logging into remote machines via ssh, just installing the updates is not enough since the update does not regenerate the keys of the users. If you want to be really sure you should run ssh-vulnkey and check for keys marked "COMPROMISED". If there are any, regenerate them with "ssh-keygen".

[eldragon]

it does actually regenerate the keys for the server (it does force you to). which is a start.

it doesnt talk about the user keys,

ive experienced a small glitch though.

the update tried to update 3 times already on both my computers. with or without the server installed. ive let it regenerate the keys once, since i dont feel like going through the process of updating my key_db each time.

is this a problem? a glitch? or was it updated 3 times for a reason?
ssh-vulnkey reports no blacklist for my keys, i asume this means im ok.


newbies shouldnt worry since they dont use the ssh features anyway. and if they do, then the regeneration of the server keys will point them to an error next time they try to login and force them to a solution that will eventually make them regenerate their keys.


cheers.

[jimv]

Oh Noez!!!!1!

[bodhi.zazen]

Thread merged. Feel free to check here or the announcement for security related issues.

[James79]

I'm running 6.10 server. It just fell out of scope for security updates 2 weeks ago and of course now this happens :(

According to http://www.ubuntu.com/usn/usn-612-2, only Feisty and above are affected.

Is this because my Edgy openssh doesn't have the vulnerability, or because it's simply no longer supported?

I pretty much have no choice but to upgrade to Hardy now don't I? :confused:

[p_quarles]

I'm running 6.10 server. It just fell out of scope for security updates 2 weeks ago and of course now this happens :(

According to http://www.ubuntu.com/usn/usn-612-2, only Feisty and above are affected.

Is this because my Edgy openssh doesn't have the vulnerability, or because it's simply no longer supported?

I pretty much have no choice but to upgrade to Hardy now don't I? :confused:
The package was uploaded to Debian Testing roughly a month before Ubuntu 6.10 came out. You should query the version of ssl on your machine to be sure, but I would say there's a very high likelihood that 6.10 contains the compromised number generator.

[James79]

The package was uploaded to Debian Testing roughly a month before Ubuntu 6.10 came out. You should query the version of ssl on your machine to be sure, but I would say there's a very high likelihood that 6.10 contains the compromised number generator.

Thanks for the quick response.

I ran dowkd.pl on /etc/ssh/*key* and it found no issues. I ran it on ~/.ssh/* and it told me I had 2 weak keys. Should I be worried?

How do I get my ssl version number?

[p_quarles]

How do I get my ssl version number?
In a terminal:

openssl version
Btw, nearly every Linux program has a "version" option that will print the release info in the shell. Most of them use "-v" or "--version." This is true of graphical applications as well as shell applications.

[James79]

Ok, well it reports OpenSSL 0.9.8b 04 May 2006, and according to this (http://lists.debian.org/debian-security-announce/2008/msg00152.html), it affects 0.9.8c-1 and newer. So I guess that means I'm safe?

[p_quarles]

Ok, well it reports OpenSSL 0.9.8b 04 May 2006, and according to this (http://lists.debian.org/debian-security-announce/2008/msg00152.html), it affects 0.9.8c-1 and newer. So I guess that means I'm safe?
That's my understanding as well. Since prior versions did not contain the Debian modification which led to this vulnerability, it should contain a correctly working pseudo-random number generating algorithm.

[SEMW]

For a bit of on-topic light relief, the latest xkcd (http://xkcd.com):


http://imgs.xkcd.com/comics/security_holes.png

[plun]

Well....:(


http://sslguru.org/?s=debian&x=0&y=0


This can be a disaster....

EDIT

Internet Storm Center
http://isc.sans.org/diary.html?storyid=4420

Computerworld
http://computerworld.com/action/article.do?command=viewArticleBasic&articleId=9085980

INFOCon Yellow: update your Debian generated keys/certs ASAP

http://isc.sans.org/diary.html?storyid=4421

[Bad Penguin]

Some CAs will allow you to revoke your certificates and reissue them without charge. You will need to look at the specific contract/terms for your CA, which should be available somewhere on their website or by contacting support.

Just an FYI, verisign charges $100 to revoke and replace an existing cert. This bug has cost me $300 so far ;(

[jhansonxi]

pam mount (libpam-mount) is indirectly affected by this vulnerability. When used with LUKS/dm-crypt to auto-mount encrypted home file systems it uses an OpenSSL encrypted copy of the user's password to unlock it.

[twisted_steel]

Just an FYI, verisign charges $100 to revoke and replace an existing cert. This bug has cost me $300 so far ;(

From the looks of their blog, they should not have charged you. If they already have, I'd contact them to get it squared away.

https://blogs.verisign.com/ssl-blog/debian/

[Nephiel]

Any ideas about how to check for bad OpenVPN keys? dowkd.pl doesn't seem to be able to read the key/pem/csr/crt/whatever files.

I'm also looking for that. Is there a way to check if a SSL certificate has been signed using a version of openSSL affected by the vulnerability?

[Conficio]

EDIT bodhi.zazen: Adding information so that people do not need to read the entire thread for some basic information.

\[SSH instructions\]

bodhi.zazen
Bodi,
thanks for putting this vital info upfront. However your post gives the impression that ssh is the only application that is vulnerable. That is not the case, there is ntp, imap, pop, smtp, tls, certificate authorities for pgp, openVPN, web servers with SSL, and more. Basically, anybody that used an SSL key generated.

More info can be found at http://www.debian.org/security/key-rollover/

Also your solution (if I understand it right) upgrades the release of Ubuntu to 8.04. That is neither necessary nor would I advise to handle this whole bag of new issues.

K<o>

[bodhi.zazen]

Thanks for the info I will post your link as well.

apt-get dist-upgrade will not upgrade to 8.04 unless you change your repos to hardy.

apt-get upgrade will not upgrade to 8.04 unless you change your repos to hardy, but apt-get upgrade (and synaptic) often shows the packages as on "hold" necessitating the apt-get dist-upgrade to proceed with installation. I have updated two 7.10 server with those commands without upgrading either to 8.04.

[glotz]

HALP?

I must say I'm pretty dissappointed and ashamed by the handling of this whole issue. Still I don't know if I am affected and if yes, how to actually mend it. I have read the ubuntu security notices over and over again.

(It's pretty funny because I've been using computers more than 20 years and generally feel pretty much at home with them. I can only imagine what the average d00d understands about this issue. Safe as the Titanic. I guess 2008 isn't the year of the linux desktop...)

[p_quarles]

HALP?

I must say I'm pretty dissappointed and ashamed by the handling of this whole issue.
I thought the handling of the issue was pretty remarkable. As big and embarrassing a mess-up as this was, the Debian security folks were very up front about reporting it and getting the information out to everyone as quickly as possible.

It's unfortunate that it happened in the first place, yes, but this is why it's said that the only safe computer is the one that's not plugged in.

[glotz]

Too bad most users might still be vulnerable. :(

[kevdog]

Is this random number generator vulnerability an issue with OpenSSH specifically (effecting all particular versions of OpenSSH no matter the platform), or a Debian/Ubuntu specific vulnerability?

[Mr. Picklesworth]

It's Debian specific; some maniac decided it made sense to mess around with code being imported into Debian even though it worked perfectly fine, without confirming the changes upstream ;)

It's my understanding that, after the updates, you can run ssh-vulnkey. If the results are all positive, you can go ahead and forget about the whole thing.

[kevdog]

Any background on this disaster?? I took a long time for this exploit to be discover. Egdy was released well over a year ago, and the exploit has only been discovered now? How was it discovered?

[beercz]

Despite checking I have all the latest updates installed and generating new keys, I can no longer ssh from my debian (etch) box to my ubuntu (hardy) laptop using keys.

Why not? And what can I do to fix this?

[aulio]

This page has some additional info on steps to check for vulnerable ssh keys and regenerate them.

http://www.ubuntu.com/usn/usn-612-2

I followed the instructions but couldn't update the openssh:


$ sudo apt-get install openssh-client=1:4.3p2-8ubuntu1.3
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '1:4.3p2-8ubuntu1.3' for 'openssh-client' was not found


How to update a newer version?

[jwkungfu]

Hi all,
What should I do about this threat?
Wait until there is a patch from Ubuntu?
Or should do something ASAP?

:confused:

[Monicker]

I followed the instructions but couldn't update the openssh:


$ sudo apt-get install openssh-client=1:4.3p2-8ubuntu1.3
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '1:4.3p2-8ubuntu1.3' for 'openssh-client' was not found


How to update a newer version?


The problem is not with the openssh client. Its with the openssh-server package. Do you have openssh-server installed? The update has been out for a little while now, so you should have already been prompted to upgrade if you do indeed have that server package.

[Monicker]

Hi all,
What should I do about this threat?
Wait until there is a patch from Ubuntu?
Or should do something ASAP?

:confused:

The update has been availabe for a while now. If you are running an ssh server, the update will automatically regenerate the server keys. Any user specific keys will need to be regenerated. Keys for certain applications may also be need to be regenerated.

Please read the links given in this thread. They point to all the information you need.

[rapha]

Hi,

sorry if this has been answered already - a forum search for "dapper openssl vulnerability" didn't bring anything up: is this problem solved in the latest packages for Dapper already? At least I don't have an ssh-vulnkey command on my Dapper servers...

Thanks,
Raphael

[Monicker]

Hi,

sorry if this has been answered already - a forum search for "dapper openssl vulnerability" didn't bring anything up: is this problem solved in the latest packages for Dapper already? At least I don't have an ssh-vulnkey command on my Dapper servers...

Thanks,
Raphael

Dapper did not have an vulnerable version of openssh/openssl. The only issue would be if you had imported keys from a later vulnerable version into Dapper.

[/etc/init.d/]

No you're not, mate. This is related to SSL encryption keys you have generated youself. If your CA has suffered in any way because of this problem then they should reissue your SSL certs free.
No, this is not entirely correct. When you obtain an SSL certificate from a commercial CA, your system will generate a certificate request, which you then send to the CA to obtain your SSL certificate. It is at the point which you generate the certificate request, you decide what private key your SSL certificate will have (so that you don't need to disclose it to the CA). If you used a system with a vulnerable version of OpenSSL, this means your SSL certificate now has a weak key -- but it is not the fault of the CA.

[Endolith]

You can then run :


sudo ssh-vulnkey -aIf you see "Not Blacklisted: xxx.yyy.zzz /path/to/key" you are ok.

And if I see that root@hostname is "COMPROMISED", what do I do?


The update will regenerate your server keys

I updated a few days ago but it has apparently not regenerated all of them?

[aulio]

The problem is not with the openssh client. Its with the openssh-server package. Do you have openssh-server installed? The update has been out for a little while now, so you should have already been prompted to upgrade if you do indeed have that server package.

Yes, I have the openssh-server installed, but I haven't been prompted to upgrade. Manual upgrade gives the same error:


$ sudo apt-get install openssh-server=1:4.3p2-8ubuntu1.3
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '1:4.3p2-8ubuntu1.3' for 'openssh-server' was not found


Do I miss a repository or something? I'm running on kubuntu 7.04.

[sinling]

Yes, I have the openssh-server installed, but I haven't been prompted to upgrade. Manual upgrade gives the same error:


$ sudo apt-get install openssh-server=1:4.3p2-8ubuntu1.3
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '1:4.3p2-8ubuntu1.3' for 'openssh-server' was not found


Do I miss a repository or something? I'm running on kubuntu 7.04.


sudo apt-get install openssh-server

[aulio]

sudo apt-get install openssh-server

Resulting: openssh-server is already the newest version. In my system it is

1:4.3p2-8ubuntu1

However, the instructions on http://www.ubuntu.com/usn/usn-612-2 tells me to upgrade to version

1:4.3p2-8ubuntu1.3

Does anyone have version 1:4.3p2-8ubuntu1.3 on his/her computer?

[gtdaqua]

openssh-server and openssh-client have been 'kept back' in apt-get upgrades. I think Ubuntu Community is still working on a permanent patch which will simply re-generate RSA and DSA keys. However, this applies only to 7.10 servers and not 8.04.

[jwkungfu]

The update has been availabe for a while now. If you are running an ssh server, the update will automatically regenerate the server keys. Any user specific keys will need to be regenerated. Keys for certain applications may also be need to be regenerated.

Please read the links given in this thread. They point to all the information you need.

Thanks for the reply!
A) How do I check if I am running a ssh server?
B) What is and how do I regenerate user specific keys (and the keys for "certain" applications (which one's?)
D) There seems to be a lot of terminal instructions and links in this thread?!
E) Is there a step by step procedure that I could follow to iron out this problem/concern....?
Cheers!
:)

[lucho64]

Thanks for the reply!
A) How do I check if I am running a ssh server?
B) What is and how do I regenerate user specific keys (and the keys for "certain" applications (which one's?)
D) There seems to be a lot of terminal instructions and links in this thread?!
E) Is there a step by step procedure that I could follow to iron out this problem/concern....?
Cheers!
:)
A) Go to System->Administration->Services look for "Remote shell server (ssh)" in the list of services. Chances are you don't have it even installed, so it won't appear. If it does check if it is checked.
B) Again, if you don't run ssh or have a ssl enabled web SERVER (not talking about firefox here), chances are you have little to worry. Look here (http://wiki.debian.org/SSLkeys) for a list.
C and D) first check A and B ;-)

[lucho64]

And if I see that root@hostname is "COMPROMISED", what do I do?



I updated a few days ago but it has apparently not regenerated all of them?
That is a key that you have imported from other system. You can't change it in the system you are looking the file at (unless, of course, it is the same). Look for that key on the ~/.ssh/authorized_keys and remove it using a text editor.

[Endolith]

I get


COMPROMISED: 1024 <key fingerprint> root@hostname

How do I regenerate this?

[jwkungfu]

A) Go to System->Administration->Services look for "Remote shell server (ssh)" in the list of services. Chances are you don't have it even installed, so it won't appear. If it does check if it is checked.
B) Again, if you don't run ssh or have a ssl enabled web SERVER (not talking about firefox here), chances are you have little to worry. Look here (http://wiki.debian.org/SSLkeys) for a list.
C and D) first check A and B ;-)

Many thanks indeed!!
:KS

I did as you said and nothing came up titled ssl webserver (or even close), so I feel at ease now...

Apart from the total confusion as to what all this is about....?!
As you can guess I'm not the most computer savvy person...

How do I check for what I am using instead of this ssl webserver?
As I was looking at the list (after system/administration/services) I couldn't see anything else that mention the web/servers/etc.....?

I am very interested in computer security, however there seems to be very little in the way 'overviews' concerning this topic...
I'm looking for some good graphical diagrams giving me a good overview of how computers/security/virus' etc...
And I don't mean... box (a) and box (b) with an arrow....
I need more info than that... I have studied electronics and some computing (microprocessors, binary, ASCII code, very old and very basic I know).

Perhaps I'm asking too much...?
I doubt that I am though?

:confused:

:popcorn:

[Bad Penguin]

From the looks of their blog, they should not have charged you. If they already have, I'd contact them to get it squared away.

https://blogs.verisign.com/ssl-blog/debian/

I just got the email from verisign today announcing revoke and replacements cost $0 until June 30th. Hopefully they will credit back what they charged earlier...

[Bad Penguin]

Does anyone know if the installation media for feisty/hardy includes the bad openssl/openssh and generates vulnerable keys when installing from CD without network access?

[lucho64]

Many thanks indeed!!
:KS

You are welcome


I did as you said and nothing came up titled ssl webserver (or even close), so I feel at ease now...

Apart from the total confusion as to what all this is about....?!
As you can guess I'm not the most computer savvy person...

How do I check for what I am using instead of this ssl webserver?
As I was looking at the list (after system/administration/services) I couldn't see anything else that mention the web/servers/etc.....?

Nothing. Most users don't need a webserver. Apache2 is the default web server, but it is not installed by default, and you didn't see it in the services, so you should be fine. This whole mess is more about servers and people that administer them. Regular users have little to worry about.

[lucho64]

I get

Quote:
COMPROMISED: 1024 <key fingerprint> root@hostname
How do I regenerate this?

log in as root on hostname, delete the old key in .ssh/id_dsa or id_rsa and run ssh-keygen

[Endolith]

log in as root on hostname

I thought you couldn't log in as root on Ubuntu.


delete the old key in .ssh/id_dsa or id_rsa

I used sudo to delete everything in /root/.ssh, but it still lists "COMPROMISED" for root


run ssh-keygen

Where do I tell it to put the key? What do I use for a passphrase?

[lucho64]

I thought you couldn't log in as root on Ubuntu.
well, you always can do sudo su root, but you are right, you shouldn't need to.


I used sudo to delete everything in /root/.ssh, but it still lists "COMPROMISED" for root
Hmmm... lets see, maybe I didn't understand you. There are two computers, say A and B. You generated the key for root on A and imported the public key to /home/user1/.ssh/authorized_keys (maybe root as well) on B sometime ago. You used the key to log in from A into B, therefore the /home/user1/.ssh/known_hosts got the host A public key added. Now you discovered that A had the broken ssl libs and therefore the keys are no good. So you updated your openssl libs with apt-get (or equivalent) on A and B and deleted the public key you imported to B (on the authorized_keys file) and the private key you had generated in A (/root/.ssh/rsa_id or .ssh/dsa_id). On B you also deleted the host from the known_hosts file (ssh-keygen -R hostname_A would do it). The libs update should have regenerated the host keys on A (and B if the were compromised)
That should take care of all the ssh keys.

Where do I tell it to put the key? What do I use for a passphrase?
the default location, .ssh/id_dsa. Use anything like a password for your passphrase, the longer and more random looking the better.

[yaztromo]

I thought you couldn't log in as root on Ubuntu

It's disabled by default but it can be quickly enabled.

[IntuitiveNipple]

I used sudo to delete everything in /root/.ssh, but it still lists "COMPROMISED" for root

You're suffering from one of the deficiencies of the ssh-vulnkey tool - when it checks all keys it doesn't tell you which file the key is in, so you need to track it down manually - not exactly administrator friendly, let alone user-friendly!

In your case the warning will be about the localhost's SSH protocol type 1 compatibility key, usually stored in /etc/ssh/ssh_host_key{,.pub}, which is keyed to root@hostname.

To be sure do:


$ sudo ssh-vulnkey /etc/ssh/ssh_host_key.pub

The reported fingerprint should match the one you're seeing.

To regenerate it, use ssh-keygen -t rsa1 ...

[IntuitiveNipple]

Something to be aware of if you manage or use a system that doesn't have the affected openssl package installed - all non-Debian based servers may also be affected. It means this potentially impacts not just servers with Debian-based installtions but all Linux distributions and also Windows, Solaris, BSD, Mac, etc.

If that non-Debian system provides SSH-controlled access or hosts server processes that use SSL/TLS certificates (web servers, mail, etc.) then it is possible users have uploaded to the server certificates and/or keys generated on a system that was a subject of this bug.

That means that in practice all servers that allow users or administrators to install externally generated certificates and keys need to check those keys no matter what operating system the host has installed.

For example:

User SSH keys generated by the user on another system
TLS/SSL certificates for web/mail (if CSR generated on an external system)
OpenVPN certificates (if generated on external system)
Stunnel aggregated service handler (if CSR generated on external system)

[Endolith]

well, you always can do sudo su root, but you are right, you shouldn't need to.

I should be able to do it all with just sudo, right?


There are two computers, say A and B.

I have two computers, yes, but I don't think that's relevant. Both are running Ubuntu and both have been upgraded. On one, the vulnkey program says all are fine. On the other computer (let's call it "george"), it says "COMPROMISED: 1024 <key fingerprint> root@george" It refers to itself, not to my other computer.

I don't think I did anything that imported anything from one computer to another. I use SSH and NX to control one from the other, but that's it.


the default location, .ssh/id_dsa.

Default location in my case is /root/.ssh/id_rsa


Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.



Use anything like a password for your passphrase, the longer and more random looking the better.

I wish I understood the purpose of all this.


To be sure do:

$ sudo ssh-vulnkey /etc/ssh/ssh_host_key.pub

The reported fingerprint should match the one you're seeing.

It does not:


sudo ssh-vulnkey ssh_host_rsa_key.pub
Not blacklisted: 2048 <fingerprint> root@george
sudo ssh-vulnkey ssh_host_dsa_key.pub
Not blacklisted: 1024 <fingerprint> root@george

[Cache22]

I don't think I did anything that imported anything from one computer to another. I use SSH and NX to control one from the other, but that's it.

The NX server process (running as root@george) is the source of the problem. The NX server uses OpenSSL generated keys so it also is affected by this vulnerability ... here are instructions on fixing it:

http://www.nomachine.com/news-read.php?idnews=237

[Endolith]

The NX server process (running as root@george) is the source of the problem. The NX server uses OpenSSL generated keys so it also is affected by this vulnerability ... here are instructions on fixing it:

http://www.nomachine.com/news-read.php?idnews=237

I followed those directions but root@george still shows up as the old COMPROMISED key.

[Irihapeti]

Sorry, people, I'm a bit confused by all of this. I've just been installing the updates as they became available. I didn't realise that I had to do anything else.

I don't run a server, but I do have a couple of POP3/SMTP email accounts with my ISP that connect using SSL. I've run ssl-vulnkey -a and I get absolutely NO output. Does that mean I have no keys on my system? And how would I check that?

[movieman]

I don't run a server, but I do have a couple of POP3/SMTP email accounts with my ISP that connect using SSL. I've run ssl-vulnkey -a and I get absolutely NO output. Does that mean I have no keys on my system? And how would I check that?

I don't believe there's any problem if you're just connecting to a remote server using SSL, since the remote server has its own SSL key (though if it's a debian/ubuntu system it could still be a weak one) and web browsers should use their own random number generators for session keys.

The problem is with weak keys that you generate on a debian/ubuntu system, or with keys that other users generated on one and uploaded to your system. If you haven't generated any keys and haven't had any remote users upload them, I believe you should be fine.

[Irihapeti]

Thanks for your clarification. I use Thunderbird for email and there don't appear to be any certificates installed other than the built-in tokens. Ditto for Firefox. As for the ISPs, the servers in question are running FreeBSD and Solaris 8, according to Netcraft; thus there shouldn't be any problems at the ISP end.

[Unix_Slayer]

The now-patched vulnerability, reported by the Debian Project May 13th, allows a hacker to use brute-force guessing attacks to decipher keys in SSH [Secure Shell], DNS-SEC (Domain Name System Security Extensions), Open VPN and X.509 certificates, as well as session keys used in SSL/TLS (Secure Sockets Layer/Transport Layer Security) connections.

The vulnerability has existed since September 2006, and officials with the Debian Project recommend that all cryptographic key material generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems be considered compromised and re-created from scratch.

It is a big deal to patch and then generate keys--that is why they always say look for FIPS [Federal Information Processing Standard] 140-tested crypto, which would test things like the random number generator.

Since the flaw was announced, CA's have stepped up to offer free replacement of SSL certificates for enterprises affected by the situation. However, officials at VeriSign and Comodo Group say there has not been a groundswell of enterprises taking them up on the offers. There is also the fact that Debian is not the most popular Linux distribution. Still, potentially replacing two years' worth of keys could represent a formidable task for enterprises that are affected.

In the event that an enterprise did have to replace a large number of certificates, the main difficulty it would face would simply be the logistics of turning over that many certificates and getting all the right parts in all the right places. However, enterprises are capable of flipping their entire certificate base in less than a month if it is worth their while.

Businesses are still investigating the impact of the vulnerability, and it may take a while for CA's to see an outpouring of requests for replacement certificates. Even those companies who do need the update and are aware of it might not have been able to reissue their certificates yet. They have to install the Debian patch, satisfy themselves that it's working correctly, figure out which [certificates] need replacement, revoke them and replace them with the new certificates. That's a lot of steps, and the part where they touch the CA is not until the end of the list.

[Endolith]

I followed those directions but root@george still shows up as the old COMPROMISED key.

I've completely removed/uninstalled NX, removed /usr/NX/etc/keys, removed /root/.ssh and it still shows this COMPROMISED key. :mad:

Can anyone help?

[lonetree]

There's a problem in Debian's version of OpenSSL, with a predictable random number generator. The announcement is here: http://lists.debian.org/debian-security-announce/2008/msg00152.html . The problem makes key material, such as OpenVPN keys and SSH public-key authentication keys, vulnerable, and you need to replace the keys generated with old versions.

Does this problem exist on Ubuntu too?


EDIT bodhi.zazen: Adding information so that people do not need to read the entire thread for some basic information.

1. There are a few tools to check your ssh keys, most are affected so be warned.

ssh-vulnkey is included in the update of openssh-server.

On a Debian/Ubuntu box with ssh server installed :

sudo apt-get update && sudo apt-get dist-upgradeapt-get dist-upgrade will install the packages (apt-get upgrade *may* show the packages are held).

You can then run :


sudo ssh-vulnkey -aIf you see "Not Blacklisted: xxx.yyy.zzz /path/to/key" you are ok.

The update will regenerate your server keys

2. If you are updating ssh keys on a remote server, be careful. When the ssh keys are regenerated *some* users have lost the ssh connection. If you use keys to ssh into the server, first make sure you have alternate access to the server (temporarily allow logins with password ?) until new keys are in place.

EDIT 2 bodhi.zazen: for clarification :

This vulnerability affects more then ssh, ntp, imap, pop, smtp, tls, certificate authorities for pgp, openVPN, web servers with SSL, and more. Basically, anybody that used an SSL key generated.

More info can be found at http://www.debian.org/security/key-rollover/

~ Thanks Conficio (http://ubuntuforums.org/member.php?find=lastposter&t=793517) for the clarification and link

bodhi.zazen

I'm confused, does that mean that I have to regenerate everything? CA, VPN-Server, and keys for server and clients?

regards,