Is there a possibility to enable 2 factor authentication (or 2 step verification a-la Google terminology) for Google compute engine?
I'm interested in protecting my VMs, cloud storage and the developers console.
I've tried using the Google Authenticator (libapm) referring to this article Securing SSH with two factor authentication using Google Authenticator on a VM but it didn't succeed (I managed to login with the gcloud compute shell with no additional code).
[Jan 12th]
Some updates:
Google developer console works perfectly. Thanks.
For 2-step verification with the compute-engine SSH access, I retried everything all over again. Followed the instructions mentioned in the links provided, and did the following:
I created a new Google-Cloud project.
I used 2 different OS instances - Debian 8.2 and Ubuntu 15.10.
All of these tests failed - there was no prompt for a verification code.
I looked around in the Google compute-engine documentation, and they mention explicitly they support only certificate authentication (rather than username/password), so I cannot verify whether this is the root cause.
Is there anyone using 2-step verification with Google compute-engine?
Thanks
At last - a solution (thanks for Google cloud support).
A couple of updates on top of the document I have referred to:
Apart of adding a line to /etc/pam.d/sshd, one should also comment out the #include common-auth line. So it should be something like:
auth required pam_google_authenticator.so # from the original instructions
# #include common-auth # commenting out is new...
Apart of changing the ChallengeResponseAuthentication property in /etc/ssh/sshd_config, one should also add AuthenticationMethods publickey,keyboard-interactive in the following line:
ChallengeResponseAuthentication yes # from the original instructions
AuthenticationMethods publickey,keyboard-interactive # this is new...
Of course, this is on top of the regular instructions of installing libpam-google-authenticator, changing the sshd and sshd_config (as mentioned above), restarting the ssh/sshd service, and setting up the google-authenticator for the account.
Finally, a few more points:
Consider this carefully - from restarting the ssh/sshd account, no one can login without proper 2FA. So make sure anyone who should have ssh access - configured it properly.
I'm contemplating whether this is the proper solution for us, as it requires setup the VMs (each VM separately), and manual setting up the authenticator per each account and each VM manually. Not sure how scalable is this alternative. I would appreciate your thoughts...
Last but not least - the setup of libpam-google-authenticator may be simplified by using apt-get, no need for manually installing all dependencies and building it. Worked for me by running:
sudo apt-get install libpam-google-authenticator
Good Luck!
Related
I'm currently trying to develop a cloud in my pc using virtual box. The idea is that I have 2 virtual machines, one which devstack installed (all in one) and the other with osm mano. Right now both have everything installed. Hence, I can log in to mano via user and password 'admin' as well as to devstack.
Current properties:
VM1 (devstack): IP (enp0s8) -> 192.168.56.101
Login to 192.168.56.101 -> correct
VM2 (mano): IP (enp0s8) -> 192.168.56.105
Login to 192.168.56.105 -> correct
As some of you may guess, I have 2 network interfaces in every vm, the first one being NAT (enp0s3 with 10.0.2.15 IP) and the second one being Host Only (192.168.56.x according to virtual box).
Needless to say, I can ping from one virtual machine to another without any problem.
Now, in the past I've being using devstack (ubuntu 18.04) in order to play with it a little bit, learn how to deploy instances, create groups and so on. Indeed, I developed a topology with an instance as a router and nagios as the monitoring tool system. It worked and I learnt a lot!
Anyway, what I want in this case is starting from scratch (scratch meaning having downloaded mano and devstack but without going further). So here I am, trying to integrate OSM with Devstack, making use of osm-vim command as it is:
osm vim-create --name openstack-site --user admin --password my_openstack_password --auth_url http://192.168.56.101:5000/v3 --tenant admin --account_type openstack
In this case, my openrc file (downloaded from horizon) resulted in my auth_url being:
export OS_AUTH_URL=http://192.168.56.101:5000/v3
What I'm trying to get my head into is how it's possible that this doesn't work, as whenever I log-in to mano web interface (after osm-vim command) I go to VIM accounts and operational state equals to "error".
Any kind of help would be much appreciated, as I've being struggling for a week now.
Thanks in advance!
I had the same problem. At the beginning I thought It was a network problem, but finally I found out It was due to a SSL problem. The most easy solution is to put a specific flag to avoid the SSL verification until the developers fix it. "--config '{insecure: True}'"
I also encountered this problem when I finished installing OSM-10 and OpenStack-Ussuri for Ubuntu18.04 some days ago. I solved this problem by change the url "--auth_url http//:192.168.23.18:5000/v3" to "-- auth_url http//:controller:5000/v3" and put "192.168.23.18 controller" in the ro container "/etc/hosts". The "controller" here is the host name where you install your openstack and which is used is your keystone authentication urls. Maybe you also have solved this problem but this problem is so troublesome and I hope more people do not be annoyed at this~
I have an old Debian Compute Engine instance (created and running since December 2013) and got an email warning about the turndown of Legacy GCE and GKE metadata server endpoints (more details at https://cloud.google.com/compute/docs/migrating-to-v1-metadata-server).
I followed the directions for locating the process and found that the requests were coming from /usr/share/google/google_daemon/manage_addresses.py. The script seems to be the same as what's at https://github.com/gtt116/gce/blob/master/google_daemon/manage_addresses.py (also with what's in that directory).
I don't recall installing this, so I'm imaging it came with the provided Debian image I used in 2013.
Does anyone know what this manage_addresses.py script is, what it does, and what I should do with it now that the legacy metadata server endpoints are turning down? Is it safe to just stop running it? Or is there a new script I should replace it with? Or should I just try to update it myself to use the new endpoint?
I dug around and was able to trace /usr/share/google/google_daemon/manage_addresses.py as being installed by a package called google-compute-daemon. A search for that brought me to https://github.com/GoogleCloudPlatform/compute-image-packages#troubleshooting which explains that google-compute-daemon has been replaced with python-google-compute-engine. That led me to https://cloud.google.com/compute/docs/images/install-guest-environment . I followed the instructions there and manually installed the guest environment.
I noticed during installation that it said it was removing the google-compute-daemon package (and a packaged called google-startup-scripts), so this seems like the right thing. And I'm no longer seeing any requests to the legacy endpoints. So it seems like at some point the old guest environment failed to update.
TLDR; If you have this problem, follow the instructions at https://cloud.google.com/compute/docs/images/install-guest-environment#installing_guest_environment to manually update the guest environment.
I downloaded a qcow2 image from Atomic official site, but I really frustrated with the steps to start this qcow2 image, and no helpful clear tips from Google.
Anyone can give me some clear hints on how to start the qcow2 vm? Thanks.
The image name is: Fedora-Atomic-25-20170131.0.x86_64.qcow2
The Fedora Atomic Host (FAH) qcow is a cloud image, so it expects a Metadata source. Metadata is all the configuration bits a generic cloud image uses to get configured. Specifically, it requires something that the cloud-init package recognizes. You can read more about cloud-init here. If you just want to fire off some one-off VMs for testing, a tool you can use is testcloud.
Using testcloud to launch the VM, you'll be able to log in with the user 'fedora' (which is the default in Fedora based cloud images) and the password 'passw0rd' (you can change this default in the config).
The other option is to download the installer ISO, and then you can install into a fresh VM and not have to worry about metadata at all. You can find that here, under "Other Downloads" on the right hand side.
The #fedora-cloud channel on Freenode is a good place to check if you have any other questions.
I have a Google Cloud Platform account that I access from a VirtualBox VM. I am using the Google Compute Engine for a project that I am currently working on, and I had to create a custom image based on the Ubuntu 14.04 image that's available there.
I made changes to the Ubuntu image by ssh'ing into an Ubuntu 14.04 instance, (from my Vbox VM terminal) installing the Matlab compiler runtime, and downloading some other files that I needed. I created the custom image by following the steps according to the documentation.
However, now the changes I made are only available to me when I SSH from my Vbox VM terminal. I need to be able to run a certain matlab program Via startup scripts, how can I make it so that all users using this image have access to the customizations I made? Is there a way I can do this without having to make the edits by ssh'ing from the developers console and redoing all the changes?
EDIT: I don't think I was very clear so Ill give some examples. say my Google account is alexanderlang. When I ssh into an instance created from my custom image from the developers console, bash prompt looks like:
alexanderlang#myinstance $
My Vbox username is alex, and when I ssh into the same instance from my vbox terminal, bash prompt looks like:
alex#myinstance $
alex#myinstance can run matlab programs, but alexanderlang#myinstance cannot. I'm talking about the same instance, created from the same image. I think this might have something to do with the ssh keys for my custom image, but I don't know how to change or remove those keys.
When you connect to your VM instance via ssh by using either Developers Console or gcloud, the user account is dynamically created (if it doesn't already exist) by setting metadata on the VM. The question is: how does each tool choose your username?
When you use Google Developers Console, the only information it knows about you is your Google Account name, so it uses that, e.g., <first-name>_<last-name> or similar.
When you connect to your instance via gcloud, it knows the value of $USER so it uses that instead.
Note that in either case, your account has passwordless sudo access, so if you want to switch from one account to the other, you can run:
sudo su alex
while logged in as alexanderlang and then you have access to all the programs that alex does.
Similarly, you can run:
sudo su alexanderlang
while logged in as alex to do the reverse.
Startup scripts run as root. To run commands as another user, you need to do two things:
change to that username
run commands as that user
sudo su alex will create a new shell and hence ignore the rest of the script (until you manually exit the user shell, which is not what you want).
You can use sudo su alex -c 'command to run' but since what you want to run is a complex script, you need to first save the script to a file, and then run it.
Your options are:
pre-create the shell script to run
dynamically generate it from the startup script
Doing (1) is easy if the script never changes. For frequently-changing scripts (and it sounds like, many dynamically created VMs), you want to use option (2).
Here's how to do this in a startup script:
cat > /tmp/startup-script-helper.sh <<EOF
# ... put the script contents here ...
EOF
sudo su alex -c '/tmp/startup-script-helper.sh'
You can use Packer to create a derived image from a stock GCE VM image. Packer will let you do the following very easily:
boot a GCE VM using an image you specify
run some customization step, e.g., shell script, or Chef/Puppet/etc.
save the resulting image in your Google Cloud Platform project
Then, you can boot any number of new VMs using your newly-created image.
Note that since your VM image will be stored on Google Cloud Storage, you will be charged for the space it uses. Current pricing for Google Cloud Storage standard class is USD $0.026 / GB / month. A typical VM image should be less than 1GB.
You can see a complete example of how I used Packer to build VMs and pre-installed Ambari on it via my GitHub repo.
my old father is using ubuntu-gnome. He has no static ip address. In order to perform remote administration, I need to know his ip. I was using dyndns free account (configuration in the adsl modem), but this will stop working in a couple of days.
I would like to run a script each time he logs in to publish his ip on my website. I have tried to put a script on the boot, but the network is not available. It seems that it is gnome 3 that starts the network, but I do not know much about gnome 3.
How should I do to have my script run automatically as soon as the network is available ?
One possible non-elegant solution for this is to put your script in his cron to run every X minutes :)
Looking to mine /etc/NetworkManager/ looks like there is a folder dispatcher.d that I think it'll do what you want. Just experiment with a bash/perl/python w/e script in there set the permission appropriately. You can find the UUID in the system-connections/ folder. More information is available in man networkmanager.
EDIT: Look what I found: https://askubuntu.com/questions/13963/call-script-after-connecting-to-a-wireless-network. Seems like this is exactly what you want.
The easiest way is to use another dynamic DNS service. I used to use my own. You could also put curl or wget command to cron or create a systemd service that will call that command periodically. As a target you would have to use your machine with a web server where you can see the IP in your logs.
It is not Gnome that connects the network, it is a system service called NetworkManager. It tries to connect at boot if possible. In some cases it waits for wireless signal, in other cases it waits for a user password. I recently verified that in Fedora, NetworkManager properly implements the systemd's network-online.target but it may have yet to be fixed in other distributions, see the upstream bug report.
https://bugzilla.gnome.org/show_bug.cgi?id=728965
If you want to run a system service just after boot, you need to use:
[Unit]
...
Wants=network-online.target
After=network-online.target
You could also just run a script that calls nm-online at the beginning to wait for the network connectivity if you can expect the connectivity to come up in reasonable time, otherwise it times out. Such a script can be run from any environment including a user session.
And, as noted already, you can put a script into /etc/NetworkManager/dispatcher.d that will be called on any network configuration change and such a script can then filter connection up events and start the notification script.