Monthly Archives: June 2015

Cinder Authentication Failures

Leave a reply

I’ve been building a new OpenStack lab (Kilo) manually to get a feel for the changes – last time I did much with OpenStack it was on Grizzly. Most of the components are broadly similar, with improvements generally speaking, but getting Cinder proved to be a lot more work then anticipated.

Basically it just wouldn’t work – due to authentication failures. I checked and rechecked the passwords, followed the guide to the letter, and nothing:

2015-06-29 17:03:04.394 4639 DEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.7/dist-packages/keystone/middleware/core.py:229
2015-06-29 17:03:04.395 4639 INFO keystone.common.wsgi [-] GET /?
2015-06-29 17:03:04.396 4639 INFO eventlet.wsgi.server [-] 10.68.3.29 - - [29/Jun/2015 17:03:04] "GET /v2.0/ HTTP/1.1" 200 579 0.002657
2015-06-29 17:03:04.399 4639 DEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.7/dist-packages/keystone/middleware/core.py:229
2015-06-29 17:03:04.400 4639 INFO keystone.common.wsgi [-] POST /tokens?
2015-06-29 17:03:04.507 4639 INFO eventlet.wsgi.server [-] 10.68.3.29 - - [29/Jun/2015 17:03:04] "POST /v2.0/tokens HTTP/1.1" 200 2764 0.108216
2015-06-29 17:03:04.513 4634 DEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.7/dist-packages/keystone/middleware/core.py:229
2015-06-29 17:03:04.515 4634 INFO keystone.common.wsgi [-] POST /tokens?
2015-06-29 17:03:04.523 4634 WARNING keystone.common.wsgi [-] Authorization failed. Invalid user / password (Disable debug mode to suppress these details.) (Disable debug mode to suppress these details.) from 10.68.3.29

Eventually, more in hope then expectation, I used the keystone_authtoken config block from glance, rather then the config guide, and we were in business – very frustrating day but got there in the end.

[keystone_authtoken]
identity_uri = http://openstack-mgmt:35357
admin_tenant_name = Services
admin_user = cinder
admin_password = notcinder

If I had the auth_uri parameter configured it just wouldn’t work, and I’m beyond caring why at this point!

Raspberry Pi’s Hardware Random Number Generator

Leave a reply

Given all the OpenSSH/Diffie-Hellman issues seen lately, I was regenerating all my certs to  longer ones, which on the RPi is a bit of a job. Afterwards I discovered that the RPi actually has a hardware RNG. To make use if this awesome tool:

Install the kernel module

sudo modprobe bcm2708-rng

Make sure it is always available by adding it to /etc/modules

bcm2708-rng

Install some cool RNG tools.

sudo apt-get install rng-tools

The hardware device should now be available to root as /dev/hwrng

Testing how random is random

We have the basic rngtest available to use courtesy of rng-tools – there are far harsher ones e.g. dieharder but they take a while to run. Testing for true randomness is quite hard – you need a vast number of tests, and even then we would expect a few failed tests for truly random input.

In this case I had 2 failed tests out of 1000, which is reasonable.

sudo cat /dev/hwrng | rngtest -c 1000
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=35.153; avg=859.670; max=1627604.167)Kibits/s
rngtest: FIPS tests speed: (min=401.935; avg=3276.347; max=7317.816)Kibits/s
rngtest: Program run time: 29046630 microseconds

In comparison with the linux /dev/random number generator it’s not bad at all. The linux /dev/random passed all the tests but took far longer – look at the difference between the input channel speed 233.256kibits/s vs. 859.670kibits/s.

sudo cat /dev/random | rngtest -c 1000
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=97.034; avg=233.256; max=428.947)Kibits/s
rngtest: FIPS tests speed: (min=836.349; avg=5252.286; max=7274.209)Kibits/s
rngtest: Program run time: 87562313 microseconds

Persistent Reverse-SSH Tunnels with autossh and screen

1 Reply

I’ve been working to manage my place remotely as I tend to have irregular hours. As a pilot I put in a Raspberry Pi and got a Belkin WeMo Switch. I had two problems with this setup;

  1. The internet connection is NAT-ed
  2. The Belkin cloud-y manager thing doesn’t seem to work (neither does IFTTT)

My solution was to use the RPi to manage the WeMo, and to have a reverse-ssh tunnel between the RPi and my public server.

  1. Ensure that passwordless SSH is working between the RPi and the server – plenty of guides online about how to do this.
  2. Open a screen session
  3. Use autossh to open and maintain the tunnel
$ autossh -M 65500 -o ServerAliveInterval=20 -R 11141:localhost:22 [email protected]

Autossh will use ports 65500 and 65501 to send echo data over and back between server and host, and opening an ssh session on the public server to local port 11141 will tunnel back to the SSH port on the RPi

ssh -p 11141 [email protected]

While this works fine, there is a potential issue – if the RPi is rebooted/looses power for any reason, the tunnel will be gone so we need to automate the setup so that it will be fired up upon boot – we will use a crontab entry for this:

@reboot /usr/bin/screen -S reverse-ssh-tunnel -d -m autossh -M 65500 -i /home/pi/.ssh/id_rsa -o "ServerAliveInterval 20" -o "ServerAliveCountMax 3" -R 11141:localhost:22 [email protected]

This cron entry will open a screen on reboot with “reverse-ssh-tunnel” as the title, and issue the autossh command. Reboot the RPi to test and you should be good to go.

Simples 🙂