3 ms·
I've used ~. for a long time but did not know about others. I know, should have read man page. Anyway, if you try it from shell prompt it is likely will not wo
by vzaliva 7mo ago
I've used ~. for a long time but did not know about others. I know, should have read man page.
Anyway, if you try it from shell prompt it is likely will not work as pressing ENTER shows the next prompt. Try `cat` followed by ENTER and then ~?
- BenjiWiebe 7mo agoIt'll still work. OpenSSH doesn't care about output (for ~ stuff), only input, so if you type <enter>~. it will close the connection.
- vzaliva 7mo agoIt does not. open ssh linux to mac, typing ~ just types it on fish shell prompt. It works after`cat` followed by ENTER
- ploxiln 7mo agoJust type <enter> without cat, your shell will show you another prompt, and the ssh escape command will also work.
- gear54rus 7mo agoNo they are correct, fish seems to intercept this or something like that. Only works with cat.
- BenjiWiebe 7mo agoSo you're saying 'fish' intercepts it on the far end? The ssh server on the far end shouldn't be sending it to 'fish' until it knows what's coming next. Is this a current-ish version of OpenSSH or some other client/server? EDIT Interesting! I tested it with fish and it does indeed intercept it! Wonder how that works.
- dnet 7mo agoIn newer versions, it's disabled by default and you have to do something like this to enable in ~/.ssh/config: Host * EnableEscapeCommandline yes
- nh2 7mo ago`EnableEscapeCommandline` only controls the <Enter>~C commandline. The reason that is disabled in current OpenSSH by default is OpenBSD `pledge` support: https://security.stackexchange.com/questions/280793/what-attack-vectors-are-enabled-on-ssh-with-the-usage-of-enableescapecommandline https://security.stackexchange.com/questions/280793/what-att... On my Linux, cat<Enter>~. closes the connection as expected, and no ~ is shown in the terminal.
- krautsauer 7mo agoDoes not for me, not even with busybox sh and no funky escape codes in PS1 at all. It does with cat or yes running, so just something being output is not the problem… Hm.
- ralferoo 7mo agoSame with me, I'll still instinctively go for ~. when a connection has hung / dropped (usually because of a NAT via a rebooted firewall), but never even considered how ~ doesn't normally cause an issue. Never knew it had to be immediately following a newline. Also never knew about the other options, ~^Z in particular looks useful. I wonder if anyone still remembers the ctrl-[ sequence in telnet. I think I only ever used the quit command in that though.
- lxgr 7mo agoNo need – your local ssh client, which interprets the escape sequence, doesn't have any understanding of whatever mode the remote session might currently be in. The point of the return is to prime it to accept the start of a new escape sequence. Presumably the idea is that `~.` is not completely unlikely to occur as part of text entered remotely, but less so at the beginning of a new line.