# Test if SSH login possible without FATAL error? **URL:** \ **Category:** Ansible Project\ **Created:** [November 4, 2013, 8:29pm UTC](https://forum.ansible.com/t/test-if-ssh-login-possible-without-fatal-error/13841 "2013-11-04T20:29:22Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Dave\_Stern1](https://avatars.discourse-cdn.com/v4/letter/d/b5a626/32.png) [@Dave\_Stern1](https://forum.ansible.com/u/Dave_Stern1)\ **Post date:** [November 4, 2013, 8:29pm UTC](https://forum.ansible.com/t/test-if-ssh-login-possible-without-fatal-error/13841/1 "2013-11-04T20:29:22Z")
Posted this on Stack Overflow with no response so far, so I’m hoping someone can answer this in the group: [http://stackoverflow.com/questions/19642167/ansible-test-if-ssh-login-possible-without-fatal-error](http://stackoverflow.com/questions/19642167/ansible-test-if-ssh-login-possible-without-fatal-error) I have a setup playbook that takes a freshly installed linux instance, logs in as the default user (we’ll call user1), creates another user (we’ll call user2), then disables user1. Because user1 can only access the instance before this set of tasks is executed, the tasks are in a special playbook we have to remember to run on new instances. After that, all the common tasks are run by user2 because user1 no longer exists. I want to combine the setup and common playbooks so we don’t have to run the setup playbook manually anymore. I tried to create a task to see which user exists on the instance to make the original setup tasks conditional by attempting to login via SSH as user1. The problem is that if I try the SSH login for either user, ansible exits with a FATAL error because it can’t login: user2 doesn’t exist yet on new instances or user1 has been disabled after the setup playbook executes. `ignore_errors: yes` has no effect in this case. I believe testing the login via SSH is the only way to determine externally what condition the instance is in. Is there a way to test SSH logins without getting a FATAL error to then execute tasks conditionally based on the results? ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [November 4, 2013, 11:17pm UTC](https://forum.ansible.com/t/test-if-ssh-login-possible-without-fatal-error/13841/2 "2013-11-04T23:17:00Z")
Quick Public Service Announcement — There’s a much larger community of Ansible users here, so I’d prefer if you’re going to post here, just post here – and then we don’t have to bother with duplicating the response on Stack Overflow. Our support guys read Stack Overflow some, but everybody is _here_. Stack Overflow has some policies around discussion and closing topics that I also don’t care for, but that’s their right, obviously. Back to the regularly scheduled program… There isn’t presently a way to try one user and then another. I think it would be a useful feature, but is not something I’m immediately going to implement any time soon as I can see it getting out of hand… try this user with this password then this user with that password etc etc I’d much rather people _know_ what machines are using what keys and passwords rather than doing guess and check. Don’t get me wrong, I can see it being useful… but this seems to be a very good reason to get to common SSH keys. ---
**Author:** ![Dave\_Stern1](https://avatars.discourse-cdn.com/v4/letter/d/b5a626/32.png) [@Dave\_Stern1](https://forum.ansible.com/u/Dave_Stern1)\ **Post date:** [November 5, 2013, 5:55pm UTC](https://forum.ansible.com/t/test-if-ssh-login-possible-without-fatal-error/13841/3 "2013-11-05T17:55:34Z")
Fair enough on the Stack Overflow issue. Some groups prefer usage questions on SO and dev questions in the google group, but I’ve been very happy with the quality of discussion here, so that’s fine with me. My intent was not to duplicate, only to try and post to the correct forum first. I’ll follow your suggestion going forward. Regarding the SSH keys, I’m not necessarily advocating any features. But as a security issue, we routinely disable the default users that some OS distros ship with in favor of less discoverable usernames with completely different SSH keys. Let me also make it very clear that we realize this is not maximum security, just another deterrent. So the default user only exists right after instantiation, then it’s disabled. I just don’t know of a good way using ansible to detect whether that switch has happened, so we end up running one playbook on new instances, then our master playbook from that point forward. Perhaps we can come up with a workaround if fatal errors can’t be avoided. Thanks for the response. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [November 6, 2013, 2:08pm UTC](https://forum.ansible.com/t/test-if-ssh-login-possible-without-fatal-error/13841/4 "2013-11-06T14:08:29Z")
We have ansible-devel for development topics. This is the user list actually. You can set ansible\_ssh\_user: foo as a host\_vars/ variable to specify a different username to try for the host if you want. ---
**Author:** ![Dave\_Stern1](https://avatars.discourse-cdn.com/v4/letter/d/b5a626/32.png) [@Dave\_Stern1](https://forum.ansible.com/u/Dave_Stern1)\ **Post date:** [November 7, 2013, 7:48pm UTC](https://forum.ansible.com/t/test-if-ssh-login-possible-without-fatal-error/13841/5 "2013-11-07T19:48:42Z")
Thanks. I believe ansible\_ssh\_user would still fail. The same host will only allow login to one or the other username depending on the state. So one will always fail. I’m considering a different, very limited login shell instead of disabling the initial user or simply leaving the burden with the user to run the initial playbook. Ideally it would be nice to have a switch like “ignore\_errors” for login failures that doesn’t produce a fatal error and allows execution to continue. I could then change users based on that result and try again with a different user. I’m not pushing for that feature, but there is a use case for disabling a login for security and needing the ability to detect that and continue with another one. Perhaps it’s a niche and we just need to remember to run the initial playbook first. Or perhaps my process could use improvement - I’m just accustomed to locking down boxes on install. Open to ideas on process. ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [November 7, 2013, 8:09pm UTC](https://forum.ansible.com/t/test-if-ssh-login-possible-without-fatal-error/13841/6 "2013-11-07T20:09:13Z")
you might want your first play to be something like this: - hosts: all   gather\_facts: False   remote\_user: normal\_one   tasks:       - setup:         ignore\_errors: true         register: normalworks       - include: bootstrap.yml remote\_user: bootsrap\_user         when: normalworks is not defined         # bootstrap should call setup again to make sure you have host facts .... continue as normal ---
**Author:** ![Dave\_Stern1](https://avatars.discourse-cdn.com/v4/letter/d/b5a626/32.png) [@Dave\_Stern1](https://forum.ansible.com/u/Dave_Stern1)\ **Post date:** [February 18, 2014, 7:44pm UTC](https://forum.ansible.com/t/test-if-ssh-login-possible-without-fatal-error/13841/7 "2014-02-18T19:44:29Z")
Brian, I know it took me a long while, but I finally got to working on this and your suggestion was extremely helpful. I implemented a variation that works really well for me. In this example, user “original” is the one the OS ships with and that we want to disable. User “newuser” is the one we want to enable. ## Secure the server and disable user original if this is a new instance - hosts: all:!localhost gather\_facts: false user: original sudo: yes tasks: - name: Attempt basic command as user original to determine setup status. Failure means the machine has been secured raw: hostname ignore\_errors: yes register: setup\_status - include: roles/common/tasks/user-newuser.yml when: not “Account disabled.” in setup\_status.stdout handlers: - include: roles/common/handlers/main.yml # Continue with standard setup when user newuser is enabled and original disabled - hosts: all:!localhost user: newuser sudo: yes roles: - common handlers: - include: roles/common/handlers/main.yml