Password authentication for egress connections about the-bastion HOT 11 CLOSED

OK, in that case the solution is easy:

~ Access denied for myusername to [email protected]: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

from the-bastion.

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.

from the-bastion.

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?

from the-bastion.

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 [email protected] --'
It can be set as:
alias bastion='ssh -t [email protected] -- --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

?

from the-bastion.

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

myusername@bastion01(master)> ssh [email protected]
~ 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 => [email protected]:22 => [email protected]:22 ...
~ Access denied for myusername to [email protected]: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 [email protected]
~ 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 => [email protected]:22 => [email protected]:22 ...
~ Access denied for myusername to [email protected]: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 [email protected]. send teh command and get few seconds later the prompt to enter the password.

from the-bastion.

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) ?

from the-bastion.

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 :)

from the-bastion.

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 [email protected] (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 [email protected]
~ 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 => [email protected]:22 => [email protected]: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...
[email protected]: 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?

from the-bastion.

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!

from the-bastion.

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:

[email protected](master)> ssh [email protected]
~ 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 => [email protected]:22 => [email protected]:22 ...
~ Access denied for myusername to [email protected]:22

Do you have any other ideas?

from the-bastion.

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. ;-)

from the-bastion.