If you end up finding that you must accept plaintext telnet inbound due to the countries in which your folks may go,
you may wish to consider the following instead of permitting broad use of plaintext inbound:
1) setting up a bastion host that accepts telnet, and having them ssh from there to the real target host(s).
2) deploying a one-time password service (e.g. SafeWord, or SecurID) so that an intercepted session does not divulge a
3) configuring the bastion telnet daemon to accept only one inbound shell per UserID concurrently.
Of the two example OTP products above, I would favor SafeWord since its passwords are truly one-time and are not accepted even if
replayed promptly (the user must press the token's button again, to generate a new password if they need to reconnect).
RSA's OTP may have incorporated that feature since my experience with it, but if not its passwords may be at risk of re-use
during their ~1-minute validity window.
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of jeff murphy
Sent: Wednesday, November 19, 2008 12:20 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] VPN/ssh and foreign travel
We're trying to eliminate use of cleartext password transmission
access to university systems. One point of discussion involves
with US export controls. What I'd like to hear from you (sec () educ)
your thoughts on whether it's practical to require encrypted access
given the export issue?