Last modified: 2013-04-24 18:31:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T34163, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32163 - Please list the fingerprint(s) of the server
Please list the fingerprint(s) of the server
Status: NEW
Product: Wikimedia Labs
Classification: Unclassified
General (Other open bugs)
unspecified
All All
: Normal normal
: ---
Assigned To: Ryan Lane
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-02 23:31 UTC by T. Gries
Modified: 2013-04-24 18:31 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description T. Gries 2011-11-02 23:31:32 UTC
Please list the fingerprint(s) of the server.

cd /etc/ssh
ssh-keygen -lf ssh_host_rsa-key.pub

or the like.

See http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/56378
Comment 1 Platonides 2011-11-02 23:39:39 UTC
The fingerprints of the instances are dynamic (would change on each recreation). 
Extension:OpenStackManager can show them in the 'get output', but you can't view that page unless you are admin.
Comment 2 Ryan Lane 2011-11-02 23:57:54 UTC
I'll try to think of some way of listing this info. There are definitely some dirty, hackish ways of doing this. I may just put a cron on one system that pulls the keys and adds them to the instance's wiki page.

I may also be able to do this via OpenStackManager, by adding a job to the job queue that tries to ssh to the host, pulling the key and then updating the wiki page with the fingerprint.
Comment 3 Ryan Lane 2011-11-03 00:00:31 UTC
http://www.php.net/manual/en/function.ssh2-fingerprint.php

^^ that would do perfectly.
Comment 4 T. Gries 2011-11-04 07:41:10 UTC
(In reply to comment #1)
> The fingerprints of the instances are dynamic (would change on each
> recreation). 
I understand.

Perhaps a solution, and increasing security: each newly created instance must get a new name, or serial number, or hash ?
Comment 5 Ryan Lane 2011-11-04 17:58:57 UTC
(In reply to comment #4)
> (In reply to comment #1)
> > The fingerprints of the instances are dynamic (would change on each
> > recreation). 
> I understand.
> 
> Perhaps a solution, and increasing security: each newly created instance must
> get a new name, or serial number, or hash ?

It does. Every new one has a unique instance name, and is a newly installed OS, so also has a new ssh key.

That is what *causes* the problem, though. It's not a solution. I listed a solution above.
Comment 6 Thehelpfulone 2012-06-13 15:39:07 UTC
Moving out of the Wikimedia product into the already existing Wikimedia Labs product, I'm going to remove the Labs component from the Wikimedia product.
Comment 7 Damian Z 2012-10-11 09:22:42 UTC
Now we have salt running on most the instances we could write a module for grabbing this data (possibly after the api is done).

I'd really like to push SSHFP records into DNS, apparently the current PDNS ldap schema can't handle that though :(
Comment 8 Ryan Lane 2012-10-11 20:13:15 UTC
I'd like salt to fire an event when the instance is finished building. It could include the fingerprint along with the event message.
Comment 9 Andre Klapper 2013-04-24 12:05:39 UTC
Is this really high priority (as it's been since November 2011), or shall this be decreased to low or normal priority?
Comment 10 Ryan Lane 2013-04-24 18:31:30 UTC
No. Normal priority is fine.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links