[HN Gopher] SSH Tips and Tricks
___________________________________________________________________
SSH Tips and Tricks
Author : feross
Score : 119 points
Date : 2022-08-16 17:31 UTC (5 hours ago)
(HTM) web link (carlosbecker.dev)
(TXT) w3m dump (carlosbecker.dev)
| chasil wrote:
| Would you like to try cleartext SFTP, to compare performance?
| This can be done with inetd/socket activation.
| server# cat /etc/systemd/system/ctsftp.socket [Unit]
| Description=cleartext sftp [Socket]
| ListenStream=7777 Accept=yes [Install]
| WantedBy=sockets.target server# cat
| /etc/systemd/system/ctsftp@.service [Unit]
| Description=cleartext sftp [Service]
| ExecStart=-/usr/libexec/openssh/sftp-server
| StandardInput=socket User=nobody Group=nobody
| server# systemctl start ctsftp.socket
|
| Then, on the client, set up a netcat. client$ cat
| ncssh #!/bin/sh exec nc fileserver.myco.com
| 7777 client$ chmod 755 ncssh
|
| Feel free to move around the cabin. client$ sftp
| -S ./ncssh bogus Connected to bogus. sftp> put ncssh
| Uploading ncssh to /ncssh remote open("/ncssh"): Permission
| denied sftp> cd tmp sftp> put ncssh Uploading
| ncssh to /tmp/ncssh ncssh
| 100% 56 128.6KB/s 00:00 sftp> quit
|
| I've also jacked this into stunnel. I haven't really benchmarked
| it, though.
|
| You could probably chroot() this, if there was a desire to use it
| for something important.
|
| For those who truly miss anonymous FTP, it was hiding inside of
| SSH the whole time. Shoehorning it back into the browsers is left
| as an exercise for the reader.
| kwoff wrote:
| > setenv -g SSH_AUTH_SOCK $HOME/.ssh/ssh_auth_sock
|
| I've worked in an environment where $HOME is mounted on a drive
| that's shared across multiple servers, so you might want to
| consider including the hostname in the socket name (logging in on
| another server while already logged in can result in confusing
| disconnections).
| quasarj wrote:
| What is the purpose of forwarding the yubikey-agent? What is it
| even used for?
| StewardMcOy wrote:
| Not the author of the article, but it allows you to use your
| yubikey wherever you would normally use agent forwarding. If I,
| for example. SSH to server foo, do some work, and then need to
| connect to server bar from server foo, I can use ssh -A bar. As
| long as both foo and bar are set up to accept my yubikey, it
| will work.
|
| This can be useful if bar is configured to only be reachable by
| foo.
| nvahalik wrote:
| Another trick I use is to put all of my stuff into .ssh/config.d/
| and then run `ssh-compile` and it generates .ssh/config for me.
|
| This lets me pull in new config files and hosts without having to
| redo everything every time.
| CamJN wrote:
| Or you can add this to the top of your ssh config file:
|
| `Include ~/.ssh/config.d/*`
| VLM wrote:
| Suggests using a yubikey, OK, then suggests shutting off host key
| checking, sigh.
| ajross wrote:
| Even the yubikey suggestion is suspect. A hardware token can
| protect access to your private keys by firewalling them on the
| "first system", which the agent is doing already. And enabling
| agent support on a remote device is, if anything, only opening
| new attack vectors; it's improving convenience and not security
| (the remote system has no way to validate that the hardware is
| in use, it just knows from ssh key pairs). It's not a bad
| suggestion, but it's not meaningfully different than just using
| ssh-agent as intended.
|
| Then it goes on and explains how to use ControlMaster to evade
| the physical access validation granted by the key! I mean...
| why even bother with the key in the first place?
|
| ControlMaster itself is a bad idea generically unless you
| really know what you're doing, because the original connection
| process needs to stay alive until the last child connection
| exits. Hands up, all of us who ever inexplicably hung chron
| jobs and other automated systems by doing interactive stuff at
| the wrong moment. I know I have. (To be clear: it's still
| useful as a performance enhancement for remote work, but you
| absolutely have to know what you're doing and script it
| carefully. It shouldn't appear like this in a default config
| line.)
|
| Similarly CanonicalizeHostnames is a recipe for collision with
| your DNS. If a name doesn't work the way you want it to you
| need to fix the naming and not just decide to speak a new
| language.
| outworlder wrote:
| > but it's not meaningfully different than just using ssh-
| agent as intended.
|
| Expect for where the key is stored. How much difference that
| makes depends on the use-case. For a developer laptop with a
| passphrase protected key? Not much of a difference.
|
| ControlMaster is great for development too. That should have
| been prefixed with that caveat.
|
| In fact, it seems that all recommendations are from the point
| of view of a developer, not automation. That would be a bad
| idea for automated systems, as you point out.
| outworlder wrote:
| Just for 'testing stuff'.
|
| What's the problem you see with the recommendation? Specially
| when it's talking to localhost?
| cyberCleve wrote:
| I will for sure be using the SSH straight into Tmux trick. To get
| it to work I had to add a RequestTTY option in ~/.ssh/config.
| fareesh wrote:
| - How is vim + tmux compatibility these days? Particularly with
| regard to powerline, etc. types of plugins? Is there a good
| resource that helps one set this up from scratch?
|
| - I find that SSH times out / disconnects if unused but only on
| my mac, not on my linux machine. I don't have any of the configs
| described here on either machine, so I'm not sure why one
| disconnects and one doesn't - is there some out-of-the box macOS
| default that needs to be changed, or is it some arcane battery
| optimization macOS feature that's killing the SSH sessions?
| ancientsofmumu wrote:
| > _How is vim + tmux compatibility these days?_
|
| I find I like having "set-option -g mouse on" in ~/.tmux.conf
| so that mousewheel scrolling feels more natural (like it does
| in a local terminal).
|
| > _I find that SSH times out / disconnects if unused..._
|
| This one is a little tricky - it partly depends on the default
| settings of the remote sshd_config for sending KeepAlive pings
| (changed Debian 10 to 11, e.g) and what your local vendor-
| compiled ssh_config defaults look like. In general, to just
| solve the problem add this to your macOS ~/.ssh/config at the
| bottom/end: Host * TCPKeepAlive yes
| ServerAliveInterval 300
|
| TCPKeepAlive is what it sounds like, it's the L3 level tweak.
| ServerAliveInterval is a higher level ping-pong on the SSH
| session itself; kind of overkill to have both configured, but
| it Just Works(tm) for most people to have them set on their
| client. You can look these up in the man pages (ssh_config,
| sshd_config) and discover even more tweakable options than just
| these two I presented - some you can set server side, some
| client side, some both.
|
| Side note: bash has an envvar `TMOUT` -- if that's set, bash
| will auto-logout if you idle in a shell. It's usually not set
| on most Linux server installs, just be aware it exists and is a
| thing to look for if you're debugging some day.
| fareesh wrote:
| Thanks I'll give that a try!
| SamuelAcker wrote:
| Another good set of ssh tips for those interested in further
| reading: https://www.sans.org/blog/using-the-ssh-konami-code-ssh-
| cont...
| cyounkins wrote:
| The SSH straight into tmux solution uses RemoteCommand and will
| break things like scp and rsync [1]
|
| I have this in fish config: function tsh
| ssh -o RequestTTY=yes $argv tmux -u -CC new -A -s tmux-main
| end
|
| and use `tsh host`
|
| [1] https://unix.stackexchange.com/questions/628607/how-to-
| bypas...
| CamJN wrote:
| Well, it used to break scp, but then I fixed scp:
| https://github.com/openssh/openssh-portable/commit/77e05394a...
| gerdesj wrote:
| Two lines of code.
|
| That was clearly one of those paper cut type of fixes that
| makes the world a tiny bit nicer.
| dizhn wrote:
| I have a similar setup but the tmux invokation is handled on
| the remote shell. Needless to say it does not break scp. (I
| will admit that a single config file for all hosts is more
| convenient though)
|
| I am actually switching to having wezterm handling the mux
| functionality. It's nice to have this stuff running on the
| local client which allows all familiar keyboard shortcuts to
| work without conflict. Automatic Pane/Tab support is really
| nice. Mosh like functionality comes for free as well.
| mdeeks wrote:
| The SSH agent symlink tip will not fully work. If you connect
| with a second SSH session and then disconnect it will point to a
| stale SSH_AUTH_SOCK that doesn't work. The only way I found to
| solve this is by having a prompt command that refreshes it every
| time your prompt is rendered. So worst case is you have a broken
| ssh-agent for a single command.
|
| Add this function to your zshrc/bashrc: # This
| function refreshes some env vars that go stale in old tmux
| sessions # It must be run as a preexec function in zsh or a
| PROMPT_COMMAND in bash function refresh_env {
| local ssh_auth_sock="" if [[ -v "TMUX" ]]; then
| ssh_auth_sock=$(tmux show-environment | grep "^SSH_AUTH_SOCK")
| fi if [[ -n "$ssh_auth_sock" ]]; then
| #shellcheck disable=SC2163 export "$ssh_auth_sock"
| fi }
|
| Then for bash, add this: if ! [[
| "$PROMPT_COMMAND" =~ refresh_env ]]; then
| PROMPT_COMMAND="refresh_env; $PROMPT_COMMAND"; fi
|
| Or for zsh, add this: autoload -U add-zsh-hook
| add-zsh-hook preexec refresh_env
| hprotagonist wrote:
| _SSH straight into tmux_ Host example.org
| RemoteCommand tmux new -A -s default
|
| Instead of this, i go one step further, and in .zshrc on
| username@example.org: if [ -n "$SSH_CLIENT" ] ||
| [ -n "$SSH_TTY" ]; then [ -z "${TMUX}" ] && tmux new-
| session -A -s default fi
| valbaca wrote:
| For anyone dealing with very shoddy connection, I'd highly
| recommend mosh: https://mosh.org
|
| I used it when trying to use my iPad for minimalist development
| (mosh + ec2 + vim + Go) and it worked great compared to SSH.
| fourmajor wrote:
| I wanted to try mosh, but noticed that its last release was in
| 2017, which doesn't inspire confidence in its security.
| shmerl wrote:
| A very powerful feature of ssh is port forwarding and running
| SOCKS5 proxy out of the box (which possible in both directions).
|
| Check -D, -R (both support SOCKS5 now) and -L options in man ssh.
| lucb1e wrote:
| -R is a reverse tunnel similar to -L, something very different
| from -D which is indeed a SOCKS proxy.
| shmerl wrote:
| -R now supports SOCKS5 too. Except you initiate it from the
| other side (compared to -D), which is pretty cool and gives
| the same practical effect.
| lucb1e wrote:
| How does that work? Does it try to autodetect whether
| you're speaking SOCKS to it? What if you want to reverse
| tunnel a socks proxy from another process like Tor?
| shmerl wrote:
| If I understand correctly, something like this:
|
| Let's say you have hosts A and B.
|
| Doing this from A: ssh -R 1080 B
|
| will start a SOCKS5 proxy on A, to which you can connect
| on B through port 1080 that's being forwarded there. So
| your web client running on B will use traffic proxied
| through A while connecting to 1080 on localhost.
|
| _> Does it try to autodetect whether you 're speaking
| SOCKS to it_
|
| I think it just uses SOCKS5 out of the box if you don't
| specify the host for -R. According to the man page for
| -R: if no explicit destination was
| specified, ssh will act as a SOCKS 4/5 proxy and
| forward connections to the destinations requested
| by the remote SOCKS client.
| singlow wrote:
| If you don't specify a destination for -R it will work in
| SOCKS mode.
|
| > ssh -R 8080:localhost:8080 #Port forward
|
| vs
|
| > ssh -R 8080 #SOCKS
___________________________________________________________________
(page generated 2022-08-16 23:00 UTC)