search for: qralston

I don't like to be the bearer of bad news, but... In light of the big "ssh hangs on logout" thread (wherein the true culprit was identified as being programs that don't close inherited file descriptors), I find it somewhat ironic that one of those "broken daemon" programs that doesn't close its open fds is sshd. :( http://bugzilla.mindrot.org/show_bug.cgi?id=3

Currently, ~/.ssh/environment can set static environment variables, and ~/.ssh/rc can run initialization routines. But there is no way for sshrc to propagate changes to the environment to the user's shell or command. There is, however, a possible way to do this. If the PermitUserEnvironment option is set, sshd could treat the stdout of sshrc as additional assignment lines of the form

Okay, I'm asking this again. As of 2.2.0p1, the *only* program that knows how to invoke ssh-askpass is ssh-add. Not ssh itself, nor scp understand how to invoke ssh-askpass. This is a direct contrast to ssh-1.2.27, in which all clients know how to invoke ssh-askpass. My question: is the limitation that only ssh-add knows how to invoke ssh-askpass intentional (i.e., a deliberate design

On Wed, 6 Jun 2001, Markus Friedl posted the following to Bugtraq: > this feature [placing the X11 cookie file in /tmp] was inherited > from ossh and the reason was: > 1) if $HOME is on NFS, then the cookie travels unencrypted > over the network, this defeats the purpose of X11-fwding > 2) $HOME/.Xauthority gets polluted with temorary cookies. > however,

I've been trying to get openssh to play nicely with chroot()'ed accounts (on Red Hat Linux 7.1), but so far, I haven't had much success. I can stick this line in /etc/pam.d/sshd: session required /lib/security/pam_chroot.so debug onerr=fail For slogin, this works great. But scp and sftp don't apply the chroot, because they don't invoke do_pam_session(). Even worse, I

I have several servers running Samba, all using security = ads mode. After updating one of the servers to 3.0.25, non-Kerberos login attempts now fail, although Kerberos logins work just fine. E.g.: $ smbclient -k -L //my-server OS=[Unix] Server=[Samba 3.0.25-0.0] Sharename Type Comment --------- ---- ------- ... $ smbclient -U username -L

I've just finished compiling OpenSSH version 2.1.1p4 for Red Hat Linux 6.2 (i386) with recent patches, using OpenSSL version 0.9.5a, which was compiled to use RSAREF. There are a couple of issues I noticed immediately: 1. The ssh-agent program can only store RSA keys, not DSA keys. 2. Only ssh-add knows to invoke ssh-askpass (if it is not attached to a tty and DISPLAY is set).

There are situations in which access to one's home directory depends on prior authentication. Here are several: - AFS (requires Kerberos-based tokens) - NFSv4+GSSAPI (requires a Kerberos TGT) - encrypted home directories (requires a token/password to decrypt) As it stands right now, OpenSSH X11 authentication forwarding breaks in these scenarios. This is because unlike the approach

Enclosed is a patch against 2.2.0p1 that teaches ssh (and therefore slogin and scp) how to invoke ssh-askpass to request a password, RSA/DSA key passphrase, or an skey challenge response. I've tested this on Linux (i386), for passwords and RSA/DSA key passphrases. I cannot easily test whether the Right Thing will happen for skey challenge responses; I would appreciate it if someone who uses