combining port knocking with sshfs and autofs ?
 

is there a way of combining : automount, sshfs & port knocking ?

specifically, is there a method to include a shell command (knock or nmap) in the client-based autofs files (master, misc etc) to be called at activation time for a given autofs mount point ? i need the server-based port knocking daemon to open a particular port for the ssh(fs) handshacke to happen.

i don't know otherwise how to include the port knocking method as an added safety feature for exporting home directories over the internet.

sshfs is a fuse filesystem that uses sftp so you have to map the directories per each user. autofs does have an executable map feature so you could add the port knocking script.

https://docs.oracle.com/cd/E19455-01...9g7/index.html

In the following link the author added sshfs to the GDM ( i.e the login manager ) but the exact method would depend if you are running a desktop and which one. You could add the port knocking script to the PostLogin.

https://www.staldal.nu/tech/2010/08/...shfs-in-linux/

While I've experimented with autofs sshfs I have not used port knocking or tried with a remote home directory.

Don't bother with silliness like port-knocking: use OpenVPN! (With digital certificates and tls-auth.) :tisk:

OpenVPN acts as a cryptographically-secure TCP/IP Router, through which any sort of traffic can be passed. It is impossible for anyone on the outside even to detect that the "tunnel" exists(!!), much less break into it. (A port-scan of your IP should show no(!) open sockets.)

And yet, to the authorized users, the remote network is "simply there." Bearing the necessary un-revoked certificates, they approach the hidden door and pass right through. Once the tunnel is made, the IP addresses on the other side appear to be "local." But the OpenVPN server is in secure communication with its peer, whose identity is positively known. You can now use file-sharing or anything else that you please, through the tunnel, knowing that no one can interfere. You know that you must be talking to the intended party, with no "man in the middle." You know that "Eve" cannot eavesdrop.

If you choose, you can now use very simple strategies such as NFS or Samba to share your files, knowing that the tunnel that connects the two systems is secure and reliable. It is not necessary to take further security or authentication measures. You can simply treat the remote as "a trusted part of your internal network."

Certificates not only make it completely impossible to "crack your way in," but they also enable the two parties to positively identify themselves to one another – not based on what anyone "knows," but on what they mutually "possess." (Furthermore, any of these materials, if ever compromised, can be revoked without affecting what is possessed by any other still-authorized user.)

If you want to use ssh to provide "a second line of defense," feel free to do so. But arrange for sshd to listen only to the VPN tunnel, and use firewalls to make damn sure that no other traffic can pass either out or in except through the tunnel. One must first clear the tunnel before being given an opportunity to use, or even detect(!), ssh.

"Number of open ports found by a port-scan?" Zero!

"Number of unauthorized access attempts?" Zero!

thank you for your helpful suggestions, sundialsvcs and michaelk !

VPN : i am aware of VPN and used/implemented OpenVPN in previous projects but in our current scenario i think we should go with a flexible SSH solution (in place) - but add on this silly-neat port knocking just for further enhancing & obscuring security. i understand that VPN is quite an advanced technique but we deal here with an R&D group of techies scattered across three continents who need to work together on a single computing environment to which we login using ssh & vnc.

executable maps : i was able to use this truly flexible autofs feature and call the knock program (or any other program for that matter) - but the rest of my auto.master services got screwed up that way and refused to work as before. how can i timely arrange that an auto.exec file is called user-specifically first - and a user-specific auto.USERx file only thereafter which is then going to invoke fuse and sshfs ? should i do this within the auto.master file ? with direct or indirect maps ? is there a way to serially chain autofs maps and invoke them sequentially ?

i saw that autofs is able to use the output of executable maps to subsequently mount a directory - i am just not sure about the syntax for a complex string needed for sshfs such as used in the auto.USER0 file :

are you aware of solutions for this scenario ? should the corresponding line in an auto.exec_USER0 file look the following way ?

called via this line in the auto.master file :

what do you think ? i am this minute not in front of my computers, so i couldn't test this scenario yet... and where to include UID and GID ?

Please, go back and re-read the above paragraph, and think about it for a few minutes.

If you have a group of researchers on three continents, and you're using VNC to log in, you're pretty much lost from a security standpoint off the bat. OpenVPN is robust, and trivial to work with. It won't interfere with you mapping drives with SSHFS, Samba, NFS, or whatever else you need in the future, essentially because the remote machines act as if they're on the local LAN once connected. If you truly want flexibility, scalability, and security, use the correct tools. OpenVPN works on Linux, Windows, Mac, Solaris, and pretty much any other platform you care to name, as well as being built-in to many appliances (Untangle, for one). ALL of them work together easily.

Putting your port-knocking into a script, gives anyone who looks at that script the information to negate your port-knocking. All you're doing is making things harder on the administrators, and less secure for the environment as a whole. I do think you hit port-knocking on the head when you called it "silly-neat"...because that sums it up nicely. It's fairly silly to use it and think its secure, and its only a 'neat' factor. You don't enhance security at all using it; strong crypto enhances security.

If they log in via SSH, then OpenVPN works great...if you really use VNC (which opens ANOTHER set of security holes doing a GUI over WAN), then you've already made your environment less secure. Your folks can use X forwarding to run any X apps over the VPN tunnel, WITHOUT VNC.

I agree with TB0ne. Your present situation is insecure, and stuff like "sshfs" and so forth is by comparison difficult to work with. (It is very easy to think that you are secure, when you're not.)

Conceptually, OpenVPN (in the usual "tunnel" mode ...) is very easy: "it is a secure TCP/IP Router, implemented in software."

All of your researchers, no matter where in the world they are, can simply "open the tunnel," and give no further concern to communications security. If you wish, each of them can set up non-overlapping local-IP addresses and then they can convey information directly, not only with the OpenVPN host server, but also with one another. To each and every one of them, the remote subnets are "simply, there." It so happens that the connection is protected by fairly-bulletproof cryptographic security, yet from the point-of-view of each user, "it's invisible."

Now you're free to use whatever communications solutions you like ... VNC, NFS shares, Samba. You no longer have to be concerned about security within each protocol, because the tunnel through which all communications must pass is secure. You can simply go about your business.

If(!) you use certificates in the way that I recommend here, connecting the tunnel is the matter of a few seconds – and you can be certain of the identity of the server to which you are connected. If information is being transferred directly from one OpenVPN client to another, each of them can also be certain of the identity of each and every other party. If anyone's equipment gets stolen or compromised, anywhere in the world, you can block that machine's future access selectively.

In the crazy hostile world of the Internet ... "peace and quiet, confidence and reliability." You will not encounter interference, nor "unauthorized access attempts," because the outside world can't even see(!) that there is anything there: nothing to attack, nothing to attempt to enter. (Although you are using TCP/IP within the tunnel, the tunnel itself is not.)

"Port knocking?" (Chuckle, 'why bother?') "sshfs?" (Ditto.) "How 20th Century!" ;)

Just go ahead and switch to OpenVPN and all of your colleagues will appreciate you for it. I assure you that their reaction – and yours – will be: "This is so much better! Why didn't we do this a long time ago?" :confused:

You'll find plenty of experienced help here at LQ.

i listened to your advice - and then i listened on our 'trans-continental' servers to port knocks which rarely wanted to arrive as a complete quartet or quintet - though i am not sure why, distance perhaps may have scrambled their sequence. in any case, this last trouble became then the nail in the coffin of our port knocking efforts. so, after much listening we decided to pursue the VPN avenue...

thanks for everybody's input !

You're welcome, but again, I urge you to re-read what you just posted here. You are flat-out saying that you were able to listen for the knock sequences...but you say the 'nail in the coffin' was the fact that SOMETIMES they didn't work? The real problem is that if you were able to listen to them, then SOMEONE ELSE is able to listen, too, and could capture/replay them easily. This is why good security is a process, and there are no quick fixes.