The other day one of our projects at work had its Git master branch updated, I had been working on a few projects of my own with local branches based off of the earlier master branch. As usual, I had to pull down the latest version of master and merge it in to my local branch. My normal workflow is for this is:

# Ensure I switch to the master branch locally
git checkout master
# Pull down the latest version of the repo
git fetch -p origin
# Merge the pulled down origin in to my local master
git merge origin/master
# Switch to the branch I am working on
git checkout my-local-branch
# Merge the master branch in to my-local-branch
git merge master

The above works great and is my regular workflow. Most of the time I am able to merge things without conflict, however on this occasion there was a merge conflict. This wouldn’t be an issue, however I overlooked the git output that indicated this to me.

What followed is I built a local .deb package to test on one of our dev servers. I pushed to the package up, installed it via dpkg and thought awesome, let’s give it a test. That’s when I ran in to a problem.

-bash: /usr/local/lib/path/to/the/script.sh: line 20: syntax error near unexpected token `<<<'
-bash: /usr/local/lib/path/to/the/script.sh: line 20: `<<<<<<< HEAD'
Connection to dev.server closed.

Well that’s not good! Essentially the profile on the server loads a set of scripts by default and in one of those scripts was my merge error from git. This caused a syntax error when reading the file and the profile failed to load, closing my SSH connection.

I didn’t have direct root access so I started looking for a way to disable loading of the profiles in order to allow me to SSH in. This yielded the following to tack on to the SSH command:

ssh dev.server "bash --noprofile"

The above tacks executes the bash command with the --noprofile flag. This flag specifically prevents profiles from loading, including as explained in the Bash man pages and includes /etc/profile as well as local user profiles such as /home/user/.bashrc.

This is great, I was able to log in, however at the same time, what I found was that this also meant a TTY terminal control session was not started and I was unable to sudo in order to edit or remove the file. I kept running into the following error:

sudo: no tty present and no askpass program specified

After some searching I found a great article on shell-tips.com that shed some further light on to what was happening with regard to the lack of a TTY session and the proposed fix being adding the -t flag to the SSH call. In a nutshell the flag provides a pseudo-sudo shell when the connection is made, allowing me to run sudo commands without loading the profiles that were calling the corrupt file.

I was able to successfully amend the file on the server and restore access while resolving the merge conflict locally and successfully merging the branches. The above is a great way to get around issues where a script being called from a user profile fails and your SSH session fails to load.