At a couple of places in the past, I've set up an SSH jump box to allow access 
to internal systems. Each person with login access to the jump box had his/her 
login shell set to a script (jumpsh) that brought up a prompt immediately after 
logging in. The user would need to enter one of the codes matching an internal 
host in a configuration file; if one of the correct codes was entered, an SSH 
session would then be initiated to the matching internal host. (There are 
limited tries before logout, and delays between tries, to defend against 
attacks.) You couldn't get a normal command prompt on the jump box itself 
(unless you had a code configured for "localhost"). This system requires 
successful authentication on the jump box (depending on how you've configured 
sshd), knowledge of at least one of the codes in the configuration file, and 
then successful authentication to the internal host (usually key-based). More 
details are here:

        http://www.occam.com/tools/README.jumpsh-3.1

with jumpsh (a simple Perl script) downloadable here:

        http://www.occam.com/tools/

In addition, it's best if the jump box is on a protected DMZ.

And it's a good idea to have the SSH service listing on a non-standard port, 
either with a network device that does port mapping, or by specifying an 
alternate Port in sshd_config. It eliminates the usual storm of people trying 
to break in; I was shocked at how the rogue login attempts disappeared after 
doing that. It also adds one more thing that a legitimate user needs to know to 
log in.

--------------------------------------------------------------------
Leon Towns-von Stauber                  http://www.occam.com/leonvs/
"We have not come to save you, but you will not die in vain!"

On Mar 20, 2014, at 7:26 AM, Kenton Brede wrote:

> Years ago when I started administering linux boxes, some of our boxes had 
> sshd open to the world.  So I devised kind of "poor person's" two-factor 
> password authentication.  It worked like this:
> 
> admin1: could login to the system and su only to admin1ad.
> admin1ad: could not login, could su to root.
> 
> Currently for all of our boxes, port 22 is behind a VPN.  Some of us are 
> using ssh keys for the initial login but password authentication is still 
> enabled.
> 
> I'm thinking about disabling password auth, using keys only and passwordless 
> sudo access.  Everyone would just have one user account.  It sounds like at 
> some point we'll be moving to two-factor for our VPN.
> 
> Is this pretty much standard practice these days?  Is it reasonably secure?  
> If not, how are you all handling ssh authentication?
> 
> Thanks,
> 
> -- 
> Kent Brede
> _______________________________________________
> Tech mailing list
> Tech@lists.lopsa.org
> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
> This list provided by the League of Professional System Administrators
> http://lopsa.org/

_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to