Earlier quoted context omitted.
Mosh would be so great if it worked with the mouse.
Isn't that called remote desktop?
Terminals can have mouse support. It works with some TUI apps like vim.
SSH hacks – a little sanity for remote workers
181–190 of 230 posts
Re: SSH hacks – a little sanity for remote workers
#182Earlier quoted context omitted.
> It would put your password into your `~/.bash_history` I'm fine typing (or pasting) my password in an interactive prompt when I'm interactively using it; that's not the problem. What I would like a --password option for is when I'm not interactively using it, like from a script. It'll still show up in the process list (ssh could overwrite it but there are some µs where it's there) but my laptop is single-user so th…
It's quite likely that what you want in this case is to use SSH forced commands with sshkey auth and a remote account exclusively dedicated to serving this one request. https://binblog.info/2008/10/20/openssh-going-flexible-with-...
But that would be server-side, if I'm reading it right? I'm trying to remember the last time I needed password auth and wanted to do it in an automated fashion (like I said, it is rare), I think it was a router where the filesystem was read-only (only /var and /tmp writable, or something like that, so can't set authorized keys).
Re: SSH hacks – a little sanity for remote workers
#183Earlier quoted context omitted.
Isn't that called remote desktop?
Terminals can have mouse support. It works with some TUI apps like vim.
All the terminal software with mouse support I've found so far just messes with things, I wasn't aware that people actually use this (e.g. in vim enabling mouse support messes with the yank buffer and doesn't let me select things for clipboard copying anymore, I immediately turn that off in setups where some overzealous maintainer default-enabled it). The amount of software with support is very low anyway, so if one really wants to use a mouse, remote desktop might serve one better.
Re: SSH hacks – a little sanity for remote workers
#184ssh not having support for --password argument is a big drawback. Usually requires to use some weird workarounds, especially when copying ssh keys to the machine are not an option.
It is baffling to me as well. I had to write some automation for network devices that only accepted password authentication over ssh, and ended up just doing it in Go instead of using the OpenSSH binary. It worked extremely well. (I think you can make OpenSSH read the password from another fd, so you don't have to write a client just to supply a password from a script. But ultimately I found parsing the output of SSH to handle errors to be too painful; errors being out-of-band makes everything better.)
Re: SSH hacks – a little sanity for remote workers
#185I highly recommend using the canonicalization feature if you use multiple networks:
CanonicalizeHostname yes
CanonicalDomains example.org
This setting allows you to automatically accept keys for new hosts but still report conflicts for existing hosts:
StrictHostKeyChecking accept-new
Host *.amazonaws.com github.com *.github.com gitlab.com *.gitlab.com *.googleusercontent.com
ControlMaster auto
ControlPath ~/.ssh/control/%C.socket
ControlPersist 600
This will enable the provider:
PKCS11Provider=/usr/lib/ssh-keychain.dylib
ssh-keygen -D /usr/lib/ssh-keychain.dylib
Re: SSH hacks – a little sanity for remote workers
#186Earlier quoted context omitted.
That's likely to be a firing offence, no? If I were running things I wouldn't want employees deliberately subverting my network's security measures in the name of their own convenience. If you have to spend time wrestling the VPN while you're on the clock, that's their own time being wasted.
All you would have to do is disallow outbound SSH.
That's tricky, though, since there are many uses for SSH which are not circumventing security policy — blocking outbound SSH would also mean you couldn't use Git, manage servers in the cloud or other locations, transfer files, etc.
Using this to circumvent policy is exactly the kind of move which would lead to those other uses being banned and making life worse for all of your coworkers.
Re: SSH hacks – a little sanity for remote workers
#187Earlier quoted context omitted.
Interesting that they permit TCP port 53, rather than just UDP port 53.
My guess is that it stems from lax firewall defaults. "Allow port 53 - [tcp/udp/BOTH]?" (Yeah, I know that DNS can also work over 53/tcp, but it's rare compared to the 53/udp volume)
It's not as rare as it used to be a couple decades ago. If you block tcp/53 you will find a surprising number of things breaking as record sizes have increased over the years.
Re: SSH hacks – a little sanity for remote workers
#188Earlier quoted context omitted.
Do be careful doing this, if your company cares, a competent network admin can tell what's going on.
You can defeat deep packet inspection by tunneling it over an HTTPS proxy, using the SSH ProxyCommand option and the proxytunnel utility
Trying to defeat measures that your corporate IT department has put up sounds like an excellent way to be terminated.
Re: SSH hacks – a little sanity for remote workers
#189Everyone probably already knows this, but enabling compression (-C) makes running remote X programs more usable over slower connections.
Not a bad tip, but using gzip compression over the wire seems pretty stone-age. The proper solution is surely to use a modern lossy video-compression algorithm. Is that possible with X? It's not something I know a lot about. Is this where VNC steps in?
> ... using gzip compression over the wire seems pretty stone-age.
Really? Probably half of all web servers on the Internet (using HTTP/1.1) use it.
> The proper solution is surely to use a modern lossy video-compression algorithm.
The X11 protocol doesn't send bitmaps so I'm not certain that a "lossy video-compression algorithm" is gonna have the effect you think it will.
Re: SSH hacks – a little sanity for remote workers
#190Earlier quoted context omitted.
Is there much of an upside to doing the multiplexing on the client side instead of on the server (with something like tmux)? It seems to me like the session persistence tmux gives would be worthwhile if you have a lot of simultaneous sessions going.
I never saw the value of tmux unless your running a command that can’t be interrupted. Having multiple windows vs tabs on my desktop seems so much easier.
Yes, I agree. What is the usage for tmux? Multiple tabs on a quake-style dropdown terminal on a desktop (like guake) does seem much easier than tmux, especially when gnu-screen is always available when you need to run an uninteruptible command.
From what I gather, tmux is useful if you are basically running a persistent remote workspace via terminal on a server and treat your desktop like a thin-client, is that correct?