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/"On FreeBSD it's common to use nullfs to reduce this - you make one jail skeleton hierarchy and then null-mount it for individual jails so they all share the same underlying files (and cache). zfs clones can be used similarly. I'm sure other OS's have similar capabilities.
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).
It's simple to encrypt using AES, but that doesn't mean it is simple to encrypt in a secure way (i'm looking at you ECB mode). There are too many ways to accidentally mess up.
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.
A bit more history.
Despite being brought up on VT220's whacked in a VAX/Sun3 I never got my head around the details.
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.
For a group of people as large as HN, there are bound to be many people who are experts in one thing, and marginal with others, so articles like this are likely to appeal to them, and be useful.
Or, put another way: don't be an asshole.
$ telnet google.com 80
Trying 74.125.239.103...
Connected to google.com.
Escape character is '^]'.although on the Debian man page, it appears slightly differently as: "-r Emulate rlogin(1). In this mode, the default escape character is a tilde. Also, the interpretation of the escape character is changed: an escape character followed by a dot causes telnet to disconnect from the remote host. A ^Z instead of a dot suspends telnet, and a ^] (the default telnet escape character) generates a normal telnet prompt. These codes are accepted only at the beginning of a line. "
telnet is not installed by default on CentOS, but has the same man page as on Debian.
In any case that was not what my comment was about. I was, and still am, more than surprised by the poster's puerile lament that someone is getting a few odd karma that the poster thought was undeserved. I assumed that this place is somewhat removed from such "Mama ! he took my toy" behavior.
(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.