I started using tramp with emacs as per the discussion here (Open file via SSH and Sudo with Emacs) in order to use my emacs configs without having to install them on the server/user I was sshing to. Apparently the default setting of this sets HISTFILE=/dev/null, and I got a concerned email from my company's infosec team asking why I was doing this. Is there a way to turn this setting off and log history the normal way? Would like to keep using this tool in compliance with security rules.
Setting HISTFILE=/dev/null is disabled in development version of Tramp, because there is a bug in bash which corrupts /dev/null then. Likely, the security department of your company is concerned about this.
If you have a recent Tramp (say the one bundled with Emacs 24.5), setting HISTFILE=/dev/null is hardwired in tramp-sh.el. You would need to patch it there.
If you install a newer Tramp version like 2.2.12 (see the Tramp manual how to do this), you could use the variable tramp-histfile-override to set your own value. Per default it is set to ".tramp_history", but there are also other possibilities. See the docstring of that variable.
Related
For reasons unknown yet, my MobaXterm Local Terminal will not start any more on Windows 7 box. There is not even a single error prompt of why this may be happening. I am still able to ssh into remote hosts. Could someone please suggest how to turn on logging in MobaXterm of all its events etc. so that I can debug this break?
Alternatively any explanation on why only the MobaXterm Local Terminal may not start in the application would also be very much appreciated.
Thank you very much for your help.
So the workaround for now is to revert to a previous version of MobaXterm (agree.. not the best solution).
-- Uninstalled MobaXterm 9.1
-- Reinstalled MobaXterm 8.6
Not necessarily we need to move to an old revision. I hope we can take any latest stable branches (not installer) portable edition, and use it.
If this works, there was something goofed up in the installer folder.
This portable edition can be continued, for same configuration and other settings, copy and paste the MobaXterm.ini file from your old location and check if that restores all your settings or crashes.
If this crash, this is day clear of the reason, else we have the old favourite restored.
I had this working on a previous work server but I no longer work there and never copied my .bashrc so now I've forgotten what I did since it was so long ago.
Basically I ssh onto my server and then do ide file.txt and it will use the alias ide to open the file in a local app on my laptop.
So my alias now is:
alias ide="/Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl"
I think I was maybe using my IP before but I'm not sure. If it is IP, is there a way to alter it because I am on a laptop and the IP address changes.
You may have been using the rsub plugin, which adapts the rmate remote editing script from TextMate for use with Sublime, allowing for the editing of files on remote servers using SSH port forwarding/tunneling. It comes with three scripts, written in JavaScript (node.js), Ruby, and bash, and you pick one and copy it to the remote server. The README in the rmate-bash repo describes how to set things up.
While I'm at it, I would strongly urge you to check out Sublime Text 3. Even though it's still marked "beta", it is very stable and certainly as good for production work as is ST2. ST2's development is long done, and no more bugs will be fixed in it - in fact, Jon Skinner is already starting to architect ST4! ST3 has an updated Python 3 API and a bunch more features, both under the hood and user-facing. Many plugin authors are now developing just for ST3, and some have even dropped ST2 compatibility altogether because of the differences in the codebases and the API. Others still have ST2 functionality, but aren't developing for it any further, having implemented feature freezes. However, for the time being, lots of plugins work on both versions, including rsub, and for those that don't there are often superior versions available for ST3, such as the redesigned SublimeLinter framework.
At any rate, definitely check it out. I've been using it nearly exclusively for over two years now, and haven't had any major problems. Assuming you licensed ST2 (which hopefully you have if you're using it commercially), the license should also work with ST3, at least until the final version is released, when you'll have to upgrade. Also, if you're a licensed user, you can try out the dev builds, which have some bleeding-edge features (and bug fixes) not in the public beta builds yet. For example, the public beta is currently Build 3083, while the current dev build is 3095.
I am having a problem starting an X2go client session to an Ubuntu work station. Basically, the x2Go-agent does not scale down to fit my client's side screen resolution. Thus, I cannot reach Ubuntu control panels, switch between programs, etc.
I use the newest download of the x2Go windows client, version 4.0.2.0. I use session settings that worked previously, but we have had an update recently. First, I tried playing around with the session screen size, but none of the options gives a reasonable view. I searched for similar issues and found a bug entry that suggests disabling some NX-extension by commenting the line
X2GO_NXAGENT_DEFAULT_OPTIONS+=" -extension XFIXES"
in etc/x2go/x2goagent.options.
This is not possible for me without appropriate admin rights. Instead, I found out from the changelog that the above option can be overwritten from client-side, but it doesn't say how:
Introduce /etc/x2go/x2goagent.options to allow overriding x2goagent
options. This new configuration file specifies default options that
clients can override.
The man-page of the x2Go client doesn't tell, either. It doesn't seem that there is a command line option to redefine the variable during execution.
Here is my question: Does anyone know how to overwrite the above option from a windows x2go client side?
Thanks for your help!
As far as I know the problem is not fixable from the Windows side. But you can fix the issue by disabling "kcreen" in your KDE where the x2go server is running. See the following citation:
In general, this is not a bug. Using two applications that handle display resolution is not supported
I was wondering if there's a way to use Mosh on windows without Cygwin?
I need to be able to put it on my USB drive and copy it over to a windows computer and be able to Mosh into one of my servers. Otherwise, is there a way to use Cygwin and have it portable? I did get mosh working under windows via Cygwin, but that meant I had to add an environment path to the windows computer, which, on the windows computer that I'm working on doesn't allow you to change that, since I don't have admin privileges.
MobaXTerm is portable and supports Mosh.
It works quite well. I spent all day using it on a very dodgy connection and it worked like a charm.
Just get the most recent version and from the Session menu select Mosh. It did does not support IPv6 (at least in Version 9.2 (2016-09-18)):
Bugfix: Mosh sessions are forced to IPv4 only (IPv6 is not yet supported by Mosh client/server)
But it might work now, since Version 10.4 (untested):
We also improved MobaXterm behavior and fixed issues with multi-monitors, IPv6 connections, mouse scrolling and keyboard shortcuts.
Interestingly enough, I wanted MOSH for Windows too, and I find Cygwin to be very messy. Instead, I just downloaded a minimal Text-only Debian distribution, booted it up in VirtualBox, and installed MOSH. Surprisingly, it's much less time consuming and requires less tweaking than going the Cygwin route, and makes less modifications to the host machine.
In fact, there is a portable VirtualBox, so you can put your MOSH VM and Portable VirtualBox on a memory stick.
I haven't even tried to optimize things, but it runs just fine on the 256MB of ram I gave it. It would probably run just fine on 64MB or less.
I do hope MOSH will be built into PuTTY/KiTTY in the future.
I have noticed that a new version of MobaXterm has been released (version 7.1) and includes an intergrated Mosh session.
So, you dot not need anymore need plugin for that.
They said that it is "experimental", but I have tested it, and it is working quite well.
As of now, Mosh has added support for Google Chrome (or any of Chromium Browsers) as an official extension. So you can keep a portable google chrome & use mosh from there.
For Windows, there isn't a single solution install to support MOSH. Rather, you have to sort of "stitch together" a few options to make it work.
MOSH itself does not need ssh or any other initial program necessarily. It is possible to start a session on your server, then using the published connection information, go to your client (in this case your windows box) and use that information to connect the session. This is sort of messy and is the main reason people use SSH to basically establish a connection to the server, remotely start a MOSH server, get the session information back to your client machine, then launch the MOSH experience.
The two pieces you need on the client side (if you make the connection manually) are the server port number and symmetric encryption key. A typical example of one given by a MOSH server would be:
MOSH CONNECT 60001 U0MWPbwn3BdcdMyNLnSFCA
Where 60001 is my port number and "U0...CA" is my encryption key. Don't ever give this out BTW as ANYONE can connect to your running MOSH server with this information (that is, they would look just like an IP change just like you do when you get disconnected and reconnected)
So, back to installation. MobaXterm (currently at v10.5) is a free for personal use app that you can find at https://mobaxterm.mobatek.net/. Installation is relatively straight forward. One word of caution however, their SSH implementation is rudimentary. Basically they support password authentication for ssh. If you use public keys, you cannot have one with a password on it and expect it to work (the code to ask you for your password appears to be missing). This might not be a show stopper for everyone but this is where my company stopped following this thread.
Within MobiXTerm, you want to hit the "Sessions" button at the top left to bring up a new session window. Press the Mosh button on the top right to get the start of your session (NOTE: This is IPv4 only. Zippo luck on getting IPv6 with this to work). Enter your remote host and the username of the ssh account you will be using. If you have an unsigned ssh key, then you can use the Advanced Mosh setting to link that private key with this session (at this point, as a security guy, I'm sort of passing out). At this point, as long as mosh is correctly running on your server (with the 60000-61000 UDP ports open in the server firewall), things should "just work".
Ok, so its not too painful to get working this way. But other than terminal functionality, its not very much fun either. Although MobiXterm is an X-server, I haven't yet gotten X to function over the mobi connection (at least not automatically).
I need to run a program from my windows xP machine thats installed on a remote UNIX machine using MobaXterm but I have very little experience with this sort of thing.
I can login into the machine using ssh and start the program without a problem. That program needs files that I have on my windows computer to process though and I want to copy them over to that remote machine. Unfortunately the drag-and-drop file transfer panel that is mentioned regularly on mobaxterm help sites isn't present and I can't figure out how to make it appear.
Could someone suggest how to get that drag-and-drop panel to appear please? I'm using MobaXterm version 3.0.
Alternatively any explanation on how to transfer these files another way would also be very much appreciated.
Thank you very much for any help you can give.
If it still doesn't work when you try all of above methods, try this:
when you creat a Session, change the Advanced SSH setting-->SSH-browser type to SCP, which default is SFTP.
. thanks to willfurnass
Some Linux distributions or some other Unix systems have disabled SSH password authentication by default.
In order for MobaXterm to be able to launch the SFTP browser, you will have to re-enable this feature:
Edit the "/etc/ssh/sshd_config" file on your server, and comment the following line:
PasswordAuthentication no
Restart your SSH server using the following command: /etc/init.d/sshd restart
Connect using MobaXterm SSH client and you will notice that the SFTP tab will be correctly launched.
If you can not modify your remote server configuration, you can also perform your file transfers inside MobaXterm terminal using SCP. A sample SCP command would be:
scp -r /drives/c/Some/Place/On/Your/Local/Windows/Drive/ yourlogin#yourserver:/Some/Place/On/Your/Remote/Unix/Server/
Ensure you have "Display SFTP Browser" enabled in your session settings under "Advanced SSH settings".
Occasionally it doesn't reappear, which is solved by a restart MobaXterm.
Another cause for the lack of sftp panel is if you accidentally enter and store a bad sftp password. MobaXterm then appears to attempt an automatic log in, but silently fails to open the sftp connection.
To fix this, go to Settings>MobaXterm passwords management and delete the offending password. Here's a screenshot of the settings page, showing the password management link.
To be clear, I had already run through the settings mentioned by #Nicolas and #Didier (thanks, guys!). I was able to get the sftp tab when ssh'ing in to other hosts (which didn't have bad passwords stored). And I had in the past seen the sftp pane. This fix solved my problem.
If you've never seen the sftp pane, then try the other suggestions first.
Have you tried:
Turning the program off and on again?
Note: I read this hint in a comment, which saved me from a tidious process of unnecessary fixing mobaXterm, also I am hence not the only one with that behavior. Even though this might be the first thing you already tried, some might not have been trying and haven't been lucky enough to read through the comments - this is for them.
For the most recent versions, ensure you have selected 'SFTP protocol' in the'SSH-browser' selector: