If your authorized_keys line for a key has command="blah" on it and you go:
ssh server ls
You could use command to establish a jail or virtual environment of some sort in which to run the program specified if you wanted to.
A jail (ChrootDirectory in ssh) changes "where" the user gets when logs in.
The most creative thing I've do with command= was a "select" menu in bash (with some actions in the shudoers).
Other interesting tool I've discovered recently is rrsync. I'm doing the backups of my systems isolated with this. It's distributed with the rsync sources, you put it like:
command="rrsync /path/to/chroot/the/remote/rsync/client/"Jails limit the capabilities of users of the OS, instead of users of the network.
It works much better over high-latency links (mobile). It is not bothered by saturated links, tolerates IP changes and losing the underlying connection like when you suspend your laptop and take it elsewhere.
I now have mosh connect to several servers in tabs when I run gnome-terminal the first time, and only disconnect on reboot. I also run a mosh-capable Irssi Connectbot fork on the phone[2].
It's a massive improvement, fixing many of the little annoyances of ssh.
No mouse support in mosh either.
(gnome-terminal/vte (so also Terminator, Xfce Terminal and others) is similarly slow, but as with mosh you don't really notice with smaller terms. I switched to urxvt).
I haven't digged too deeply into their security, but from what the main page says, it seems pretty trustworthy. Hopefully they're using the appropriate authenticated data, with packet numbers and so forth, to prevent silly things like replay and reordering attacks.
EDIT - I suppose it must be an ASCII character, which is not an entirely unreasonable requirement.
<tilde> <space> .It is useful, yes. Here's another thing I picked up last week - how do you reboot a remote linux box that's somehow lost its root drive but you still have a shell open (because you left ssh running on another machine)?
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-triggerJust type Ctrl-Q and you will unfreeze the connection.
Credit due to: http://raamdev.com/2007/recovering-from-ctrls-in-putty/
$ stty -ixon -ixoff
To turn it on again, use
$ stty ixon ixoffI know tilde escapes from cu(1) (part of uucp) http://www.delorie.com/gnu/docs/uucp/cu.1.html
But it may well have originated before then.
chill out man.
I've also found it useful to do <enter>~C - then you can configure port forwarding without having to open a new ssh session.
(~C opens a command line, enter "help" for available commands.)
Maybe I should write a blog post about the use of CTRL-Z in the shell and post that here, should get me Kilo-karma points if this is anything to go by.
* Ruby
* Rails
* Postgres
* C
* Erlang
* Emacs
* Bash/Zsh/whatever
* Linux Kernel
* GNU C library
* Postfix
and on and on and on, these kinds of tricks are bound to be useful to someone who is not a complete expert with whichever system is being discussed.
Also, realistically speaking, they are far less prevalent than nakedly political articles lately, which do weight on the quality of the site.
$ telnet google.com 80
Trying 74.125.239.103...
Connected to google.com.
Escape character is '^]'.(This does not refer to the Unix version of telnet, which defaults to ^] as the default escape character.)
Not complaining, just a little surprised something so novice would get attention...
I've started to set it really really low personally - like, 5 seconds, so the connection drops after 15 seconds. I'm tempted to go down to 1, but I have a lot of long running sessions and I start to worry about the traffic counts.
But, after all this there's still a problem: none of it seems to work with any of the connection mux'ing options - once the background session dies, I still have to manually kill it to get anything working again.
I've tried to use it without success to kill a runaway listing of megabytes of scrolling text, but frantically hitting ctrl-C seems to work much better.
The Unix 'tty' subsystem was basically designed to support simple serial terminals, and so it had a bunch of behaviour designed to interoperate with the pre-existing 'break' conventions. If a Unix system's serial port received a break, Unix would (optionally) send any processes running via that connection a SIGINT, to represent the 'reset to known-good state' behaviour (this is controlled by the stty command's 'brkint' flag). Also, if the user's terminal didn't provide a specific 'send a break signal' command, Unix could be configured to send a break signal when it received some particular character (^C by default; this is controlled by stty's 'intr' setting).
Of course, nobody uses physical RS232 terminals anymore, but for compatibility reasons the Unix tty API lives on, and the "psuedotty" implementation used for things like terminal emulators maintains compatibility. ssh is basically a tool for exporting the tty API over the network, and so for compatibility it too must have a way to transmit the information "pretend a break condition has occurred on the RS232 connection we're pretending to use."
To summarise: yes, unless you've messed with the stty command, ~B will probably result in a SIGINT. Ctrl-C is probably more reliable since you can hit it much faster than you can type <Enter>~B, but ~B is still useful if your terminal is in 'raw' mode, where ^C is not converted to SIGINT (for example, if you're running an app that wants to bind ^C to some other function).
See also:
https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter#Break_condition
stty(1)
tcsendbreak(3)That being said, some people are new to the game. No reason to be elitist.