Description Peter Åstrand 2006-01-04 08:40:24 CET

I've transferred comment #4 from bug 1283 into a separate bug:

---
I have an idea for another enhancement. Currently, the client uses the same
entered password and username for both SSH connections. Instead of this
approach, vsmserver could report back the username and password that should be
used for the second SSH tunnel. In some cases, this might give some flexibility.
Consider for example a setup with one time passwords. Currently, we have
problems, since we need to use the OTP twice, so currently, we require a token
caching server or a NE server, which allows using the same OTP twice. If there's
a possibility of getting a new OTP on the serverside, without input from the
user, vsmserver could fetch this new OTP and report it back to the client. Thus,
we could support OTP solutions without using the OTP more than one time. 

I got this idea from RDP: When using the load balancing / session directory, the
first RDP server apparently reports back a username and password to use for the
new RDP connection. 
---

I think this feature is independent of the rest of bug 1283. It should be
possible to implement this simply by having vsmserver add the credentials to the
do_login response, and having tlclient use these if available. We can consider
both password and pubkey credentials. 

One idea is that vsmserver could actually report a "fixed" username/password
pair, so that all users could create the second SSH tunnel using this username. 

Advantages:

* ThinLinc would then only need to authenticate the actual user once! This, in
turn, means that any OTP solution could be used. The problems with Novell
gracelogins would also go away. 

There are disadvantages, though:

* If all users are connecting using the same username, it will be harder to
debug and audit the system. Questions like "Who has created a tunnel from the
Internet to our internal eDirectory server?!?" will be very hard to ask, since
the sshd processes will be more or less anonymous. Also, if a malicious user
gains knowledge of the username/password, he could create arbitrary tunnels. 

The "fixed" user could have /bin/false as a shell, though. 

Instead of using a fixed username/password, the system could be setup so that
each user has an extra "alias" account. vsmserver could change the password for
this account upon do_login. This would mean that vsmserver could basically
create an OTP solution for the second SSH connection. 

If solving this bug, the server side should be flexible. We could, for example,
have the credentials generated by an external program that recieves the username
and password for the first SSH connection on STDIN and writes the credentials to
use for the second tunnel on STDOUT. By default, this program could be /bin/cat,
meaning to use the same credentials for both tunnels. 

One additional note: Nomachine are actually using an "anonymous" user. It's
possible to start the login shell by running:

ssh -i /usr/NX/share/keys/server.id_dsa.key nx@testdrive.millenux.com 

They are using a known_hosts file that prohibits use of forwarded ports, though.