ssh proxy for DMZ?


    A requirement has come up for the implementation of an ssh proxy in our dmz to proxy inbound and outbound connections.  I was wondering how I'd go about setting up an ssh proxy that can be used from the clients command line (like the suse ftp proxy).  Use of a socks proxy is not an option, it needs to be something that can be specified in the username field on the client side.  Please let me know what you've got.


Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

do you think of a transparent proxy?
Inbound or outbound?
Do you realy mean a proxy, or something fomerly known a "bastion host"?
convex001Author Commented:
it will be in the middle of a firewall sandwich, so I don't know if you could really consider it a bastion host.  But it needs to be as transparent in the sense that users shouldn't be connecting to a shell on the machine...let me give an example of how the ftp proxy works;

- make a connection to

- as a login name use


- as a password use the target_ftp_server password


I would like to connect to, with a login name "myname" and a

"mypass" password:

- connect to

- login name:

- password: mypass

I'd like to see this done with ssh and sftp aswell.  any ideas?


use folloing script as shell for your user (myname) at the proxy, then connect like:  ssh myname@proxy
It works with ssh -port-forwarding too, not shure for sftp (which is obsolete when having scp).
Keep in mind that you probably need to adjust some things for the -T switch
.. and to be improve in many ways ...

I'll await you donations ;-))

#! /usr/bin/perl -T
sub sane { my ($sig) = @_; exit( 1 ); }         # be very pedantic
foreach $s (keys %SIG) { $SIG{$s} = 'sane'; }
($host, @ports) = split( /\s+/, $ENV{'SSH_CLIENT'} );
print "hostname: ";
$host   = <>; chomp $host;
print "username: ";
$user   = <>; chomp $user;
# we allow hostnames which must be defined herein, 'cause we've no internal DNS
%hosts = ( 'marvin'=> '',);

if ( grep( /^$host$/, keys %hosts ) != '' ) {
        $ip = $hosts{$host};
} else {
    $_ = $host;
    if ( m/^\d+\.\d+\.\d+\.\d+$/ ){
        $ip = $host;    # IP as hostname is ok
    } else {
        exit( 2 );
#print "#dbx: /usr/bin/ssh -l $user $host";
exec "/usr/bin/ssh", "-l", $user, $ip;
exit( 3 );

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
The problem with ssh is that it's end-to-end secure.
a HTTP or FTP proxy effectibvley executes a man-in-the-middel attack, pretending to be the server for the client and visa versa.

I believe MS has such a web-proxy for HTTPS. It pretends to be a fake CA, then generates fake certificates for all the sites you go to using https. Using the fake certificates it is able to re-encrypt the traffic in such a way that your browser trusts it (after manually iporting the original fake-CA certificate).

I guess you could do something similar to ssh, but it does introduce a common weakness to all ssh comms.

You could run a web-based ssh client on the DMZ server, so from inside the company you browse to, a web-based ssh client starts up and you use that to connect to the outside world.

I guess it really depends on what problem you're trying to solve, i.e. why you're not just letting internal systems connect directly.
you can proxy the traffic via an http tunnel thru a proxy server.

take a look at this, it describes how to do it.

my strong advice to you however is to use a bastion host in your DMZ, you should never allow this sort of connection from unknown networks. They should come into a secure and monitored bastion and from there they access your internal resources.

What your doing is very risky and becuase its encypted, you will not be able to monitor it.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Security

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.