31–40 of 105 posts
Because SSH requires several seconds to initiate a session, even on a local LAN. Does anyone know why this is the case? Its always baffled me.
If it's taking you several seconds then you probably have a reverse DNS problem. (By default, the SSH server looks up the reverse DNS of the client when it connects.)
Earlier quoted context omitted.
Yes. It does not have any centralized certificate system like HTTPS so unless you can manually verify the host's public key, you will not know whether your first visit is being proxied. Of course, if the first one is proxied, so may subsequent ones, and you would only get a warning if the proxy was removed or if it's key changed.
SSH supports CA-style key signing, and it also supports server fingerprint validation over DNSSEC (search for SSHFP DNS). Unfortunately neither of these things are commonly used yet. Cloudflare is adding DNSSEC support soon, so hopefully that will change.
Because SSH requires several seconds to initiate a session, even on a local LAN. Does anyone know why this is the case? Its always baffled me.
Every time I've tried to keep a long-running ssh tunnel for printing / http, the connection degrades after a while. I'm sure there are some flags that can be set, but I thought this was the major show stopper for the "everything over shh" (since ssh uses TCP protocol)
Because SSH requires several seconds to initiate a session, even on a local LAN. Does anyone know why this is the case? Its always baffled me.
Neat trick, if you're so inclined to use such tricks: $ cat .ssh/authorized_keys command="tmux new-session -A -s base" ssh-rsa [...] Automatically creates or joins a tmux session named base, and disconnects the SSH session when you disconnect from the tmux session. So, yeah, why don't we use SSH for more?
It's multiplexing support uses static sized windows, which even on modern LANs means you usually only see 3-5 mb/s transfer rates where you should be able to - even with encryption overhead - achieve almost gigabit NIC speed. Fortunately the HPN-SSH patches exist to solve this problem - but I really want to know why their's so much resistance to adding them upstream.
If I had to guess, the reason would be threefold. One, it requires tuning on both ends of the connection to make the high speed transfers work well (and it looks like it will interfere with multiplexing as well, the reason the fixed window exists in the first place).
Two, the "none" cypher which it enables completely undermines the security of the secure shell. The cypher renegotiation after authentication would make it trivial to MITM the connection. You could probably disable the cypher after every transfer by restarting the sshd daemon, but that's being a bit optimistic.
Finally, there is no visible license on the patchfile, or on the homepage. The project's sourceforge page lists it as being BSD licensed, but there is no indication from the author that this is the case.
Interesting idea, but isn't ssh very sluggish when it comes to throughput and latency? Doesn't it cost quite a bit more in CPU? I'd hate to make ssh the protocol replacement for http for a busy site.
If you believe Jacob Appelbaum, we probably should not be using SSH for anything http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_...
Yea I was fairly confused about that announcement as I couldn't find anything damning in the released docs about SSH. Do you have a reference to a specific document/slide?
From the slides:
Page 19: "SSH [...] Potentially recover user names and passwords" Page 36: "SSH - often have router configurations and user credentials [...]"
Because SSH requires several seconds to initiate a session, even on a local LAN. Does anyone know why this is the case? Its always baffled me.