Hi folks, sorry if this has been discussed before, I did a quick search on the mailing list but found nothing pertinent. My question: is it possible to log all data that is sent from the ssh client to the sshd server? Rationale: I'd like to log all commands that users execute when being logged in via ssh. And I mean all, as the system in question is a sensitive production server, so the shell history isn't quite sufficient. I've found nothing in the manpages, only syslog levels (DEBUG1..4) are mentioned. A cursory glance through the CVS source didn't show any logging facilities and didn't answer the question if the syslog level debugging can handle that, so I'm asking the developers. Has this concept been discussed before? Thanks in advance, Roland -- RGiersig at cpan.org
> > Using System Auditing Reports is the only sane way of doing > > this. As it was pointed out in secureshell@ > > I'm not sure it's sane, but it's definitely the "correct" method. > Correct doesn't mean usable, though. > > Enforcing accountability among trusted peers is often even more > importantthan maintaining security -- when something breaks, first > you want to know > who broke it, then you want to know what they did to cause the break.Right. I concurr that SARs are the correct way to do this and even tried to set them up, but alas, configuration was a nightmare and usability was abysmal. I haven't looked into TTY auditing, that of course would be the best thing if the kernel gives you the possibility to log what is sent via a pseudo-terminal. But I don't think that that there are many OSes with that ability...> I consider this request somewhat orthogonal to the security > aspects of SSH -- it's a trait of the shell environment that > the admin would like SSH to securely provide, rather than > a trait of the security SSH is applying to the system.You are right of course, but given that SSHD is a single point of authenticated data flow, adding logging to SSHD gives maximum flexibility. Instead of having to enforce the usage of a certain shell that does logging and thus restricting the users choices (one user wants bash, that one zsh, that one ksh...) I simply log what the client sends to the server. This also includes what gets sent via 'scp', so that whiterabbit.sh gets logged too. Of course there are a lot of holes to be plugged, port-forwarding for example, to make this hacker- proofed... As of orthogonal, I don't think so. SSH is very strong on authorisation, why should auditing be left out? Anyway, what's the chance that a patch for logging would be accepted and incorporated? Cheers! Roland -- RGiersig at cpan.org
> > I believe one can obfuscate one's tty session such that you > > might not really figure out what was done merely through a > > keystroke replay. > > Ah, but if the only incoming channel of de-obfuscation code is itself > tapped, it's actually provably impossible to successfully > obfuscate the code.Right, and don't forget that ssh already provides strong authentication, so that should be enough to be able to point a finger at somebody and have the inquisition take over. "What were you uploading there?"> > I think a tty-log plus a history of exec*()s and open()s and > > creat()s> and so on would be a rather complete record, yes. But > > ultimately a sufficiently nasty and savvy user can get 'round > > such logging (though the obfuscation necessary might itself > > raise enough red flags that you could catch such a user). > > As I've been saying, often the "enemy" is lack of documentation and > accountability, not an active attacker. Production machines need > histories of who did what when.That's exactly my point. Providing a secure, stable, shared computing environment to untrusted users is nearly impossible, so we don't have to go that way (but it's of course interesting to talk about it). If I had to do this, I'd run multiple virtual machines and give every user her own. Proper load-balancing and quotas does the rest... So I'll summarize my wishes: per-connection logging of what gets sent from the client to the server. When a connection gets accepted, a logfile is created in a logdir whose filename contains a timestamp, pid of the sshd process that handles the connection, if a terminal is requested, authenticated user name and hostname from where the connection came. If the session uses a tty, a timestamp is written periodically to the logfile (once a minute) to give an indication what happened when. X forwarding could be logged the same way, as well as other forwarded ports. Anybody from the openssh developer team reading this? Roland -- RGiersig at cpan.org
> sorry if this has been discussed before, I did a quick search on the > mailing list but found nothing pertinent. > > My question: is it possible to log all data that is sent from the ssh > client to the sshd server? > > Rationale: I'd like to log all commands that users execute when being > logged in via ssh. And I mean all, as the system in question is a > sensitive production server, so the shell history isn't quite > sufficient.There are TTY snooping apps, but SSH can be used to execute commands without a TTY. (For example, one can use SSH to execute a non-snooping SSHD that would escape the TTY sniffer. But that's pretty damn obscure.) Recording all traffic in and out of SSHD is certainly possible, and for the highly sensitive environment you refer to, not necessarily a bad idea... Hmmm. If you need something urgently, some variation on messing around with script might help. The ugliness of making this happen right is a good sign that building this into OpenSSH might be the right idea. But: # mv /bin/csh /bin/csh_real # cat > /bin/csh #!/bin/sh exec script -q /tmp/log.$$ csh_real # chmod 0755 /bin/csh ...*does* seem to have a useful effect, without involving kernel level sniffing. There are *all* sorts of problems -- the logs are owned by the users, the logger shows up and can be killed by the user, and I don't even want to think about how to trace /bin/sh like that -- but it ain't bad for about 5 minutes of thought :-) --Dan
> > i'd like to capture unencrypted ssh packets in > > pcap format, just like openbsd's isakmpd does. > > and add support to tcpdump and etherreal for > > interpreting these packet, this would make > > debugging simpler. > > isakmpd can do this probably because it's linked so deeply with > the OS and the kernel; sshd never actually sees the raw packets > and we probably don't want to complete the engineering effort > to let it.I think you misunderstood this. Markus is just proposing a dump format, which IMHO makes perfect sense. After decrypting the packet it gets dumped in the same format that tcpdump is using, so you then can use 'tcpdump -r dumpfile' to display it. Did I get that right? Roland -- RGiersig at cpan.org
> > I won't speak for the others, but I don't want to turn OpenSSH into > > snoopware. All the more so if the snopping is going not going to be > > effective (e.g. whiterabbit.sh, whiterabbit.bin). > > I agree with Damien here. > > I'm just interested in the plaintext for debugging the protocol > implementation. It's not OpenSSH's job to spy the users.Well, that's a matter of usage, not technical capability. Most tools can be used for both good and bad. How about amending the startup protocol to tell the client "This session will be logged."? Apart from that, SSHs job is to secure communication *between* hosts, not what is going on inside. An evil admin can still add some sort of snooping, e.g. by modifying/wrapping the user's shell, so IMHO it doesn't make sense to take a holier-than-you stance on this issue. Knifes are much too useful for cutting your lunch meat to be abolished because you can stab people with them. And I see SSH as a swiss army knife. Now *firearms* are a different matter... Roland -- RGiersig at cpan.org
> > Apart from that, SSHs job is to secure communication *between* > > hosts, not what is going on inside. > > Yes, you are right. > > And because SSH does not care about what's going on inside it does > not snoop ttys. On Unix, tools should do _one_ thing and do it > well, not 1000 things is a very mediocre way.I'll word that differently in that I'd say "tools should solve *one* problem". SSH does a *lot* of very different things, forwarding X displays, propagating tty settings and signals, to name a few. You are right, I could write a tty snooping app that interposes itself between SSH and a shell, but this app would have to deal with tty and signal forwarding, just as SSH, so I would steal the work already done in SSH, strip out the network part and put in logging instead. Probably 80% of the code would be shared with SSH. So why not inserting the logging into SSH in the first place? Makes sense? Roland -- RGiersig at cpan.org
> > Did I get that right? > > tcpdump parses packet headers(IP, TCP, etc.)...> what are you suggesting, faking packet headers? :-)Sorry, got it the wrong way around, SSL is doing the encryption, of course, stupid me. Mixed up the protocol layers... Roland -- RGiersig at cpan.org
> OpenSSH is already providing TTY services; logging > functionality is all over the place in TTY tools(script, > most GUI telnet clients, etc.) This ain't a big jump; > in fact I'd be surprised if it's more than a few > dozen lines of code to diff in.Oh yeah, didn't think about that, the SSH client is also missing logging facilities (like xterm and telnet).> A *really* nice aspect of friendly TTY logs (we'll leave > attacker-logs to the SAR reports, though I doubt there's any > disagreement that TTY logs would supplement SAR's by helping > filter out innocent traffic) is that they'd automatically drop > whatever didn't show up on the TTY, i.e. typed passwords. > That would make captured logs an order of magnitude less security > sensitive -- big win.Hmm, turning off logging when the pty is set to -echo? Nice idea, but I'd definitely would make that optional so the admin still can specify: "I want all, I might have to deal with black hats" or "OK, I just want to see what trusted users are doing and if they are doing something fishy". If a trusted user does the whole session with -echo, that's definitely finshy...> ... > Thoughts? I definitely see your perspectives on > this... perhaps we can limit abuses by making this a > compile time option? Mind you, I *hate* compile time > options, but we could at least throw up a banner > referencing ECPA1986 if it was enabled.No, please, no compile-time options!! I'd propose amending the connection protocol so the client can display a warning like "WARNING! This connection will be logged on the server side. Do you still want to connect? (Y/N)", but then you need some way to always answer 'yes' to that for automatisation purposes etc. You could store that as an option with the hostkeys... <wanders off into the darkness mumbling> Roland -- RGiersig at cpan.org