Refactored bl-sshconfig-pipemenu.

[tknomanzr]

The current version's terminal menu entries do not work, as well as the file manager entries. This version fixes both entries, at least for me. Assuming a correct ~/.ssh/config, both menu entry variants should work now. https://thumb.ibb.co/kwgF2n/Screenshot_2018_03_08_16_47_06.png

[tknomanzr]

I linked the thumbnail. Doh! https://image.ibb.co/icov2n/Screenshot_2018_03_08_16_47_06.png

I think I can simplify this pipe-menu down even further. Consider this ~/.ssh/config entry:

HOST webber HostName ip_address User username IdentityFile ~/.ssh/nas_rsa

If I run

ssh webber

ssh resolves the HostName, User, and Port from the HOST entry. So the pipe-menu script only really needs to run the ssh command against the HOST entry. The pipe-menu script can skip all the rest of the entries in the config. Please don't merge yet. I am going to simplify this down a bit.

[johnraff]

Thank you for this! Confirmed the terminal session opens on my system, prompts for the password and acesses the remote system OK.

(Just noticed your update - I was wondering the same thing. The ssh config alias should be enough.)

I have two old entries in my ssh config file, which are no longer allowed access. In those cases the terminal closes immediately - it might be nice to have an opportunity to see the error message first. I don't think urxvt's -h option is universally supported by x-terminal-emulator, so the only way I can see is to open a shell first, something like: x-terminal-emulator -e sh -c ' ssh_command || echo "SSH error. Press any key to close"; read' The python escaping and quoting I leave to you. I don't know if the extra complication would be worth it?

---

I can't test the file manager access because my ssh remote server does not have /shares/Public. Is sshfs necessary for this to work? If so, we'd have to make it a dependency (or Recommend) of bunsen-pipemenus. It's quite a small package, so that might not be any problem. Actually, adding sshfs to bunsen-meta-ssh might be the obvious way to go, and the pipemenu could test for the absence of either sshd or sshfs in order to offer the metapackage install.

[tknomanzr]

This commit should allow you to use the file manager entry. Apparently, I had set the code to map to the actual shared folder on my file-server. This commit just uses the HOST entries.

As for error trapping, it seems that the default behavior is just to exit the terminal on errors. So tracing through the calls, it seems that we would need to trap that error somehow in Bash. I will need to think more on this.

[tknomanzr]

I tried this command for the terminal ssh. It still doesn't seem to trap the exit:

x-terminal-emulator -e sh -c ' ssh_command || echo "SSH error. Press any key to close"; read'

Python output:

x-terminal-emulator -e sh -c ' ssh temp || echo "SSH error. Press any key to close"; read'

Temp is an intentionally broken config entry. Another small gotcha is that the library that parses the config, paramiko seems to lowercase the HOST entries, so I had to convert the one that I had in uppercase to lowercase.

My thinking is this: We need to link the pipe menu into a bash script that accepts the HOST entry as a parameter. This script then issues the command based on the HOST entry. I think in this way, we can keep control of the terminal. We can roll with it this way and chalk this up to further improvements to the scripts later or if someone better at Bash than me could write up a script that builds a proper ssh command with the HOST entry as a parameter, we could then call that script via the pipe-menu.

[johnraff]

Sorry I should have actually tested that command! It works as-is with bash instead of sh, but read with dash needs a variable name as argument. For a trivial job like this it seems wasteful to call up bash - this should work as python output: x-terminal-emulator -e sh -c ' ssh temp || echo "SSH error. Press any key to close"; read REPLY' except that this code is going to be sent to openbox as an xml menu entry, so the quotes might better themselves be escaped: x-terminal-emulator -e sh -c ' ssh temp || echo "SSH error. Press any key to close"; read REPLY' I think that should work without having to invoke a separate shell script.

[johnraff]

BTW for file-manager access, how is password input handled?

[tknomanzr]

It is actually sftp piggybacking over ssh I believe. In fact, I turned off ftp on the server and checked that I still have write access to the server. gvfs takes care of creating the network mount for it.

Here is some gvfs output from journalctl -xf (on my desktop I follow both journalctl and ~/.xsession-errors continuously.)

Mar 09 12:15:14 wtfbox gvfsd[1254]: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Permission denied Mar 09 12:16:29 wtfbox gvfsd[1254]: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Password dialog cancelled Mar 09 12:16:47 wtfbox gvfsd[1254]: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Password dialog cancelled

Once you login the dialog shows

sftp://HOST/

Things I have learned: If seahorse is installed, it will store the keys for sure. I typically don't install seahorse, so I will check how the secret storage works on an install without it. However, I had a bad entry store in seahorse that was causing one of my ssh config entries to fail because it was trying to login with the wrong username. Just something to be aware of. I am interested to see if ssh-agent will properly store the keys. Even if it is just temporary storage, that is ok. I am not so sure permanent storage of key secrets is necessarily a good idea.

[tknomanzr]

Here is another scrot showing ssh reporting the error and the press any key to exit message. This works! Thanks a ton! That's the beauty of FOSS right there. It would have probably taken me days to figure out that bash one-liner.

I am going to push a commit with the new bash syntax for opening terminals. I'll check here in a bit about how key storage works on a machine without seahorse installed. For the record, sftp seems to have better performance for file copy/move operations than sshfs so for me it's a double win.

Edit: Actually since we have ssh reporting the errors now, we can safely remove the SSH error part of the Message and leave the Press any key to close this window message.

[tknomanzr]

I can confirm that the key storage seems to work independent of seahorse, so it would appear that ssh-agent is working.

tknomanzr@testbed:~/bunsen-pipemenus$ apt-cache policy seahorse seahorse: Installed: (none) Candidate: 3.20.0-3.1 Version table: 3.20.0-3.1 500 500 http://deb.debian.org/debian stretch/main amd64 Packages

[johnraff]

sftp seems to have better performance for file copy/move operations than sshfs

What package are you using to support sftp? There seem to be a number: https://packages.debian.org/search?keywords=sftp&searchon=names&suite=all&section=all

Can most filemanagers (at least candidates for bl-file-manager) be expected to support ssh:// URIs without any further configuring?

About ssh-agent: I've been using it for some time now with no problems. I don't load the password automatically with every boot though, just run ssh-add ~/.ssh/id_rsa (or path to ssh id file) the first time I need it, and for the rest of the session ssh connections are made automatically. Gnome-keyring can be used instead by editing ~/.config/openbox/environment: export $(gnome-keyring-daemon --start --components=pkcs11,secrets,ssh) See: https://forums.bunsenlabs.org/viewtopic.php?pid=18426#p18426 https://forums.bunsenlabs.org/viewtopic.php?id=1281

[tknomanzr]

I can confirm that the ssh:// mounting (it actually transforms into an sftp:// url that piggybacks over ssh) works in both Thunar and Pcmanfm. Gvfs is the underlying abstraction layer. More Info: (http://edoceo.com/howto/xfce-custom-uri-handler)

Using Thunar to browse remote locations Since Xfce 4.8 (Thunar 1.2) it is possible to browse remote locations (such as FTP servers or Samba shares) directly in Thunar. To enable this functionality ensure that gvfs, gvfs-smb and sshfs packages are installed. A 'Network' entry is visible in Thunar's side bar and remote locations can be opened by using the following URI schemes in the location dialog (opened with Ctrl+l): smb://, ftp://, ssh://, sftp://, davs:// & followed by the server hostname or IP address.

For the file manager stuff, I am pretty sure sshfs is going to be a dependency. If I take it out, the file manager closes immediately when I click the link. Add it back, and the connection works.

[johnraff]

The new pipemenu works for me, both terminal and file manager. I didn't have to install sshfs - Thunar opened the remote server with an sftp:// protocol, and displayed everything. A GTK window came up for my password, and offered to keep it for the session or indefinitely. I don't know where it would have been stored - I chose not to keep it at all. If the password is already loaded in ssh-agent then it goes straight in.

After installing sshfs this behaviour was unchanged - maybe if I reboot it will use sshfs? What protocol do you see in your filepaths?

(EDIT: gvfs is aliasing ssh to sftp in /usr/share/gvfs/mounts/sftp.mount)

[johnraff]

Experimented with sshfs. It will use the aliases in .ssh/config but (unless I'm missing some gvfs shortcut) it does require a directory to mount the remote file system on. Thunar can then open it. Navigation might be slightly faster than with sftp, and opening files in a local editor seems significantly quicker. Maybe the whole directory is downloaded and mounted? The commands I used (assuming the ssh/config host is server)

mkdir mnt # should be a user-owned dir
sshfs server: mnt # remote system now on mnt
thunar ~/mnt
# now finished
fusermount -u mnt
rm -r mnt

Up to you whether you consider the speed gain to be worth the extra complication of building it in. One problem is the cleaning up (fusermount -u, remove dir) you'd have to do afterwards. Unless there's a way thunar can use sshfs directly it might be too messy.

[tknomanzr]

Ok. Great. I'm dealing with a lot of latency these days.Lightning hit our septic system but I suspect it also damaged the microwave internet receiver. Gvfs hates high latency networks, so I end up with all sorts of strangeness and lockups. I wouldn't worry about sshfs then. I believe the links will work for any file-manager capable of working with gvfs.

[johnraff]

btw, I edited above (EDIT: gvfs is aliasing ssh to sftp in /usr/share/gvfs/mounts/sftp.mount)

And I just found that sshfs is based on sftp anyway, so there's no reason it should be faster... ...even though it seemed to be. There also seem to be some subtle differences in the way files are handled, between thunar/sftp and looking at a fuse-mounted directory.

Anyway, the menu now works! Lets just be glad, and move on. Thanks!

PS if you have nothing to add, I'll merge it in.

[tknomanzr]

Ok. One last commit to put my name in there. It's all good to go now.