[GH-ISSUE #101] Password authentication for egress connections

BreizhHardware commented

2026-05-07 00:17:34 +02:00

Owner

Originally created by @dwydler on GitHub (Dec 17, 2020).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/101

Hallo everyone,
we have some old switches in our network, which do not support public key authentication. So any it admin had a own account with a custom password.

I study the docs and found in /etc/bastion/bastion.conf a parameter passwordAllowed. According to the description exactly what i am looking for.

I change the value from 0 to 1. After that i connected to a fresh bastion session and try different commands to get a prompt for password authentication.

Is the parameter even suitable for my requirements?
If so, which parameters do I have to use with the command ssh admin@host: 22?

Regards,
Daniel

Originally created by @dwydler on GitHub (Dec 17, 2020). Original GitHub issue: https://github.com/ovh/the-bastion/issues/101 Hallo everyone, we have some old switches in our network, which do not support public key authentication. So any it admin had a own account with a custom password. I study the docs and found in ```/etc/bastion/bastion.conf``` a parameter ```passwordAllowed```. According to the [description](https://ovh.github.io/the-bastion/administration/bastion_conf.html?highlight=passwordallowed#passwordallowed) exactly what i am looking for. I change the value from ```0``` to ```1```. After that i connected to a fresh bastion session and try different commands to get a prompt for password authentication. Is the parameter even suitable for my requirements? If so, which parameters do I have to use with the command ```ssh admin@host: 22```? Regards, Daniel

BreizhHardware closed this issue

2026-05-07 00:17:34 +02:00

BreizhHardware commented

2026-05-07 00:17:35 +02:00

Author

Owner

@speed47 commented on GitHub (Dec 18, 2020):

Hello,

We do have a few of those too. That's what passwordAllowed is for, indeed, among other things.
The documentation about how to handle this case properly is missing, but I guess this means I'll have to write it faster than I though previously :)

I'll try to sum up here: you have 2 possible solutions.

Just let the people type their passwords themselves when the remote device prompts it. In that case, setting passwordAllowed to 1 should be enough. Note that some network devices don't actually use password auth but keyboard-interactive auth. In both cases you're prompted with a passwword, but the SSH auth method is slightly different underneath. In that case, you would need to set keyboardInteractiveAllowed to 1 also. In that case, the bastion doesn't handle the egress auth side: the user does.
Let the bastion type the password to the remote device. In that case, you still need to enable passwordAllowed and/or keyboardInteractiveAllowed, but you can use the selfGeneratePassword command. The bastion will generate a random password, with the complexity you specify, and give you back the password hash to add to the userline on the remote device. In that case, the bastion user doesn't even know the password: the bastion will type it for them. To tell the bastion to do this, the users will have to use the -P command when connecting to the device through the bastion. What's nice here is that you can use a very complex password of e.g. 32 chars or even more: nobody will ever need to type it manually. You may also want to rotate the passwords every 3 months or so. In that case, this would be transparent to the users: you would just have to generate a new password on the bastion, and update the userline on the device. A proper chapter of the documentation will cover this soon.

@speed47 commented on GitHub (Dec 18, 2020): Hello, We do have a few of those too. That's what `passwordAllowed` is for, indeed, among other things. The documentation about how to handle this case properly is missing, but I guess this means I'll have to write it faster than I though previously :) I'll try to sum up here: you have 2 possible solutions. 1) Just let the people type their passwords themselves when the remote device prompts it. In that case, setting `passwordAllowed` to 1 should be enough. Note that some network devices don't actually use *password auth* but *keyboard-interactive auth*. In both cases you're prompted with a passwword, but the SSH auth method is slightly different underneath. In that case, you would need to set `keyboardInteractiveAllowed` to 1 also. In that case, the bastion doesn't handle the egress auth side: the user does. 2) Let the bastion type the password to the remote device. In that case, you still need to enable passwordAllowed and/or keyboardInteractiveAllowed, but you can use the `selfGeneratePassword` command. The bastion will generate a random password, with the complexity you specify, and give you back the password hash to add to the userline on the remote device. In that case, the bastion user doesn't even know the password: the bastion will type it for them. To tell the bastion to do this, the users will have to use the `-P` command when connecting to the device through the bastion. What's nice here is that you can use a very complex password of e.g. 32 chars or even more: nobody will ever need to type it manually. You may also want to rotate the passwords every 3 months or so. In that case, this would be transparent to the users: you would just have to generate a new password on the bastion, and update the userline on the device. A proper chapter of the documentation will cover this soon.

BreizhHardware commented

2026-05-07 00:17:36 +02:00

Author

Owner

@dwydler commented on GitHub (Dec 18, 2020):

Hi @speed47
thanks a lot for the detailed description the possibilities. I would like to use scenario 1). Both parameters passwordAllowed andkeyboardInteractiveAllowed are already set to 1 already.

On every attempt i do not get a password prompt. The Bastion displays a error message like access denied. Or is the parameter -p (ssh admin@host:22 -Pnecessary here?

@dwydler commented on GitHub (Dec 18, 2020): Hi @speed47 thanks a lot for the detailed description the possibilities. I would like to use scenario 1). Both parameters ```passwordAllowed``` and```keyboardInteractiveAllowed``` are already set to ```1``` already. On every attempt i do not get a password prompt. The Bastion displays a error message like ```access denied```. Or is the parameter ```-p``` (```ssh admin@host:22 -P```necessary here?

BreizhHardware commented

2026-05-07 00:17:36 +02:00

Author

Owner

@speed47 commented on GitHub (Dec 21, 2020):

The Bastion displays a error message like access denied.

Can you copy/paste the exact error message? It may contain some clues.

Or is the parameter -p (ssh admin@host:22 -Pnecessary here?

No, if you want interactive prompt, -P should not be used. However if you think your device uses keyboard-interactive authentication, you should add --kbd-interactive when wanting to connect to such a device (setting keyboardInteractiveAllowed just means that this option can be used, it's not enabled by default for all connections).
So for example if your bastion alias is bastion, you should use bastion --kbd-interactive admin@networkdev.

Of course if your users will be connecting to such devices all the time, they can include this command directly in their bastion alias, for example if their alias is:
alias bastion='ssh -t me@mybastion.example.org --'
It can be set as:
alias bastion='ssh -t me@mybastion.example.org -- --kbd-interactive'
Note the double-dash before the --kbd-interactive: it tells your local ssh command not to try to parse this option, but pass it rremotely (to the bastion).

If this still doesn't work, and you have shell access to the bastion, can you try these two commands:

ssh -o passwordauthentication=yes -o preferredauthentications=password admin@host

and:

ssh -o kbdinteractiveauthentication=yes -o preferredauthentications=keyboard-interactive admin@host

?

@speed47 commented on GitHub (Dec 21, 2020): > The Bastion displays a error message like `access denied`. Can you copy/paste the exact error message? It may contain some clues. > Or is the parameter `-p` (`ssh admin@host:22 -P`necessary here? No, if you want interactive prompt, `-P` should not be used. However if you think your device uses keyboard-interactive authentication, you should add `--kbd-interactive` when wanting to connect to such a device (setting `keyboardInteractiveAllowed` just means that this option can be used, it's not enabled by default for all connections). So for example if your bastion alias is `bastion`, you should use `bastion --kbd-interactive admin@networkdev`. Of course if your users will be connecting to such devices all the time, they can include this command directly in their bastion alias, for example if their alias is: `alias bastion='ssh -t me@mybastion.example.org --'` It can be set as: `alias bastion='ssh -t me@mybastion.example.org -- --kbd-interactive'` Note the double-dash before the `--kbd-interactive`: it tells your local `ssh` command not to try to parse this option, but pass it rremotely (to the bastion). If this still doesn't work, and you have shell access to the bastion, can you try these two commands: `ssh -o passwordauthentication=yes -o preferredauthentications=password admin@host` and: `ssh -o kbdinteractiveauthentication=yes -o preferredauthentications=keyboard-interactive admin@host` ?

BreizhHardware commented

2026-05-07 00:17:37 +02:00

Author

Owner

@dwydler commented on GitHub (Dec 21, 2020):

Hello,
sure, here the complete output of the (error) message. I connect directly with my user to the bastion.

myusername@bastion01(master)> ssh netadmin@192.168.95.1
~ Welcome to bastion01, myusername, your last login was 00:00:07 ago (Mon 2020-12-21 18:54:27 UTC) from 192.168.0.147(client.domain.com)

client.domain.com:49776 => myusername@bastion01.domain.com:22 => netadmin@sw-ah-rz05.domain.com:22 ...
~ Access denied for myusername to netadmin@192.168.95.1:22 myusername@bastion01(master)>

After your detailed explain i tried it with the parameter --kbd-interactive. But the result is still the same. :-(

myusername@bastion01(master)> ssh --kbd-interactive netadmin@192.168.95.1
~ Welcome to bastion01, myusername, your last login was 00:00:25 ago (Mon 2020-12-21 18:54:34 UTC) from 192.168.0.147(client.domain.com)

client.domain.com:49776 => myusername@bastion01.domain.com:22 => netadmin@sw-ah-rz05.domain.com:22 ...
~ Access denied for myusername to netadmin@192.168.95.1:22 myusername@bastion01(master)>

The current configuration looks like this:

...
"keyboardInteractiveAllowed": 1,
"passwordAllowed": 1,
...

In a bash shell on the bastion everything works as is should. I type the same command ssh netadmin@192.168.95.1. send teh command and get few seconds later the prompt to enter the password.

@dwydler commented on GitHub (Dec 21, 2020): Hello, sure, here the complete output of the (error) message. I connect directly with my user to the bastion. ``` myusername@bastion01(master)> ssh netadmin@192.168.95.1 ~ Welcome to bastion01, myusername, your last login was 00:00:07 ago (Mon 2020-12-21 18:54:27 UTC) from 192.168.0.147(client.domain.com) client.domain.com:49776 => myusername@bastion01.domain.com:22 => netadmin@sw-ah-rz05.domain.com:22 ... ~ Access denied for myusername to netadmin@192.168.95.1:22 myusername@bastion01(master)> ``` After your detailed explain i tried it with the parameter --kbd-interactive. But the result is still the same. :-( ``` myusername@bastion01(master)> ssh --kbd-interactive netadmin@192.168.95.1 ~ Welcome to bastion01, myusername, your last login was 00:00:25 ago (Mon 2020-12-21 18:54:34 UTC) from 192.168.0.147(client.domain.com) client.domain.com:49776 => myusername@bastion01.domain.com:22 => netadmin@sw-ah-rz05.domain.com:22 ... ~ Access denied for myusername to netadmin@192.168.95.1:22 myusername@bastion01(master)> ``` The current configuration looks like this: ``` ... "keyboardInteractiveAllowed": 1, "passwordAllowed": 1, ... ``` In a bash shell on the bastion everything works as is should. I type the same command ```ssh netadmin@192.168.95.1```. send teh command and get few seconds later the prompt to enter the password.

BreizhHardware commented

2026-05-07 00:17:37 +02:00

Author

Owner

@speed47 commented on GitHub (Dec 21, 2020):

OK, in that case the solution is easy:

~ Access denied for myusername to netadmin@192.168.95.1:22

This is the bastion saying that, as far as it can tell, myusername is not allowed to connect on the remote server.
In your case, as the users will type their login/passwords themselves, you can just tell the bastion to allow them:

accountAddPersonalAccess --account myusername --host 192.168.0.0/16 --port 22 --user netadmin
You'll need to do this as a bastion admin (of course, you can adjust 192.168.0.0/16 accordingly).

If such accesses need to be added automatically for everyone when their account is created, there is a config parameter for this: https://ovh.github.io/the-bastion/administration/bastion_conf.html#bastion-conf-accountcreatedefaultpersonalaccesses

@speed47 commented on GitHub (Dec 21, 2020): OK, in that case the solution is easy: > ~ Access denied for myusername to netadmin@192.168.95.1:22 This is the bastion saying that, as far as it can tell, `myusername` is not allowed to connect on the remote server. In your case, as the users will type their login/passwords themselves, you can just tell the bastion to allow them: `accountAddPersonalAccess --account myusername --host 192.168.0.0/16 --port 22 --user netadmin` You'll need to do this as a bastion admin (of course, you can adjust 192.168.0.0/16 accordingly). If such accesses need to be added automatically for everyone when their account is created, there is a config parameter for this: https://ovh.github.io/the-bastion/administration/bastion_conf.html#bastion-conf-accountcreatedefaultpersonalaccesses

BreizhHardware commented

2026-05-07 00:17:37 +02:00

Author

Owner

@dwydler commented on GitHub (Dec 21, 2020):

Now that you say it, it sounds logical... now i understand the logic.

Does it (accountAddPersonalAccess --account myusername --host 192.168.0.0/16 --port 22 --user netadmin) also work when using groups (groupAddServer --group testgroup1 --host 192.168.0.0/16 --port 22 --user netadmin) ?

@dwydler commented on GitHub (Dec 21, 2020): Now that you say it, it sounds logical... now i understand the logic. Does it (```accountAddPersonalAccess --account myusername --host 192.168.0.0/16 --port 22 --user netadmin```) also work when using groups (```groupAddServer --group testgroup1 --host 192.168.0.0/16 --port 22 --user netadmin```) ?

BreizhHardware commented

2026-05-07 00:17:38 +02:00

Author

Owner

@speed47 commented on GitHub (Dec 21, 2020):

Personal accesses and group accesses are two ways you can use to handle accesses. It depends on use cases, and both can (and often should!) be used on the same bastion, depending on how are handled the infrastructures behind it, and how many users are using the bastion.

If you haven't read it, this blog post tells more about those two ways: https://www.ovh.com/blog/the-ovhcloud-ssh-bastion-part-2-delegation-dizziness/

But to answer your question, yes, you can also add 192.168.0.0/16 to a group, and then grant membership to this group to your users :)

@speed47 commented on GitHub (Dec 21, 2020): Personal accesses and group accesses are two ways you can use to handle accesses. It depends on use cases, and both can (and often should!) be used on the same bastion, depending on how are handled the infrastructures behind it, and how many users are using the bastion. If you haven't read it, this blog post tells more about those two ways: https://www.ovh.com/blog/the-ovhcloud-ssh-bastion-part-2-delegation-dizziness/ But to answer your question, yes, you can also add 192.168.0.0/16 to a group, and then grant membership to this group to your users :)

BreizhHardware commented

2026-05-07 00:17:38 +02:00

Author

Owner

@dwydler commented on GitHub (Dec 22, 2020):

New day, new luck. :-)

First, i created a entry for my users. For that i added the parameter ---force. Otherwise I get an error message:

 Couldn't connect to netadmin@192.168.95.1 (ssh returned error 255). Hint: did you add the proper public key to the remote's authorized_keys?

After that i try to connect to a switch in our network. But the connection failed.

myusername@bastion01(master)> ssh netadmin@192.168.95.1
~ Welcome to bastion01, myusername, your last login was 00:00:18 ago (Tue 2020-12-22 09:03:06 UTC) from 10.207.187.147(client.domain.com)

client.domain.com:62752 => myusername@bastion01.domain.com:22 => netadmin@sw-ah-rz05.domain.com:22 ...
 allowed ... log on(/home/myusername/ttyrec/192.168.95.1/2020-12-22.09-03-24.253617.4dd26cba2351.myusername.netadmin.192.168.95.1.22.ttyrec)

 will try the following accesses you have: 
  - personal access with RSA-4096 key SHA256:CFEacZ9p+vMB0eQaIXQyHms61M17n/ZoTsX75NpI0+s [2020/12/01] 

Connecting...
netadmin@192.168.95.1: Permission denied (publickey,keyboard-interactive,password).
~ BASTION SAYS: The remote server (192.168.95.1) refused all the keys we tried (see the list just above), there are FOUR things to verify:
~ 1) Check the remote account's authorized_keys on 192.168.95.1, did you add the proper key there? (personal key or group key)
~ 2) Did you tell the bastion you added a key to the remote server, so it knows it has to use it? See the actually used keys just above. If you didn't, do it with selfAddPersonalAccess or groupAddServer.
~ 3) Check the from="" part of the remote account's authorized_keys' keyline. Are all the bastion IPs present? Master and slave(s)? See groupInfo or selfListEgressKeys to get the proper keyline to copy/paste.
~ 4) Did you check the 3 above points carefully? Really? Because if you did, you wouldn't be reading this 4th bullet point, as your problem would already be fixed ;)

Basicly Bastion detected in line 11 all active methods (publickey,keyboard-interactive,password) correct.

What did I miss / do wrong?

@dwydler commented on GitHub (Dec 22, 2020): New day, new luck. :-) First, i created a entry for my users. For that i added the parameter ```---force```. Otherwise I get an error message: ``` Couldn't connect to netadmin@192.168.95.1 (ssh returned error 255). Hint: did you add the proper public key to the remote's authorized_keys? ``` After that i try to connect to a switch in our network. But the connection failed. ``` myusername@bastion01(master)> ssh netadmin@192.168.95.1 ~ Welcome to bastion01, myusername, your last login was 00:00:18 ago (Tue 2020-12-22 09:03:06 UTC) from 10.207.187.147(client.domain.com) client.domain.com:62752 => myusername@bastion01.domain.com:22 => netadmin@sw-ah-rz05.domain.com:22 ... allowed ... log on(/home/myusername/ttyrec/192.168.95.1/2020-12-22.09-03-24.253617.4dd26cba2351.myusername.netadmin.192.168.95.1.22.ttyrec) will try the following accesses you have: - personal access with RSA-4096 key SHA256:CFEacZ9p+vMB0eQaIXQyHms61M17n/ZoTsX75NpI0+s [2020/12/01] Connecting... netadmin@192.168.95.1: Permission denied (publickey,keyboard-interactive,password). ~ BASTION SAYS: The remote server (192.168.95.1) refused all the keys we tried (see the list just above), there are FOUR things to verify: ~ 1) Check the remote account's authorized_keys on 192.168.95.1, did you add the proper key there? (personal key or group key) ~ 2) Did you tell the bastion you added a key to the remote server, so it knows it has to use it? See the actually used keys just above. If you didn't, do it with selfAddPersonalAccess or groupAddServer. ~ 3) Check the from="" part of the remote account's authorized_keys' keyline. Are all the bastion IPs present? Master and slave(s)? See groupInfo or selfListEgressKeys to get the proper keyline to copy/paste. ~ 4) Did you check the 3 above points carefully? Really? Because if you did, you wouldn't be reading this 4th bullet point, as your problem would already be fixed ;) ``` Basicly Bastion detected in line 11 all active methods (publickey,keyboard-interactive,password) correct. What did I miss / do wrong?

BreizhHardware commented

2026-05-07 00:17:39 +02:00

Author

Owner

@speed47 commented on GitHub (Dec 23, 2020):

Can you check the bastion /etc/ssh/ssh_config file?
Would need to set:

PasswordAuthentication yes
KbdInteractiveAuthentication yes

The bastion's configuration passwordAllowed, keyboardInteractiveAllowed and --kbd-interactive only allow the bastion to puth these auth methods in the PreferredAuthentications ssh option when connecting to the device, but if the auth method is disabled system-wide through the /etc/ssh/ssh_config file (which it is, by default), the bastion won't override it!

@speed47 commented on GitHub (Dec 23, 2020): Can you check the bastion `/etc/ssh/ssh_config` file? Would need to set: ``` PasswordAuthentication yes KbdInteractiveAuthentication yes ``` The bastion's configuration `passwordAllowed`, `keyboardInteractiveAllowed` and `--kbd-interactive` only allow the bastion to puth these auth methods in the `PreferredAuthentications` ssh option when connecting to the device, but if the auth method is disabled system-wide through the `/etc/ssh/ssh_config` file (which it is, by default), the bastion won't override it!

BreizhHardware commented

2026-05-07 00:17:39 +02:00

Author

Owner

@dwydler commented on GitHub (Dec 23, 2020):

Here my current /etc/ssh/ssh_config from the bastion host:

# === AUTHENTICATION ===

# we allow only public key authentication ...
PubkeyAuthentication yes
# ... not password nor keyboard-interactive
# ... (set to yes if sshpass is to be used)
PasswordAuthentication yes
# ChallengeResponseAuthentication=yes forces KbdInteractiveAuthentication=yes in the openssh code!
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes

To be on the safe side i restarted the whole server for my test connection. Unfortunately the result still the same:

myusername@bastion02.domain.com(master)> ssh netadmin@192.168.95.1
~ Welcome to bastion02.domain.com, myusername, your last login was 00:00:06 ago (Wed 2020-12-23 18:26:27 CET) from 123.123.123.123(xx.com)

xx.com:40679 => myusername@bastion02.domain.com:22 => netadmin@192.168.95.1:22 ...
~ Access denied for myusername to netadmin@192.168.95.1:22

Do you have any other ideas?

@dwydler commented on GitHub (Dec 23, 2020): Here my current ```/etc/ssh/ssh_config``` from the bastion host: ``` # === AUTHENTICATION === # we allow only public key authentication ... PubkeyAuthentication yes # ... not password nor keyboard-interactive # ... (set to yes if sshpass is to be used) PasswordAuthentication yes # ChallengeResponseAuthentication=yes forces KbdInteractiveAuthentication=yes in the openssh code! ChallengeResponseAuthentication yes KbdInteractiveAuthentication yes ``` To be on the safe side i restarted the whole server for my test connection. Unfortunately the result still the same: ``` myusername@bastion02.domain.com(master)> ssh netadmin@192.168.95.1 ~ Welcome to bastion02.domain.com, myusername, your last login was 00:00:06 ago (Wed 2020-12-23 18:26:27 CET) from 123.123.123.123(xx.com) xx.com:40679 => myusername@bastion02.domain.com:22 => netadmin@192.168.95.1:22 ... ~ Access denied for myusername to netadmin@192.168.95.1:22 ``` Do you have any other ideas?

BreizhHardware commented

2026-05-07 00:17:40 +02:00

Author

Owner

@dwydler commented on GitHub (Dec 23, 2020):

After some cups of coffee i found my fault. I edited /etc/ssh/sshd_config instead of as /etc/ssh/ssh_config - again.
So i have done the changes in the right file. After that i could connect successfully to my our test switches with the custom password.

Many thanks for your support. I wish you Merry Christmas!

P.S. Perhaps you can complete the docs about this chapter. ;-)

@dwydler commented on GitHub (Dec 23, 2020): After some cups of coffee i found my fault. I edited /etc/ssh/ssh**d**_config instead of as /etc/ssh/ssh_config - again. So i have done the changes in the right file. After that i could connect successfully to my our test switches with the custom password. Many thanks for your support. I wish you Merry Christmas! P.S. Perhaps you can complete the docs about this chapter. ;-)

BreizhHardware referenced this issue

2026-05-07 00:19:40 +02:00

[PR #23] [MERGED] chore: remove spurious config files #176

Rows
Columns

[GH-ISSUE #101] Password authentication for egress connections #23