Securing SSH access to warpgate

[jeffbrl]

What is the recommended way to secure warpgate from unwanted users connecting via SSH? By following the Getting Started guide, I believe you end up with an insecure setup in which anyone who can guess the targets can SSH to them.

[Eugeny]

No, targets are only accessible for authenticated users when their assigned roles match the target's own. The role list is set through targets.<target>.allowed_roles here: https://github.com/warp-tech/warpgate/wiki/Adding-an-SSH-target#connection-setup

Warpgate doesn't include any way to access targets anonymously.

[jeffbrl]

Eugeny, I appreciate the reply and your open sourcing of this software. Admittedly, I do not understand the authentication here.

Here is the target configuration in my warpgate config.

---
targets:
  - name: web-admin
    allow_roles:
      - "warpgate:admin"
    web_admin: {}
  - name: vm01
    allow_roles:
      - "warpgate:admin"
    ssh:
      host: 192.168.0.10
      username: jeffl

I am able to ssh without authentication.

jeffl@piholevm:~$ ssh admin:[email protected] -p 2222
 Warpgate  Selected target: vm01
 Warpgate  Host key (ssh-ed25519): <redacted>
 ✓ Warpgate connected

Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.15.35-1-pve x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
Last login: Wed Jun  8 12:50:04 2022 from 192.168.0.1
jeffl@vm01 ~ []$

My expectation is that I would be prompted for the warpgate admin password. What am I not understanding correctly?

[Eugeny]

Could you please post the whole config file (or send it to me privately at [email protected])?

[jeffbrl]

---
targets:
  - name: web-admin
    allow_roles:
      - "warpgate:admin"
    web_admin: {}
  - name: vm01
    allow_roles:
      - "warpgate:admin"
    ssh:
      host: 192.168.0.10
      username: jeffl
users:
  - username: admin
    credentials:
      - type: password
        hash: "<redacted>"
    roles:
      - "warpgate:admin"
roles:
  - name: "warpgate:admin"
recordings:
  enable: true
  path: /var/lib/warpgate/recordings
web_admin:
  enable: true
  listen: "0.0.0.0:8888"
  certificate: /var/lib/warpgate/web-admin.certificate.pem
  key: /var/lib/warpgate/web-admin.key.pem
database_url: "sqlite:/var/lib/warpgate/db"
ssh:
  listen: "0.0.0.0:2222"
  keys: /var/lib/warpgate/ssh-keys
  client_key: "./client_key"
log:
  retention: 7days
  send_to: ~

[cmsmith1977]

Guys, I think I ran into this same problem today. I am able to authenticate without a password with any username that has privs to the specified device and can do so with any key - including ones that aren't in the system.

[cmsmith1977]

Here's my warpgate log on connection with the message that says the credentials don't match, but it still creates the session!?

00:33:34  INFO Warpgate is now running.
00:33:34  INFO Accepting SSH connections on 0.0.0.0:2222
00:33:34  INFO Access admin UI on https://0.0.0.0:8888
00:33:34  INFO --------------------------------------------
00:33:34  INFO Listening address=0.0.0.0:8888
00:33:34  INFO Listening address=0.0.0.0:2222
00:33:41  INFO SSH: Public key auth as <username for remotehost> with key FP xs6sBleGtuX3MTOpeC1mBj0nx4X2JwZyQH+zqcv9D4s session=1eb7e2a7-2d79-495e-b1fc-b56123dbc43a
00:33:41  WARN SSH: Client credentials did not match username="username" session=1eb7e2a7-2d79-495e-b1fc-b56123dbc43a
00:33:41  INFO SSH: Authenticated username="username" session=1eb7e2a7-2d79-495e-b1fc-b56123dbc43a
00:33:41  INFO SSH: Opening session channel channel=d7e14776-1a5e-4662-958b-746756024a39 session=1eb7e2a7-2d79-495e-b1fc-b56123dbc43a session_username=username
00:33:41  INFO SSH: Recording session 1eb7e2a7-2d79-495e-b1fc-b56123dbc43a name=shell-channel-2 path="/var/lib/warpgate/recordings/1eb7e2a7-2d79-495e-b1fc-b56123dbc43a/shell-channel-2" session=1eb7e2a7-2d79-495e-b1fc-b56123dbc43a session_username=username
00:33:41  INFO SSH: Opening shell channel_id=d7e14776-1a5e-4662-958b-746756024a39 session=1eb7e2a7-2d79-495e-b1fc-b56123dbc43a session_username=username
00:33:41  INFO SSH: Connecting address=1.1.1.1:22 username="remote_username" session=1eb7e2a7-2d79-495e-b1fc-b56123dbc43a
00:33:42  INFO SSH: Connected address=1.1.1.1:22 session=1eb7e2a7-2d79-495e-b1fc-b56123dbc43a```

[Eugeny]

Thanks - this is now fixed in v0.2.3. It's a regression caused by the new OTP functionality when user.require is not set in the config file.

[jeffbrl]

Just a minor regression. ;) Thanks for the fix. The authentication works as I expect now.