Disclaimer: I don't have specific experience with Bamboo, but I've used other CI solutions in situations like this and I think the principles are transferrable.
Your CI jobs won't authenticate to the target environments using
sfdx force:auth:web:login because that command always involves user interaction. This is not about Windows versus Linux as such, but about setting up a process that works with no UI. While each CI solution is a little different as far as what the configuration looks like, you'll find the sequence of steps is generally the same.
Sticking with authentication for a minute, it looks like you're not using Ant to do your deployments but SFDX CLI. In that case, you'll authenticate using the headless JWT OAuth flow. Your CI script should issue the command
sfdx force:auth:jwt:grant -u firstname.lastname@example.org -f my_jwt_key_file -i my_OAuth_consumer_key
Generally your JWT private key will be stored in your repo in encrypted form, and your CI will decrypt it using a key stored in an environment variable. This offers you more security than keeping plaintext usernames and passwords lying around.
You'll have pre-seeded your environments with a Connected App and a certificate, the private key corresponding to which is the JWT key field mentioned above. Your OAuth consumer key above will come from that Connected App.
The Salesforce DX Developer Guide provides detailed instructions on how to set up connected apps with authentication via JWT for use in continuous integration. See Authorize an Org Using the JWT-Based Flow and following sections.
Once you've authenticated, again assuming that you're using the SFDX CLI but not scratch orgs or the new source format, you'd deploy your source code to a sandbox by having your CI script issue a command like
sfdx force:mdapi:deploy -d src --testlevel RunLocalTests [as desired] -w -1
That will deploy your Metadata API format-source code and run your tests, waiting as long as needed to execute the command.
- I have written quite a bit on Salesforce CI using CircleCI. While it's Salesforce DX-specific, the authentication solution will be quite similar.
- Salesforce provides an example repository for Travis CI, which could also be useful.
- Trailhead has a good module (again using Travis with SFDX). You can think of your use case as combining the Dev Hub and the scratch org.
- The Salesforce DX Developer Guide, linked above, has very detailed instructions on setting up JWT authentication for headless CI. Your use case is a little bit different, again, but you can still use the same structures to authenticate to your sandbox instead of a Dev Hub.