How to kill an unresponsive SSH session(laszlo.nu) |
How to kill an unresponsive SSH session(laszlo.nu) |
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.
A bit more history.
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.
(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.
$ telnet google.com 80
Trying 74.125.239.103...
Connected to google.com.
Escape character is '^]'.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.
Despite being brought up on VT220's whacked in a VAX/Sun3 I never got my head around the details.
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.
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.
But given that it uses ssh for the initial setup, I doubt there are any problems to be found with the initial key exchange, which is one of the trickiest parts of a "secure channel" protocol. And OCB, as an AEAD mode, is pretty hard to screw up, so long as (again) you make sure you're authenticating the proper data and generating IVs/nonces appropriately. Plus, they're using the (optimized) reference implementation for OCB, so that's probably pretty solid.
Now, I definitely agree that this isn't a proper security audit. But at a cursory glance, the general impression I get is that it's probably okay. Honestly, they've really removed most of the protocol complexity by using ssh to do all of the setup work.
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.
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.
nice man -l -Tdvi man*/* | wc
3416771 6700199 122007116
At more than 6 million words, that's approximately 10 War and Peace's. And of course in terms of documentation, that's only man pages, which doesn't cover all the stuff that's in other formats like info or html.
You cannot be an expert in everything: I knew about that command for closing ssh, but frankly it is not something I use because it's easier to just close the rxvt and be done with it. I have zillions of other things to occupy my brain.
I'd also argue that in terms of ssh, since this function is so easily accomplished in other ways, this is really just handy triva. Much more useful to know about are all the tunneling things, as they are not necessarily obvious, and can be extremely useful.
Or, put another way: don't be an asshole.
"A little shame is a good thing" says to everybody around you that you're more interested in feeling good about yourself than helping people. And it's a joke to boot. I've been doing this for around fifteen years, I've written multiple telnet server applications and a MUD client, and I didn't know about this feature in telnet/rlogin/ssh.
In any event, I'm not taking the position that casual *nix users should be reading every single man page. Just for the essentials like ssh, cp/mv, ls, man itself, etc. You do not need to be an expert to read a few man pages on utilities you often use. Everyone should RTFM, at least for the relevant bits, no matter what level you're at. Anyone who found the initial post useful would also find reading the man page for ssh useful. Thus, they should have read it. That's not at all suggesting that they need to become an expert.
The ~. key sequence is used in pretty much any console type application, not just ssh, so it's quite useful to know. If you do any work with a serial console i.e. configuring network devices, pdus, even some servers, etc., then it's pretty useful for ending a session as there's no TCP connection to close and take you back to the local console on your terminal emulator. If you're working on the actual local console and not in a full blown GUI on a system without virtual consoles, there may be no other way to close the serial console session on some platforms (notably man different OS'es running on Sparc64's as well as not on Solaris at all until recently).
Regardless, it's generally less effort to type ~. than to close and reopen a window/tab in your terminal emulator of choice. The time spent to read the man page would inevitably be made up by a few clicks saved here and there throughout a long career. It would have taken less time than to make multiple posts in this thread.
Meanwhile, you're resorting to making baseless assumptions about a total stranger on the Internet, and bringing your own credentials into this rather than focusing on the argument at hand. Who's digging the giant hole? Who's more interested in feeling good about himself?
I really couldn't care less what your personal story is, or what you've imagined up about mine. Let's stick to why someone should or should not RTFM, okay?
As well, I'm not sure if you're intending to, but you're coming off as an elitist asshole. Not knowing an esoteric bit of what is essentially ssh trivia does not make someone a neophyte. For anyone who entered the field in the past 15-20 years, hitting the (x) close window/tab button is likely more second nature than 'enter ~ .' Please don't be like the guy who hangs out in IRC help channels just to tell people wanting help to RTFM.
I would take the position that anyone who hasn't read the man page for something is a bit of a neophyte, or a novice at best. Unless perhaps they've read the source. How else are you going to learn something, without reading the documentation? Online tutorials and blog posts make for a poor substitute at best, and being less direct often introduce inaccuracies and other misinformation. I think it's fair to say that someone whose entire knowledge of a subject is based on incomplete information is not an expert. Not to say that man pages are perfect; they can be outdated and inaccurate themselves. But perhaps if more people read them, more people would submit revisions to make the documentation better. If suggesting that people read the proper documentation makes me an elitist asshole, so be it.
I don't quite agree with your 15-20 years timeline; GNOME and KDE were only founded about 15 years ago, and it was a few years before they matured to the point where decent windowing support was commonplace, so it wouldn't have been a given that you would have a full GUI environment at that time. Opening and closing xterm in twm was enough of a hassle to warrant using screen to accomplish windowing instead, which is much more esoteric than ~. Using ssh from an actual console without a GUI was still pretty common at the time, at the very least as part of setting up a box to the point where it had a GUI. But that is all beside the point. ~. takes less time than closing a window/tab and opening a new one, be it through a mouse or a keyboard sequence. And it doesn't nuke your scrollback history. This is just as true today as it was 15-20 years ago. If it's still useful enough to vote up a post, it should be useful enough to read about in a man page.
More people should be like the guys who hang out in IRC help channels. If you think they're there just to tell people to RTFM, you are very much mistaken. They are generally genuinely helpful people. However, they're not inclined to be as helpful to people who come waltzing in demanding everything they want to know handed to them on a silver platter, when they could have looked it up themselves with minimal effort. I don't think it's wrong to point out that there's no place for that sense of entitlement. However when someone asks a question who's clearly done their research but is still stuck on an issue, you'll find the same people who normally respond with RTFM will do everything they can to help. I don't think it's too much to ask to take enough consideration of their time not to waste it with something that can be answered in the first page of Google results. I would posit that instead of these people being labelled elitist assholes, a lot of people should be labelled entitled assholes instead.
Be a better person.
Anyone emotionally fragile enough to turn away over someone telling them to try to find answers on their own before pestering others probably isn't cut out to be part of the community in the first place, at least not a technical one, seeing as how they're too lazy to do it, and selfish enough to think that their own time is more valuable than that of the person helping them.
If people followed your advice, aside from the more experienced people shooting themselves in the face, they'd waste all their time answering questions for those too self-entitled to put in any efforts of their own where their expertise isn't even utilized, while the other neophytes who have a genuine interest and a willingness to put in their own efforts wouldn't have a resource to turn to.
Maybe it's toxic behavior to you, but it's human nature and the modus operandi because the set of technical experts is small to begin with, the set of technical experts who have enough patience to answer beginners' questions on a regular basis is much smaller still, and the set of technical experts willing to endlessly put up with the self-entitled and intellectually indolent is as rare as unicorns.
Be more realistic and open-minded to other perspectives.
Thank you for so wonderfully illustrating the problem you wish to perpetuate.
"Be more realistic?" I am being realistic. I'm telling you that being an asshole is bad. That is quite realistic. But it means having to not get your jollies. So have fun abusing beginners, as you think is your right. I hope never to encounter you in a project I care about.
I'm quite happy to never encounter someone who can't put together an intellectually honest argument and instead resorts to straw man arguments, appeals to authority, and ad hominem attacks. You can label me an asshole all you want, but I'll let your own words speak as to what type of person you are.