Live data from Hacker News

An excruciatingly detailed guide to SSH (but only the things I find useful)

grahamhelton.com

61–70 of 120 posts

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#61

There is an amazingly simple directive missing here: # in sshd_config: AuthorizedKeysCommand /usr/bin/php /etc/ssh/auth.php %u # in /etc/ssh/auth.php $user = $argv[1] ?? ''; $user = rawurlencode($user); echo file_get_contents("https://gihub.com/{$user}.keys"); This is obviously not production quality code, but just demonstrates the gist of the configuration. Basically, you can do a number of things, like verify the u…

Things like this make me wish I wasn't in the network side (where we miss out on awesome shit like this because "the network isn't working right" is part our job).

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#62
post #56

There is an amazingly simple directive missing here: # in sshd_config: AuthorizedKeysCommand /usr/bin/php /etc/ssh/auth.php %u # in /etc/ssh/auth.php $user = $argv[1] ?? ''; $user = rawurlencode($user); echo file_get_contents("https://gihub.com/{$user}.keys"); This is obviously not production quality code, but just demonstrates the gist of the configuration. Basically, you can do a number of things, like verify the u…

little typo there: "gihub"

brb buying gihub.com

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#63
> The best way I found to remember this is local forwarding with-L means local is on the left-hand side of the address. Remote forwarding with-R means the local port is on the right-hand side of the address.

This is the most important, succinct statement made in this piece. -L and -R confused me from the get-go. Having which port instance L or R is "local" change is in some ways, annoying. I "get" that -L and -R change the direction of intentionality, where initiator and responder are, but I think it might have been sensible to make a port:address:port phrase ALWAYS refer to local:binding:remote and have -L and -R define which was listen and which was send.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#64

There is an amazingly simple directive missing here: # in sshd_config: AuthorizedKeysCommand /usr/bin/php /etc/ssh/auth.php %u # in /etc/ssh/auth.php $user = $argv[1] ?? ''; $user = rawurlencode($user); echo file_get_contents("https://gihub.com/{$user}.keys"); This is obviously not production quality code, but just demonstrates the gist of the configuration. Basically, you can do a number of things, like verify the u…

Things like this make me wish I wasn't in the network side (where we miss out on awesome shit like this because "the network isn't working right" is part our job).

The real life script runs a cron job and caches the keys for all users in a group. It always does a sanity check on the user, but if that fails it still allows that user to login (because we all know GitHub goes down) if they have cached keys.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#65
Why tilde? Because rlogin, rsh used it.

Why did rlogin, rsh use tilde? because cu used it.

Why cu? Because if you had a modem or serial line, cu was the way you talked to it, to send Hayes codes, and you can't use Hayes codes breakouts because they will break to the modem, so you need a signal to break to cu.

Why not ^[ ? Because thats telnet. so if you had telnet to a host, to connect to the modem over cu, you needed a distinct break-back for cu, to not break back to telnet.

Its breakout syntax all the way down.

Also, its not actually tilde, it tilde

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#66
post #63

> The best way I found to remember this is local forwarding with-L means local is on the left-hand side of the address. Remote forwarding with-R means the local port is on the right-hand side of the address. This is the most important, succinct statement made in this piece. -L and -R confused me from the get-go. Having which port instance L or R is "local" change is in some ways, annoying. I "get" that -L and -R chan…

I think it's easiest to remember that -L listens on a local port whose number comes right after, and -R listens on a remote port whose number comes right after.

Then the rest (the host:port) is just the normal way to tell where to connect.

Since we're doing port forwarding over an SSH tunnel, it's obvious that the host is contacted from the other side of the tunnel than where the listening port is.

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#67
Here's something I bet few people know: the OpenSSH configuration parser ignores duplicate directives; only the first such directive has any effect. This is more than a little counter intuitive as IME the more common semantic in configuration parsers and rules engines is for subsequent directives to take precedence over previous ones.

This may seem inconsequential, but IME when changing defaults in, e.g., /etc/ssh/sshd_config, people and software tend to append their changes to the end of a file or directive block, not the beginning, expecting those changes to be effective. Even security companies and organizations get this wrong, including various SSH bastion products I've seen. CIS Benchmarks recommendations (IIRC) and most (all?) third-party CIS audit suites don't consider precedence at all or get it wrong--e.g. by recommending appending a value, or by providing a compliance test that accepts a broken configuration. FWIW, the proper way to check whether an OpenSSH configuration directive is defined as expected is to use `sshd -T` or `ssh -G` to dump the derived, internal configuration, not by directly inspecting the configuration file(s).

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#68
post #65

Why tilde? Because rlogin, rsh used it. Why did rlogin, rsh use tilde? because cu used it. Why cu? Because if you had a modem or serial line, cu was the way you talked to it, to send Hayes codes, and you can't use Hayes codes breakouts because they will break to the modem, so you need a signal to break to cu. Why not ^[ ? Because thats telnet. so if you had telnet to a host, to connect to the modem over cu, you neede…

I thought it was CR, tilde, . ? have i been doing it wrong?

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#69
post #32

There's a current pull request for adding AF_UNIX support, which should make all kinds of exciting forwarding possible, since it will make it easy to proxy ssh connections through an arbitrary local process which can do anything to forward the data to the remote end. https://github.com/openssh/openssh-portable/pull/431

The one I am interested in is -D using AF_UNIX, but good to see everything possible working over AF_UNIX. It looks like curl as of about a year ago can use AF_UNIX SOCKS via the ALL_PROXY syntax socks5://localhost/path (or socks5h). It looks like this was added due to Tor using an AF_UNIX SOCKS proxy. I want it to be able to configure network access via standard unix permissions (and ideally, IMO, kicking TCP/IP out of the kernel entirely).

Re: An excruciatingly detailed guide to SSH (but only the things I find useful)

#70
post #65

Why tilde? Because rlogin, rsh used it. Why did rlogin, rsh use tilde? because cu used it. Why cu? Because if you had a modem or serial line, cu was the way you talked to it, to send Hayes codes, and you can't use Hayes codes breakouts because they will break to the modem, so you need a signal to break to cu. Why not ^[ ? Because thats telnet. so if you had telnet to a host, to connect to the modem over cu, you neede…

I thought it was CR, tilde, . ? have i been doing it wrong?

Tilde dot is the disconnect sequence for SSH. Other characters after tilde have other uses as seen in the post.
Post reply on HN