I have an ever changing IP address that I like to write into an env variable $MY_IP and use it in my SSH config. But this doesn't work:
Host my_server
ForwardAgent yes
User root
Port 22
HostName $MY_IP
I also read, that something like ${MY_IP} could work, but alas, no luck so far.
Only option I see is writing a special shell-script that does the work. Or does anybody have another idea?
Related
In a nutshell, after deleting then recreating new global ssh keys on a managed host as part of an ansible play, the shared ssh keys between the controller and the host break. I would like to know a superior method to "fix" this issue and regain the original ssh key trust using ansible itself. Unfortunately this will require some explanation.
Basically as a start, right now, I don't have ansible set up when a new image is deployed. To remedy that, I have created a bash script, utilizing expect which nicely and neatly does 2 things on that new managed host:
Creates an ansible account with appropriate sudo permissions
Creates an ssh key pair between the controller and the controller and the managed host.
That's it, and that's all, however it does require manual input at this time as to the IP of the host to be run on. We now have a desired state from which ansible works well via ssh. However it seems cumbersome at 328 lines of code to check and do this procedure, more on this later.
The issue starts, due to the fact that the host/server is deployed from an image, there is a need to recreate the global keys on each so that they do not have the same set. The fix for this part of that issue is a simple 2 steps:
Find and delete all ^ssh_host_. files in the directory /etc/ssh/
Run the command: /usr/bin/ssh-keygen -A to generate new global ssh keys.
We however now have a problem, once the current ssh connection is broken to the managed host, we can no longer connect to our managed hosts as our known_hosts file on the controller now have keys that don't match. If you do nothing else, you get a prompt again to verify the remote key as it has "changed" and you can't continue until you do. (Stopping all playbooks from functioning) OR if you try to clear the IP out of the known_hosts file on the controller and put it back in, you get the lovely below message:
"changed": false,
"msg": "Failed to connect to the host via ssh: ###########################################################\r\n# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! ***SNIP*** You can use following command to remove the offending key:\r\nssh-keygen -R 10.200.5.4 -f /home/ansible/.ssh/known_hosts\r\nECDSA host key for 10.200.5.4 has changed and you have requested strict checking.\r\nHost key verification failed.",
"unreachable": true
So now I have an issue, and there must be a few commands which I can utilize with ssh-keygen, and/or ssh-keyscan to fix this mess cleanly. However for the life of me I can't figure it out. My only recourse now is to re-run the bash script which initially sets this all up, and replace everything on the controller/host sshkey wise. This seems like overkill, I can't possibly believe that is necessary.
My only hope now is that someone else has an idea how to solve this cleanly and permanently without manual intervention. Otherwise, the only thing I can do is set the ansible_ssh_common_args: "-o StrictHostKeyChecking=no"fact and run the commands my script does but only in playbook form. I can't believe there aren't any modules which can accomplish this. I tried the known_host module, but either I don't know how to use it properly, or it doesn't have this functionality. (Also it has the annoying property of changing my known_hosts file to root ownership, which I must then change back.)
If anyone can help that would be fantastic! Thanks in advance!
The below is not strictly needed as it's extra text clogging up the works, but it does illustrate how the bash script fixes this issue and maybe give some insight on a better solution:
In short, it generates an ssh public and private key, attaches the hostname to them, creates an ssh config identity file using a heredocs population method, puts them in the proper spots, and then copies the public key over to mangaged host in question.
The code snipits are below to show how this is accomplished. This is not the entire script just relevant parts:
#HOMEDIR is /home/ansible This host is the IP of managed host in the run.
#THISHOST is the IP of the managed host in question. Yes, we ONLY use IP's, there is no DNS.
cd "$HOMEDIR"
rm -f $HOMEDIR/.ssh/id_rsa
ssh-keygen -t rsa -f "$HOMEDIR"/.ssh/id_rsa -q -P ""
sudo mkdir -p "$HOMEDIR"/.ssh/rsa_inventory && sudo chown ansible:users "$HOMEDIR"/.ssh/rsa_inventory
cp -p "$HOMEDIR"/.ssh/id_rsa "$HOMEDIR"/.ssh/rsa_inventory/$THISHOST-id_rsa
cp -p "$HOMEDIR"/.ssh/id_rsa.pub "$HOMEDIR"/.ssh/rsa_inventory/$THISHOST-id_rsa.pub
#Heredocs implementation of the ssh config identity file:
cat <<EOT >> /home/ansible/.ssh/config
Host $THISHOST $THISHOST
HostName $THISHOST
IdentityFile ~/.ssh/rsa_inventory/${THISHOST}-id_rsa
User ansible
EOT
#Define the variable earlier before the expect script is run so it makes sense in next snipit:
ssh_key=$( cat "$HOMEDIR"/.ssh/id_rsa.pub )
#Snipit in except script where it echos over the public ssh key to the managed host from the controller.
send "sudo echo '"$ssh_key"' >> /home/ansible/.ssh/authorized_keys\n"
expect -re {:~> *$}
send "sudo chmod 644 /home/ansible/.ssh/authorized_keys\n"
expect -re {:~> *$}
#etc etc, so on and so forth properly setting attributes on this file. ```
Now things work with passwordless ssh as they should. Until they are re-ruined by the global ssh key replacement.
My fault: I have been so busy learning other linux stuff that I completely neglected the power of bash.
I have a number of systems to access remotely for very simple operations. The problem is that I need to remember each single IP address. And they are a lot.
Using aliases in ~./bashrc is an option:
alias ssh_customer1='ssh root#10.X.X.X'
alias ssh_customer2='ssh root#10.X.X.Y'
alias copy_customer1='scp * root#10.X.X.X:/etc/example/'
alias copy_customer2='scp * root#10.X.X.Y:/etc/example/'
alias get_customer1='scp root#10.X.X.X:/etc/example/* .'
alias get_customer2='scp root#10.X.X.Y:/etc/example/* .'
but the flexibility is minimal.
Another possibility is to define functions using the name of system as a parameter but I don't like this:
sshx('customer1')
scpx('customer2')
I would prefer to just replace a label with the corresponding IP address without the need to remember it, and use standard commands:
ssh root#ip_customer1
scp root#ip_customer2:/etc/example/* .
Is this possible?
Setup a ~/.ssh/config file:
$ cat ~/.ssh/config
Host cust1
HostName 10.X.X.X
User root
Host cust2
HostName 10.X.X.Y
User root
Now you can use:
ssh cust1
Another cool thing is that you can now attach identity files to each server:
$ cat ~/.ssh/config
Host cust1
HostName 10.X.X.X
User root
IdentityFile ~/.ssh/cust1.id_rsa
Host cust2
HostName 10.X.X.Y
User root
IdentityFile ~/.ssh/cust2.id_rsa
This will let you use ssh and scp without password, assuming the key is without password or ssh-agent is used.
I'm attempting to write an Ansible task that utilizes an environment variable on the remote host.
Based on the docs I've thought to use either lookup('env', 'SSH_AUTH_SOCK') oransible_env.SSH_AUTH_SOCK` but neither is returning the correct value. If I use the former it returns the value from my local host (not the remote host). If I use the latter is returns nothing.
If I ssh into the machine I'm able to run echo $SSH_AUTH_SOCK without issue.
My understanding was that ansible_env was the proper access point for remote host environment variables but that seems to not be the case.
Any help is appreciated.
It is possible the env variable (SSH_AUTH_SOCK) is not in the remote's env, so it is returning nothing. One way to rule this out is to get something that is always available, eg: USER or SSH_CLIENT. If you can get that value, then you can safely assume SSH_AUTH_SOCK is not set in remote's env.
- debug: msg={{ ansible_env.USER }}
The reason you see SSH_AUTH_SOCK is set when you ssh into the machine could be: Your login profile or bash script is starting ssh-agent which sets SSH_AUTH_SOCK variable with the unix socket so that ssh-add works correctly.
This question already has answers here:
SSH to remote server using ansible
(2 answers)
Closed 6 years ago.
I'm fairly certain I've seen a feature in the ansible documentation where you can tell it that to connect to certain hosts it first needs to tunnel through a DMZ host. I can't however seem to find any documentation outside of some debates on the mailing lists.
I'm aware of hacking this in with an ssh config like on this page http://alexbilbie.com/2014/07/using-ansible-with-a-bastion-host/ however that's an overcomplicated kludge for an extremely common requirement in any kind of mildly regulated environment.
Is there a way to do this without using custom ssh config includes and voodoo netcat sorcery?
With Ansible 2, this is a built-in option:
How do I configure a jump host to access servers that I have no direct access to?
With Ansible 2, you can set a ProxyCommand in the ansible_ssh_common_args inventory variable. Any arguments specified in this variable are added to the sftp/scp/ssh command line when connecting to the relevant host(s). Consider the following inventory group:
[gatewayed]
foo ansible_host=192.0.2.1
bar ansible_host=192.0.2.2
You can create group_vars/gatewayed.yml with the following contents:
ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q user#gateway.example.com"'
Ansible will append these arguments to the command line when trying to connect to any hosts in the group gatewayed. (These arguments are used in addition to any ssh_args from ansible.cfg, so you do not need to repeat global ControlPersist settings in ansible_ssh_common_args.)
Note that ssh -W is available only with OpenSSH 5.4 or later. With older versions, it’s necessary to execute nc %h:%p or some equivalent command on the bastion host.
If your jump box needs a private key file to connect (even if it's the same key as the one used for the private subnet instances), use this instead:
ansible_ssh_common_args: '-o ProxyCommand="ssh -i <path-to-pem-file> -W %h:%p -q user#gateway.example.com"'
I spent hours trying to fix a problem that now seems like a simple and obvious solution.
As Ansible uses SSH, you can specify a bastion host in the standard SSH config way:
e.g. to connect through a bastion host for all servers that have a name like "*.amazonaws.com":
Host *.amazonaws.com
ProxyCommand ssh -W %h:%p my_bastion_host.example.org
When ansible or ansible-playbook runs, it will read in your SSH configuration file and apply it for connections. You can also specify which SSH configuration file is read by using the ANSIBLE_SSH_ARGS environmental variable or by using the -F flag when calling the command.
You are also able to specify more SSH arguments in the ansible.cfg.
I'm running a couple of standard Fedora instances on EC2. I feel the public hostnames of the instances assigned by Amazon are too weird and hard to remember. I'd like to change them to something short (like red/blue/green/etc).
Is there any draw back in doing this? And how do I set it up such that it persists after reboots?
Thanks.
Before you get started, try running hostname and hostname --fqdn and take note of what the responses are.
You can edit /etc/hostname and set a hostname, which will stick around after rebooting. You can force the hostname to be "reloaded" by using hostname -F /etc/hostname to read that value into the hostname. The bash prompt will change after you logout and login.
warning / note:
Yes, it is nice to have the hostname in the bash prompt set to something more useful than ip-123-123-123-123 but I've decided to leave mine (at least for now) because it seems like a lot of things really count on having the hostname on ec2 instances set in a standard way. After editing /etc/hostname and changing the hostname to webserver a lot of the services seems to fail because the hostname would not resolve, and apache wouldn't start. Next I edited /etc/hosts and added in
127.0.0.1 webserver
as the second line. Apache would then start but complained that it couldn't find the FQDN. I confirmed that running hostname --fqdn no longer worked.
Next I consulted man hostname and learned that while you can set the hostname it appears that the FQDN is what is returned via a DNS lookup.
THE FQDN
You can't change the FQDN (as returned by hostname --fqdn) or the DNS domain name (as returned by dnsdomainname) with this command. The FQDN of the system is the name that the resolver(3) returns for the host name.
Technically: The FQDN is the name getaddrinfo(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot.
Therefore it depends on the configuration (usually in /etc/host.conf) how you can change it. Usually (if the hosts file is parsed before DNS or NIS) you can change it in /etc/hosts.
I think it might be possible to set the system / fool the system into return the FQDN, something like ip-123-123-123-123.ec2.internal even though the hostname is webserver but at this point it started to seem like more trouble than it was worth, and that for me to have a nicer bash prompt might cause a lot software and configuration problems down the road and so I decided to give up.
I also learned that a lot of amazon ec2 instances use something called cloud-init:
cloud-init is the Ubuntu package that handles early initialization of a cloud instance. It is installed in the Ubuntu Cloud Images and also in the official Ubuntu images available on EC2.
Some of the things it configures are:
setting a default locale
setting hostname
generate ssh private keys
adding ssh keys to user's .ssh/authorized_keys so they can log in
setting up ephemeral mount points
cloud-init's behavior can be configured via user-data. User-data can be given by the user at instance launch time. This is done via the --user-data or --user-data-file argument to ec2-run-instances
I also found this which talks about how the hostname is configured with cloud-init:
On EBS instances, a shutdown and later start would end up with a different IP address.
In the case where the user has not modified /etc/hostname from its original value (seeded by metadata's 'local-hostname'), then cloud-init will again set the hostname and update /etc/hostname.
In the case where the user has modified /etc/hostname, it will remain user managed.
Additionally, if /etc/cloud/cloud.cfg contains 'preserve_hostname' value set to a True value, then /etc/hostname will not ever be touched.
The interesting takeaway is that if you don't change the hostname the cloud-init package will keep it up to date for you.
If someone else has a workaround or can address some of the issues mentioned and help reassure that nothing will break on ec2 instances because of changing the hostname I would be happy to hear it.
Another way is to simply edit ~/.bashrc and prepend PS1 with the nickname of the machine.
Edit: perhaps more correctly, machine-wide, e.g. on the AWS Linux AMI (an example) (paste this into console or add to your arbitrary install .sh):
cat << EOF | sudo tee /etc/profile.d/ps1.sh
if [ "$PS1" ]; then
PS1="[\u#myinst1:\l \t \! \W]\\$ "
fi
EOF
Edit /etc/sysconfig/network as root.
Replace
HOSTNAME=localhost.localdomain
with
HOSTNAME=hostname.DOMAIN_NAME
Then, either reboot or run /etc/init.d/network restart
The server then should report its name as a FQDN.
From this site:
Change the hostname on a running system
On any Linux system you can change its hostname with the command hostname (surprised?)…
Here are some quick usages of the command line hostname:
$> hostname
without any parameter it will output the current hostname of the system.
$> hostname --fqd
it will output the fully qualified domain name (or FQDN) of the system.
$> hostname NEW_NAME
will set the hostname of the system to NEW_NAME.
You can also edit /etc/hostname (at least on Ubuntu).
To make sure it stays after a reboot in AWS, either add the command in /etc/rc.local so it runs when the machine starts.
There's also a way to set the hostname dynamically via USER_DATA:
USER_DATA=`/usr/bin/curl -s http://169.254.169.254/latest/user-data`
HOSTNAME=`echo $USER_DATA`
IPV4=`/usr/bin/curl -s http://169.254.169.254/latest/meta-data/public-ipv4`
hostname $HOSTNAME
echo $HOSTNAME > /etc/hostname
To change the system hostname to a public DNS name
Follow this procedure if you already have a public DNS name registered
Open the /etc/sysconfig/network configuration file in your favorite text editor and change the HOSTNAME entry to reflect the fully qualified domain name (such as webserver.mydomain.com).
HOSTNAME=webserver.mydomain.com
Reboot the instance to pick up the new hostname.
[ec2-user ~]$ sudo reboot
Log into your instance and verify that the hostname has been updated. Your prompt should show the new hostname (up to the first ".") and the hostname command should show the fully qualified domain name.
[ec2-user#webserver ~]$ hostname
webserver.mydomain.com
To change the system hostname without a public DNS name
Open the /etc/sysconfig/network configuration file in your favorite text editor and change the HOSTNAME entry to reflect the desired system hostname (such as webserver).
HOSTNAME=webserver.localdomain
Open the /etc/hosts file in your favorite text editor and add an entry beginning with 127.0.1.1 (on DHCP systems) or eth0's address (on static IP systems) to match the example below, substituting your own hostname. (127.0.0.1 should be left as the localhost line.)
127.0.0.1 localhost localhost.localdomain
127.0.1.1 webserver.example.com webserver
Reboot the instance to pick up the new hostname.
[ec2-user ~]$ sudo reboot
Log into your instance and verify that the hostname has been updated. Your prompt should show the new hostname (up to the first ".") and the hostname command should show the fully qualified domain name.
[ec2-user#webserver ~]$ hostname
webserver.localdomain
Note: You can also change the shell prompt without affecting the hostname. Refer to this AWS documentation.
Sure, you can do that if you have your own domain (setup a CNAME to point to the Amazon hostname). Otherwise, you're pretty much stuck with the one they give you (or an Elastic IP, if you set one of those up).
The /etc/rc.local solution worked for me for a basic hostname but does not give me a FQDN.
In my Linux AMI (a snapshot of other instance).. none of the above formula worked. Then, I simply changed HOSTNAME field in file: /etc/init.d/modifyhostname and did a normal reboot.
You will need to do multiple things to set the hostname:
hostname newname - sets the hostname, but is volatile
edit /etc/hostname - sets the hostname for the next reboot
edit /etc/hosts - to keep sudo from complaining
I put these together into a script and uploaded it as a gist:
https://gist.github.com/mnebuerquo/5443532036af8b48995547e2817dba85
sudo hostname *yourdesiredhostnamehere*
sudo /etc/init.d/networking restart
then the hostname is changed. On my server all other services like apache and postfix works. Server is Ubuntu 12.04 LTS