trib767

Hello, I want to configure SSH access to my server (Linux) that can be accessed via a web browser. Here's the important bit: the comms between the browser and the server must go over HTTP (80) or HTTPS (443).

I just got MindTerm up and running but, while it is a very nice SSH client that runs very nicely in a browser, it does still use port 22.

I want to be able to access my server from any web browser without opening my server's port 22 to the internet and without worrying about whether the browser's local network has 'special' ports open for outgoing traffic. Most places with web browsers will have 80 and 443 open so this is the way to go.

Ideas, suggestions, tips....

ratbastid

You could take down the web server and configure a SSH server to use a custom port, 80 or 443. But you can only have one server listening on a given port. So while you've got your SSH going, you'd have to do without http or https.

I've seen CGI-like applications that mimic the shell by taking command line arguments in a form field and excecuting them on the server. There are major issues of security and usability there, though--obviously, your shell is exposed over the web browser which scares me silly, and you're only able to operate as the web server's user, which won't get you very far anyway.

beejay

Yeah, you really have to be careful about opening port 22 to the world. Since ssh/sftp/scp, etc run off of the same port, you really open up a hole that you don't want to mess with...

Can you use a webshare over https instead??? That's what we do in the Windows world. It authenticates using AD. You may be able to do the same thing using ldap....

__________________
Pimps and Ho's - it's this generation's cowboys and indians

trib767

I am not going to open port 22. The only ports that will be open are 80 and 443. So my ssh client will have to somehow "tunnel" over one of these two ports. I prefer 443 as that can be wrapped in SSL security too.

I'll post the solution here when I have one. I'm pretty certain this can be done. I have the bricks but need to get the mortar.

beejay you mention ldap. This is just a directory service - I already use it as my central user-data repository on my domain controller. I'm not sure how it fits into a web tunnelling scheme ?

ratbastid

Well, hang on there. There's nothing inherantly scarier about one port over another. And there's nothing magically secure about port 443. A port is a port. It has a server running on it. Those servers have functions. End of story. Port 443 can be "wrapped in SSL security" only if the server behind that port provides that function. I don't even know what you mean by that.

Port 22 is the common port for ssh (and scp, which is provided by sshd, but not sftp which is a different thing altogether). As a result there will be doorknob-rattle attempts on port 22 more than on other ports, maybe, but that's really all. Choose decent passwords and you'll be fine.

Now, ssh tunneling is a whole other issue. With ssh tunneling, you can route OTHER protocols and services over an ssh-encrypted connection. Protocols like X or POP or ftp, for instance. It doesn't have anything to do with putting ssh on a non-standard port. You could route your https traffic through an ssh tunnel on port 443, but that would require all https users to have a live ssh connection to your server, which you probably don't want.

You haven't said what distro you're using. To put ssh on a non-standard port, you either use inetd or you configure the server manually to its own port, in whatever config files your server comes with. That's pretty much it. My Windows ssh client of choice, PuTTY, lets you specify the port to connect with.

In short, if you can trust an ssh server on port 443, you can trust it just as well on port 22 (or 2222 or 2020). And there's no way to put ssh "behind" http or https, though if you really want to--and everyone who's hitting this website has an account to ssh to--you can route those services through ssh connections.

I recommend you open up one non-standard port for ssh. Look, you could just turn the computer off and it would be 100% secure, right? What you want here is to balance security against usability. That's the whole game with practical security management. As long as you keep up with patches, sshd should be adequately secure, even running on port 22. scp uses the same security functions as ssh, so there's no additional risk to letting that run. And I'm speaking as a guy who has had two dozen servers get completely pwned due to out-of-date sshd patches. Entirely my fault--I didn't keep up with it and I got what I deserved. Don't do that. I don't anymore!

Just out of curiosity: You keeping state secrets on this box? Why isn't the industry-standard secure shell application secure enough for you? Are you unable to open additional ports on your router or something?

bendsley

You do know that AD uses LDAP and Kerberos to authenticate against right?

As far as sFTP is concerned.

The common method for most Web users to transfer files to and from their Web hosting account is to use an FTP Client. Easy-to-use graphical user interfaces (GUIs) allow the user to drag and drop files between local computer and remote server - in a very easy manner. FTP clients allow the user to upload/download files, change file permissions using CHMOD command and more. All very convenient.

However, FTP and Unix command operations such as RCP are not secure. Packet sniffers can quite easily capture usernames, passwords and file content. If you have your own server, then you most likely know about FTP vulnerabilities. For the 'average' Web user, the 'sniffing' opportunities FTP and RCP provide (by sending the information 'in the clear' as ASCII plain text) are not known by many.

SSH1 combated this issue to an extent by using what is known as 'Port Forwarding' (aka SSH tunneling). FTP traffic (which uses standard TCP connections) can be port-forwarded over secure shell - preventing username and password sniffing. However, the file content must be transferred outside the secure shell over an unprotected clear text data connection.

SSH1 used 'port-forwarding' RCP (Remote copy) and FTP tunneled over a secure shell session. SCP (Secure copy) is the name used to refer to port-forwarding of the RCP command.

SFTP - Key Points

* SFTP doesn't require an FTP server - it operates on the SSH server.
* SFTP protects every piece of information sent over the network. Usernames, passwords and the data.
* An SFTP client running SSH software encrypts and tunnels traffic to a secure shell server, where the tunneled stream is decrypted.
* FTP, RCP » Data not encrypted. Username, password and data is sent in the clear. Prone to packet sniffing.
* SCP, FTP over a secure shell » Username and password is encrypted, but data is sent in the clear.
* SFTP is ideal for use by businesses who need to send sensitive information securely » company reports, financial statements, confidential files and so on. SFTP is ideal for secure file transfer within and between businesses.
* The server you are connecting to must have an SSH server installed (with SSH2). Most servers have Open source SSH servers already set-up (Openssh.com). There are also a number of commercial SSH servers on the market.
* Connecting to an SSH server with an SFTP client is very much like you would with an FTP client - with 2 exceptions. 1) You connect using the SFTP protocol: sftp://www.yourdomain.com. 2) You connect to Port 22 (The SSH port), NOT Port 21 (The FTP port).
* SFTP clients are readily available for download - both FREE (open source) and commercial versions for use on both Unix, Linux and Windows OS platforms.
* Using an SFTP client is easy-as-pie - just like it is when connecting with your favorite FTP client (which may in fact already support SSH2 connections and SFTP).
* SFTP may also use many features of SSH such as public-key encryption and compression.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

trib767

I want to be able to log onto my box from remote locations. I can't guarantee that outgoing connections on port 22 will be allowed. I can guarantee that if I try this from work that it is most definately not allowed. The only outgoing ports allowed from work are 80 and 443. Hence I need to do this over one of those ports.

There's something called "corkscrew" out there that seems to do this but I haven't got to the bottom of it yet.

Ideally I want to be able to point a browser at my web server and somehow get an ssh login going. I have the browser bit working with a java ssh client called Mindterm but that still uses port 22. I need to sort that bit out next

ratbastid

Aha. Now I understand your limitations. Really, no OUTGOING 22? That's surprising. I can totally get blocking incoming port 22 connections (or maybe forwarding them someplace other than to you), but blocking the outgoing port is just harsh. Maybe you've got a friend in IT who can relax that for you?

Okay, well, set up your sshd to run on port 443 and forget about https. Or... Figure out some way to trigger the server to switch what service is running on that port.

Then (and here's the main thing) go download PuTTY. It's a very nice windows freeware app. It lets you specify the port you want to ssh to. Yes that means you have to have it on your desktop rather than pulling your client down from the server, but... Maybe you could stick it on a flash thumb drive or something.

trib767

This is exactly what I've been thinking!! I was wondering if there is some kind of proxy that will recognise incoming connections of different protocols and send them to different services.

I don't want to have to kill off my web server (I use 443 for other web based things).

Yes my company is harsh. They close everything in both directions unless there is a business reason for not doing so. I can understand why they do this though.

I use PuTTY on machines I regularly use and I'd thought of just changing the port it connects to but, as I said above, I was hoping not to have to sacrifice one service (httpss) so another (ssh) can use it's port.

yotta

if the web server is apache, you could use mod_proxy to tunnel to the ssh server...

Make sure mod_proxy is turned on, and add the following to your httpd.conf

__________________
I am Jack's signature.

trache

To scan packets to have a program proxy your request to another is suicide. Your router is not likely going to be able to do it (unless of course you have a sophisticated one), and at any rate, the service/routr/firewall will be too bogged down by trying to filter requests that it won't be worth it.

That's likely one reason SysAdmins at large corporations try to limit their firewall rules to the bare essentials.

WeirdX is an X-Windows JAVA client that can run in your browser. That may or may not suffice.

Are you sure you cannot run your web server under port 81, 8080, 8000 or something similar? Why not try accessing your web server through another proxy service such as The Cloak? They should be able to bring you the pages you request over any port to you no problem.

__________________
"You looked at me as if I was eating runny eggs in slow motion." - Gord Downie of The Tragically Hip

trib767

I've come across GNU httptunnel. Anyone got any experiences. It seems it might be the answer ?

j8ear

Damn, that was particularly well said.

Kudos

-bear

__________________
It's alot easier to ask for forgiveness then it is to ask for permission.

yotta

Mindterm has built in HTTP proxy support, so just enable that, and use the apache mod_proxy config I mentione before. This will put SSH and HTTP on the same port. I tested it on my server after posting, seems to work just fine.

__________________
I am Jack's signature.

trib767

Isn't the Mindterm proxy settings referring to the "local" proxy that is on the same local network as the browser. The mod_proxy apache config would need to be on the "remote" web server at the destination network.

I've got apache config for mod_proxy so it can "AllowCONNECT" to port 22 but that is on my host. My apache is not the local proxy to which Midterm directly connects.

Or maybe I just don't understand how proxies work ?

yotta

No, the proxy can be any machine. Using your server as the proxy will work fine. Also, please make sure you use the access control restrictions I listed, or else some clown fill find the proxy and abuse it.

__________________
I am Jack's signature.

trib767

Thanks very much yotta that works perfect. Next thing is to test it from work!

Also do you know if it is possible to do a proxy connect over https ?

trib767

Ok, I have another problem. I need to proxy-chain because I HAVE to use the proxy at work to get outside and then I need my server's proxy to be used as this does the AllowConnect.

Can Mindterm or PuTTY be used with a proxy chain ?

yotta

Have you checked to see if the proxy at work will allow you to connect? (telnet in to the proxy and do 'CONNECT yourhostort HTTP/1.0' and see if it connects.
PuTTY will work fine with a proxy chain, mindterm will not unless you have a signed copy (due to java security restrictions). I don't know about chaining proxies from windows, I'd start a new thread for that, but putty should be fine with it.

Final note: MAKE FUCKING SURE YOU WILL NOT GET FIRED FOR PROXY CHAINING!!!! Ask the IT guys if it's OK, and GET IT IN WRITING.

__________________
I am Jack's signature.