[GH-ISSUE #565] Using Bastion with RADIUS Authentication #146

New issue

Open

opened 2026-05-07 00:19:24 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

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

Owner

Originally created by @millosz222 on GitHub (Aug 6, 2025).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/565

Hello,
We are looking to improve security in our current network (focus is on network devices). The goal is to SSH to our network devices via bastion only, but I don't want to deploy SSH keys yet (overhead). Currently, all our switches have RADIUS authentication. I would like to allow network engineers to log in to the network devices using their credentials from AD (then authentication will be performed on the RADIUS). Then on the switches, I will set up that SSH access is only allowed from the bastion IP.
Is this concept making sense and does it match the purpose of the bastion?
Can the bastion handle each engineer using their own RADIUS username when connecting to switches (but at the same time use groups)? I found accountAddPersonalAccess with --user or with user USER|PATTERN|* and PasswordAuthentication yes KbdInteractiveAuthentication yes - is this the right approach?
Are there any additional tips available?
Our team is used to using PuTTY - can the bastion act as a kind of proxy in the above scenario?
Could you please advise? Thank you

Originally created by @millosz222 on GitHub (Aug 6, 2025). Original GitHub issue: https://github.com/ovh/the-bastion/issues/565 Hello, We are looking to improve security in our current network (focus is on network devices). The goal is to SSH to our network devices via bastion only, but I don't want to deploy SSH keys yet (overhead). Currently, all our switches have RADIUS authentication. I would like to allow network engineers to log in to the network devices using their credentials from AD (then authentication will be performed on the RADIUS). Then on the switches, I will set up that SSH access is only allowed from the bastion IP. Is this concept making sense and does it match the purpose of the bastion? Can the bastion handle each engineer using their own RADIUS username when connecting to switches (but at the same time use groups)? I found `accountAddPersonalAccess` with `--user` or with `user USER|PATTERN|*` and `PasswordAuthentication yes` `KbdInteractiveAuthentication yes` - is this the right approach? Are there any additional tips available? Our team is used to using PuTTY - can the bastion act as a kind of proxy in the above scenario? Could you please advise? Thank you

BreizhHardware commented

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

Author

Owner

@DubrullePierre commented on GitHub (Sep 8, 2025):

Hi,

I think that to implement this, you would need to turn to the FreeRadius PAM.

I haven't implemented it myself, so I'd love to hear your feedback if you do.

@DubrullePierre commented on GitHub (Sep 8, 2025): Hi, I think that to implement this, you would need to turn to the [FreeRadius PAM](https://github.com/FreeRADIUS/pam_radius). I haven't implemented it myself, so I'd love to hear your feedback if you do.

BreizhHardware commented

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

Author

Owner

@speed47 commented on GitHub (Sep 10, 2025):

What @DubrullePierre says is correct, to explain this a bit more, let's split the reasoning between the ingress (user's laptop => bastion) and egress (bastion => network device) connections.

On the ingress side, all the authentication phase is done by the OpenSSH server where the bastion is running. By default this is done through SSH public keys, but as you can use PAM, you may use anything that PAM supports, including non-default PAM modules. This is where you may want to setup your Radius. In fact, you can completely forget that this is a bastion: if you can make it work on a test server where users have a shell, then the same setup will work on a bastion to authenticate users on the ingress side.

On the egress side, the bastion connects to your infrastructure on the behalf of your users. Here, SSH keys are used (either group egress keys or accounts egress keys), but SSH password is also supported (mainly for network devices that can be limited in terms of ssh pubkeys), where the bastion will auto-input the password without the user requiring to know it.

@speed47 commented on GitHub (Sep 10, 2025): What @DubrullePierre says is correct, to explain this a bit more, let's split the reasoning between the ingress (user's laptop => bastion) and egress (bastion => network device) connections. On the ingress side, all the authentication phase is done by the OpenSSH server where the bastion is running. By default this is done through SSH public keys, but as you can use PAM, you may use anything that PAM supports, including non-default PAM modules. This is where you may want to setup your Radius. In fact, you can completely forget that this is a bastion: if you can make it work on a test server where users have a shell, then the same setup will work on a bastion to authenticate users on the ingress side. On the egress side, the bastion connects to your infrastructure on the behalf of your users. Here, SSH keys are used (either group egress keys or accounts egress keys), but SSH password is also supported (mainly for network devices that can be limited in terms of ssh pubkeys), where the bastion will auto-input the password without the user requiring to know it.