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…
An excruciatingly detailed guide to SSH (but only the things I find useful)
61–70 of 120 posts
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#62There 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"
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#63This 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)
#64There 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)
#65Why 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> 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…
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)
#67This 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)
#68Why 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…
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#69There'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
Re: An excruciatingly detailed guide to SSH (but only the things I find useful)
#70Why 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?