Login faster?

[LuKks]

Awesome work, works perfectly as intended!

One small thing, can we make it faster to login?

sudo journalctl -f -u ssh2incus.service

Sep 06 07:08:27 instance-20230425-2252 ssh2incus[2073189]: level=info msg=connection accepted, handing off to child process
Sep 06 07:08:27 instance-20230425-2252 ssh2incus[2073189]: level=info msg=started detached child process with pid 2301965
Sep 06 07:08:27 instance-20230425-2252 ssh2incus[2301965]: level=info msg=starting ssh2incus as child process, pid 2301965
Sep 06 07:08:27 instance-20230425-2252 ssh2incus[2301965]: level=info msg=child serving connection from 1.2.3.4:55484
Sep 06 07:08:28 instance-20230425-2252 ssh2incus[2301965]: level=error msg=auth (instance): failed to compare keys for ubuntu@instance.project+root: ssh: no key found session=b186d793
Sep 06 07:08:28 instance-20230425-2252 ssh2incus[2301965]: level=info msg=auth (host): succeeded for ubuntu@instance.project+root: ssh-ed25519 SHA256:oNLu5tGVH56hsU+tyd/+7487yW0IYdeVRoC2SWyVSXY session=b186d793

When I do e.g. ssh instance, in like half a second I see the logs above appear in the journalctl output (and maybe even these logs could be a tiny bit delayed due systemd logs etc so the actual execution is faster than it appears to be from the logs)

That's all good, but after the logs appears it takes like a full second or second and a half to actually shell into it

I know it sounds like ok it's just one second, but just wondering if there is an easy way to increase the speed

Especially if I already logged in once, then I exited the ssh, then I ssh into it again it should be pretty much instant

Maybe we can leave the internal server running until a configurable timeout to kill it e.g. 5 minutes

---

I tried without master process (although, I would really like to still have it thus the timeout idea) but then this happens:

ARGS="--inauth"
panic: send on closed channel within the logs

Sep 06 07:25:06 instance-20230425-2252 ssh2incus[2302826]: level=error msg=auth (instance): failed to compare keys for ubuntu@s2475755540.u68a014b49d204e83cfe71be1+root: ssh: no key found session=56b9e28e
Sep 06 07:25:06 instance-20230425-2252 ssh2incus[2302826]: level=info msg=auth (host): succeeded for ubuntu@s2475755540.u68a014b49d204e83cfe71be1+root: ssh-ed25519 SHA256:oNLu5tGVH56hsU+tyd/+7487yW0IYdeVRoC2SWyVSXY session=56b9e28e
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]: level=error msg=auth (instance): failed to compare keys for ubuntu@s2475755540.u68a014b49d204e83cfe71be1+root: ssh: no key found session=c4dfec6e
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]: level=info msg=auth (host): succeeded for ubuntu@s2475755540.u68a014b49d204e83cfe71be1+root: ssh-ed25519 SHA256:oNLu5tGVH56hsU+tyd/+7487yW0IYdeVRoC2SWyVSXY session=c4dfec6e
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]: level=error msg=shell: failed to add agent socket: Failed to fetch instance "s2475755540" in project "default": Instance not found session=c4dfec6e
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]: level=error msg=shell: exec failed: exec instance: Failed to fetch instance "s2475755540" in project "default": Instance not found session=c4dfec6e
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]: panic: send on closed channel
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]: goroutine 218 [running]:
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]: ssh2incus/server.shellHandler.func3()
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]:         ssh2incus/server/shell.go:215 +0x4c
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]: created by ssh2incus/server.shellHandler in goroutine 228
Sep 06 07:25:12 instance-20230425-2252 ssh2incus[2302826]:         ssh2incus/server/shell.go:213 +0xdf0
Sep 06 07:25:12 instance-20230425-2252 systemd[1]: ssh2incus.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Sep 06 07:25:12 instance-20230425-2252 systemd[1]: ssh2incus.service: Failed with result 'exit-code'.
Sep 06 07:25:15 instance-20230425-2252 systemd[1]: ssh2incus.service: Scheduled restart job, restart counter is at 1.
Sep 06 07:25:15 instance-20230425-2252 systemd[1]: Stopped SSH server for Incus instances.
Sep 06 07:25:15 instance-20230425-2252 systemd[1]: Started SSH server for Incus instances.
Sep 06 07:25:15 instance-20230425-2252 ssh2incus[2302910]: level=info msg=starting ssh2incus on :2222 as daemon, pid 2302910
Sep 06 07:25:15 instance-20230425-2252 ssh2incus[2302910]: level=error msg=delete instance s1622523035.u68a014b49d204e83cfe71be1 device ssh2incus-proxy-socket-186297a562fe48307w2qt: failed to get instance s1622523035.u68a014b49d204e83cfe71be1: Failed to fetch instance "s1622523035" in project "default": Instance not found
Sep 06 07:25:15 instance-20230425-2252 ssh2incus[2302910]: level=error msg=delete instance s2031031808.u68a014b49d204e83cfe71be1 device ssh2incus-proxy-socket-1862a61aefff0893dsfvn: failed to get instance s2031031808.u68a014b49d204e83cfe71be1: Failed to fetch instance "s2031031808" in project "default": Instance not found
Sep 06 07:25:15 instance-20230425-2252 ssh2incus[2302910]: level=error msg=delete instance s2031031808.u68a014b49d204e83cfe71be1 device ssh2incus-proxy-socket-1862a61d08643d89hyejl: failed to get instance s2031031808.u68a014b49d204e83cfe71be1: Failed to fetch instance "s2031031808" in project "default": Instance not found

[LuKks]

Or if there was a way to hint ssh2incus to start the internal ssh server for a specific instance (until the timeout if nobody connects) so that the first ssh is fast. Although, this is overkill but it's just about improving user experience after instance creation

Also, I accidentally commented early but see the logs "... level=error msg=delete instance ..." at the end, there were like 20 like these

[LuKks]

Another idea, if we could change the welcome and banner that would be so cool. if it's a low priority feature, I can just fork the repo for that one so don't worry about it :)

[LuKks]

The same panic crash happened with master process, so it's unrelated to -m

[arthurpro]

@LuKks, thanks for your feedback! we are working on v0.7 with a number of new features and improvements.
we can definitely consider adding your suggestions.

when you see the error like "... level=error msg=delete instance ... device" it's not a critical error.
it's a housekeeping operation which is supposed to delete some instance proxy devices created for port forwarding during ssh connection. your error says that the instance did not exist when it tried to remove temporary proxy devices. if you delete an instance all its proxy devices get deleted as well.

[LuKks]

Very important feature, I would like to allow the equivalent of the next config for individual containers:

PubkeyAuthentication yes
PasswordAuthentication yes
AuthenticationMethods publickey,password

Meaning I want a specific container to need both auth methods at the same time (key and password)

Is that possible? Or the nature of ssh2incus doesn't allow it?

[arthurpro]

@LuKks yes, in the upcoming 0.7 release we already implemented that. you will have password authentication flag

  -p, --password-auth         enable password authentication

key authentication is always primary. and once you enable password auth flag you will have password auth as secondary auth method.

we need a few more days to finish testing ssh2incus 0.7 before releasing it to the public.

[LuKks]

Just to confirm, it wasn't about primary vs secondary, I meant BOTH at the same time which is how AuthenticationMethods works. Meaning it needs both methods being authenticated for the session, could that be the behaviour?

[arthurpro]

@LuKks I think we can add that feature as well. what is your use case for that? understanding it will help us implement and test it properly

[LuKks]

Assume my machine is compromised. The attacker can't SSH into the container without knowing the password and considering macOS has Secure Keyboard Entry option for the terminal and kinds of secure buffers exists, etcetera then the attacker would need to have a very good keylogger so this becomes less likely to be able to access to the container

SSH authentication by key alone I would say is almost like non existing security if an attacker has access to your user or can just execute a single command e.g. ssh container, not even root necessary because Apple Keychain automatically grants access

I know that AddKeysToAgent confirm exists but the attacker can simply run the ssh command with a different option value and bypass it (confirm option is still nice to forward agents into unsafe containers safely but this is a different topic)

Overall, it's for extra security e.g. imagine you create and manage wallets (private keys) inside a container

[arthurpro]

@LuKks we have release version 0.7 with many features including chained authentication.
See here https://discuss.linuxcontainers.org/t/ssh2incus-0-7-has-been-released/24859

Regarding slow login you mentioned before, that happens only if you have ssh2incus running outside the incus host. If you run ssh2incus directly on the incus host, you should not see any login delays.

[arthurpro]

@LuKks, I forgot to mention that custom banner will be introduced in 0.8 release