SSH Tricks
tychoish.com
tychoish.com
Also, sshfs works great, but has some issues with memory mapped files that silently lose writes. Luckily (?) most programs don't use mmap to write files, so it's not very noticeable.
All in all, ssh is one of the greatest tools.
`brew install ssh-copy-id`
ssh user@host "mkdir .ssh && cat >> .ssh/authorized_keys" < ~/.ssh/id_rsa.pub
This works as well and is using nothing but the power of the unix shell and the concept of pipes.
ssh user@host "mkdir -p .ssh && cat >> .ssh/authorized_keys" < ~/.ssh/id_rsa.pubSaves copying/pasting the host ip a second time. Trivial Bash trick I know -- but it is a time saver...
This is not a good idea (and far from "awesome"). I get why he's doing it, but suggesting that weakening the security of a tool that is meant to enhance it is bad advice.
There's just too much that can go wrong.
I understand his specific application, and why it works for him, but including it as advice for the general SSH-consuming public is nuts.
It's host key checking that stops you typing in your root password into a different server that isn't who it says it is.
The first things I do with sshd on any machine are 1) disable remote root login and 2) disable password login.
plus move it to a high non-standard port
Our fail2ban processes were using a not-insignificant amount of resources while sshd was listening on port 22. Moving to a high port shifted it to somewhere in the "dead last" range in the CPU time column.
#!/bin/sh
exec ssh "${0##*/}" "$@"
If you're used to using "ssh user@box foo", and not always for the same user (in which case you could use "User" in .ssh/config), you can do the same thing via "box -l user foo"
(I feel old...)
Me too.
Here's how to work around it:
#!/bin/sh
exec ssh "$(basename "$0")" "$@"
#!/usr/bin/env sh
Common idiom, works in POSIX /bin/sh, bash, dash, ash, and every other sh I've encountered. I make a point of avoiding bashisms in /bin/sh scripts, but I have no problem counting on POSIX sh. :)
"~ C" Gives you a ssh command prompt.
Press ? for help.
"~ ." Closes the ssh connection; useful for
unresponsive ssh connections!Another useful tip to know is how to set your own escape key.
ssh -e ^ example.com
I had to use this recently to terminate an ssh connection that was initiated inside of a screen session on a machine I was sshed into from my laptop. Obviously, the generic ~. killed the first ssh session (on my machine), not the one in the screen. Connecting to the middle machine with ssh -e^ let me send ~. to the proper ssh session.
One of my favorite features is ssh forced commands, http://oreilly.com/catalog/sshtdg/chapter/ch08.html#22858 which I use on infrequently used remote servers to present menus of pre-defined commands to me or to others. And at other times, I can use it to kick off a daemon on a remote server just by ssh'ing to that remote server with the proper key.
It's a simple way to create a "compile server" and then use one command line from my preferred machine to tell the compile server to check a certain directory and compile everything within it.
Yeah, ssh is nice.
complete -W "$(echo `cat ~/.ssh/known_hosts | cut -f 1 -d ' ' | sed -e s/,.*//g | uniq | grep -v "\["`;)" ssh
Also, is it just me, or might his ssh-reagent bash function add keys to some other user's ssh agent process if they've sufficiently modified the permissions on their socket file in the temporary directory to allow you to write to it?
for tcsh, see http://www.opensource.apple.com/source/tcsh/tcsh-63.1/tcsh/c...
ssh -f username@mymailserver.com -L 2000:mymailserver.com:25 -N
- loose rhymes with "goose". The word is "lose".