From ncristin at n-k.it Mon Jan 1 00:27:03 2007 From: ncristin at n-k.it (Cristian Nechita) Date: Sun, 31 Dec 2006 14:27:03 +0100 Subject: Creating a file by ssh Message-ID: <4597BAA7.2020706@n-k.it> Hello I have this problem. I don't know if it's really a problem or just a misconfiguration of ssh. I tried to copy from a Fedora 6 with rsync (via ssh) a file that has some italian characters inside (file it's named "qualit?"). It gives me no error it copies the file but when I go to see it on the remote server (openSuse 10.2) i got this new file "qualit?" instead of "qualit?". The same problem with the name of the folders. I thought there has been an rsync problem but trying to vi a new file called "??????" by ssh (without rsync) to the same openSuse 10.2 I got the new file "???????". It's name is really made by the question mark character. I tried different version of ssh from Linux and WIndows (putty, ttssh, cygwin) but I have the same problem. I've tried creating the new file by ssh from an openSuse 10.2 to Redhat 7.2 and it's not working as well. I've got surprised to see that from openSuse 10.2 (my laptop) to openSuse 10.2 (server) it's working fine. Such characters as "????" I'm writing/reading well from both sides (local, and remote with ssh) All my distro have the Italian keyboard installed and English language as default. Thank you very much and have a great New Year Cristian Nechita P.S. I've posted this question on linuxforums.org but I did not have any response. From bob at proulx.com Mon Jan 1 03:35:44 2007 From: bob at proulx.com (Bob Proulx) Date: Sun, 31 Dec 2006 09:35:44 -0700 Subject: Creating a file by ssh In-Reply-To: <4597BAA7.2020706@n-k.it> References: <4597BAA7.2020706@n-k.it> Message-ID: <20061231163544.GA25293@dementia.proulx.com> Cristian Nechita wrote: > I have this problem. I don't know if it's really a problem or just a > misconfiguration of ssh. I think you are getting confused by thinking that the copy is not working. But I think the copy is working fine and it is the other components of your system, specifically the locale information, that is different. > I tried to copy from a Fedora 6 with rsync (via ssh) a file that has > some italian characters inside (file it's named "qualit?"). It gives me > no error it copies the file but when I go to see it on the remote server > (openSuse 10.2) i got this new file "qualit?" instead of "qualit?". The > same problem with the name of the folders. > > I thought there has been an rsync problem but trying to vi a new file > called "??????" by ssh (without rsync) to the same openSuse 10.2 I got > the new file "???????". It's name is really made by the question mark > character. You can check that the file contents were copied correctly by comparing the message digest (aka checksum) of the files. md5sum filename sha1sum filename If the message digests are the same on both systems then you can be assured that the file contents were copied correctly between the systems. I am guessing the the file contents have been copied correctly. The first thing you should check to get to the root of the problem is what locale data is available on the different systems and what your locale configuration is set to use. One useful command is 'locale' that prints out the locale environment variables. locale That prints the environment variables but does not say anything about whether the needed locale data is actually installed. I don't know how to get that information portably. On my Debian system the list of installed locales is in the /etc/locale.gen file and may be easily reconfigured using the 'sudo dpkg-reconfigure locales' command. I am confident that the problem is that between these two systems you do not have the same locale configuration or the system does not have all of the locale data installed. > I've got surprised to see that from openSuse 10.2 (my laptop) to > openSuse 10.2 (server) it's working fine. Such characters as "????" I'm > writing/reading well from both sides (local, and remote with ssh) Both sides have the desired locale data installed and have the same locale configuration. Bob From ncristin at n-k.it Mon Jan 1 05:33:45 2007 From: ncristin at n-k.it (Cristian Nechita) Date: Sun, 31 Dec 2006 19:33:45 +0100 Subject: Creating a file by ssh In-Reply-To: <20061231163544.GA25293@dementia.proulx.com> References: <4597BAA7.2020706@n-k.it> <20061231163544.GA25293@dementia.proulx.com> Message-ID: <45980289.5090906@n-k.it> Thank you very much BOB. You're right about the file. The source and the destination it's similar (md5sum). It's only the file name that's changed. I think you're right with the variables too. I have to check the local/remote variables to see what's changed between them. I'm very disappointed (at this point) of this project cause I wanted it as partial portability Backup WareHouse. Using openSuse 10.2 as server and Windows (.NET 2), Linux Fedora ( Ubuntu yet not tried ) as client. The whole worked smooth and clear until this characters. I wanna thank you another time for being so quickly. Have a great New 2007 Year. CristianN Bob Proulx ha scritto: Cristian Nechita wrote: I have this problem. I don't know if it's really a problem or just a misconfiguration of ssh. I think you are getting confused by thinking that the copy is not working. But I think the copy is working fine and it is the other components of your system, specifically the locale information, that is different. I tried to copy from a Fedora 6 with rsync (via ssh) a file that has some italian characters inside (file it's named "qualit?"). It gives me no error it copies the file but when I go to see it on the remote server (openSuse 10.2) i got this new file "qualit?" instead of "qualit?". The same problem with the name of the folders. I thought there has been an rsync problem but trying to vi a new file called "??????" by ssh (without rsync) to the same openSuse 10.2 I got the new file "???????". It's name is really made by the question mark character. You can check that the file contents were copied correctly by comparing the message digest (aka checksum) of the files. md5sum filename sha1sum filename If the message digests are the same on both systems then you can be assured that the file contents were copied correctly between the systems. I am guessing the the file contents have been copied correctly. The first thing you should check to get to the root of the problem is what locale data is available on the different systems and what your locale configuration is set to use. One useful command is 'locale' that prints out the locale environment variables. locale That prints the environment variables but does not say anything about whether the needed locale data is actually installed. I don't know how to get that information portably. On my Debian system the list of installed locales is in the /etc/locale.gen file and may be easily reconfigured using the 'sudo dpkg-reconfigure locales' command. I am confident that the problem is that between these two systems you do not have the same locale configuration or the system does not have all of the locale data installed. I've got surprised to see that from openSuse 10.2 (my laptop) to openSuse 10.2 (server) it's working fine. Such characters as "????" I'm writing/reading well from both sides (local, and remote with ssh) Both sides have the desired locale data installed and have the same locale configuration. Bob From Sathiyaseelan.Panchacharam at unisys.com Thu Jan 4 06:47:24 2007 From: Sathiyaseelan.Panchacharam at unisys.com (Panchacharam, Sathiyaseelan non Unisys) Date: Wed, 3 Jan 2007 13:47:24 -0600 Subject: sftp issue Message-ID: <45B258C006C6954AB0B2FA2EF5D76076045732AA@USEA-EXCH3.na.uis.unisys.com> I have problem in sftp using a user exn the sftp -v output is given below. Could someone help me in this? The user detail is as follows. The shell we are using is /bin/false is it creating problem? exn:x:2014:106::/newroot2/:/bin/false # sftp -v -v -v exn at hostname Connecting to OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /usr/local/etc/ssh_config debug3: RNG is ready, skipping seeding debug2: ssh_connect: needpriv 0 debug1: Connecting to hostname [12.41.51.253] port 22. debug1: Connection established. debug3: Not a RSA1 key file /.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /.ssh/id_rsa type 1 debug3: Not a RSA1 key file /.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2 debug3: RNG is ready, skipping seeding debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 141/256 debug2: bits set: 1613/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug3: check_host_in_hostfile: filename /.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host '' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:2 debug2: bits set: 1557/3191 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/id_rsa (64e70) debug2: key: /.ssh/id_dsa (652f0) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering public key: /.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password password: debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug2: fd 5 setting O_NONBLOCK debug2: fd 6 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: ssh_session2_setup: id 0 debug1: Sending subsystem: sftp debug2: channel 0: request subsystem debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel 0: close_fds r -1 w -1 e 7 debug1: fd 0 clearing O_NONBLOCK debug2: fd 1 is not O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 255 Connection closed Thanks and Regards Sathiyaseelan Panchacharam | UNIX Systems Analyst | Global Outsourcing and Infrastructure Services Unisys | 3199 Pilot knob Road | Eagan, MN 55121 | 1-651-687-2438 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. From dtucker at zip.com.au Thu Jan 4 14:31:54 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 04 Jan 2007 14:31:54 +1100 Subject: sftp issue In-Reply-To: <45B258C006C6954AB0B2FA2EF5D76076045732AA@USEA-EXCH3.na.uis.unisys.com> References: <45B258C006C6954AB0B2FA2EF5D76076045732AA@USEA-EXCH3.na.uis.unisys.com> Message-ID: <459C752A.5020107@zip.com.au> Panchacharam, Sathiyaseelan non Unisys wrote: > I have problem in sftp using a user exn the sftp -v output is given > below. Could someone help me in this? > > The user detail is as follows. The shell we are using is /bin/false is > it creating problem? Yes. sshd tries to run sftp-server using the user's shell (via the "-c" option) which doesn't work with /bin/false as the shell. You have a few options: 1) set the user's shell to be /path/to/sftp-server. This works with current versions but it's not very elegant. 2) If you're using OpenSSH 4.4 or up, you can set a real shell then use "Match User exn" then "ForceCommand /path/to/sftp-server" in sshd_config. This will only restrict access via ssh though, so if the user has access to, eg, telnet, they'll get a shell. 3) Use one of the restricted shells built for this purpose (eg scponly or rssh). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tryponraj at gmail.com Fri Jan 5 22:22:06 2007 From: tryponraj at gmail.com (ponraj) Date: Fri, 5 Jan 2007 16:52:06 +0530 Subject: No warning message is displayed for "none" cipher Message-ID: <00f201c730bb$c21a4e70$180110ac@pomco> Hello all, I tried to connect to the server that supports protocol 1: # ssh -1 -o "cipher none" remotehost As per the code in sshconnect1.c, it has to alert the user about "none" cipher usage. try_challenge_response_authentication() { .... if (options.cipher == SSH_CIPHER_NONE) logit("WARNING: Encryption is disabled! " "Response will be transmitted in clear text."); } try_password_authentication() { ... if (options.cipher == SSH_CIPHER_NONE) logit("WARNING: Encryption is disabled! Password will be transmitted in clear text."); } But "none" cipher is skipped during "invalid" cipher testing and the actual cipher for the connection is set to default cipher type.If it is the case, I would like to know how to alert the user about the "none" cipher usage. If such warnings are not required why or for what purpose does the code check the "none" cipher usage during password and challenge response authentication ? regards Ponraj M From djm at mindrot.org Fri Jan 5 23:01:05 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 5 Jan 2007 23:01:05 +1100 (EST) Subject: No warning message is displayed for "none" cipher In-Reply-To: <00f201c730bb$c21a4e70$180110ac@pomco> References: <00f201c730bb$c21a4e70$180110ac@pomco> Message-ID: On Fri, 5 Jan 2007, ponraj wrote: > Hello all, > > > I tried to connect to the server that supports protocol 1: > > # ssh -1 -o "cipher none" remotehost > openssh does not support the "none" cipher. Any traces of it in the code are legacy and/or paranoia. There are 3rd party patches that add support for the "none" cipher. We do not recommend their use, and obviously don't support them. This has been discussed ad nauseum on this mailing list - please have a look at the archives. -d From alon.barlev at gmail.com Sat Jan 6 03:21:58 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 5 Jan 2007 18:21:58 +0200 Subject: Announce: PKCS#11 support version 0.18 in OpenSSH 4.5p1 Message-ID: <200701051821.58679.alon.barlev@gmail.com> Hi All, The version of "PKCS#11 support in OpenSSH" is ready for download. On download page http://alon.barlev.googlepages.com/openssh-pkcs11 you can find a patch for OpenSSH 4.5p1. Most of PKCS#11 code is now moved to a standalone library which I call pkcs11-helper, this library is used by all projects that I added PKCS#11 support into. The library can be downloaded from: http://www.opensc-project.org/pkcs11-helper As a result the patch is much smaller now, and maybe I will be able to get some feedback from core OpenSSH developers? :) The way identity is loaded now into the agent was modified, please refer to the README.pkcs11 for more details. What I wish to discuss is how to further integrate it into OpenSSH, so far I touched the minimum required code (ssh-agent, ssh-add). But I would like to discuss a configuration file support for ssh-agent in order to allow it to load providers on startup, and maybe the use of PKCS#11 in none-agent configurations. But the most important issue is how to handle dynamic PIN entry... Current protocol between the ssh and the agent assume that keys are always authenticated, but what happens if a smartcard is removed and inserted? The agent must un-authenticate the key, and a PIN should be prompted at next usage. So I think that the ssh-agent protocol should be modified to allow application be notified that the requested key is unauthenticated, and support authentication verb. What's new: 20070105 - (alonbl) Removed pkcs11-helper since it is now a standalone library. - (alonbl) Default is PKCS#11 support is disabled, to enable configure with --with-pkcs11 - (alonbl) Rebase with openssh-4.5p1. - (alonbl) Release 0.18 20061023 - (alonbl) Removed logit from ssh-agent, thanks to Denniston, Todd. - (alonbl) Release 0.17 20061020 - (alonbl) Major modification of ssh-add command-line parameters. Now, a complete serialized certificate needs to be specified, this in order to allow people to add id without forcing card to be available. But to allow complete silent addition a certificate file also needed. --pkcs11-show-ids is used in order to get a list of resources. --pkcs11-add-id --pkcs11-id \ [--pkcs11-cert-file ] - (alonbl) PKCS#11 release 0.16 20061012 - (alonbl) OpenSC bug workaround. - (alonbl) PKCS#11 release 0.15 Best Regards, Alon Bar-Lev. From rapier at psc.edu Sat Jan 6 06:26:39 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 05 Jan 2007 14:26:39 -0500 Subject: No warning message is displayed for "none" cipher In-Reply-To: References: <00f201c730bb$c21a4e70$180110ac@pomco> Message-ID: <459EA66F.1050707@psc.edu> Damien Miller wrote: > On Fri, 5 Jan 2007, ponraj wrote: > >> Hello all, >> >> >> I tried to connect to the server that supports protocol 1: >> >> # ssh -1 -o "cipher none" remotehost >> > > openssh does not support the "none" cipher. Any traces of it in the code > are legacy and/or paranoia. > > There are 3rd party patches that add support for the "none" cipher. We > do not recommend their use, and obviously don't support them. This has > been discussed ad nauseum on this mailing list - please have a look at > the archives. While I perfectly understand and respect why you'd not recommend the use of the NONE cipher I do feel that the means by which it is implemented in the HPN patch is a good compromise position. By maintaining full encryption through the authentication process it, I feel at least, provide sufficient security for users who are aware of what their needs on. Being that the use of the NONE cipher in the case of the HPN patch is limited to bulk data transfers I also think that further mitigates the inherent security risk associated with unencrypted data transfers. Lastly, maintaining MAC on the packets does provide protection that a typical 'NONE' session under V1 does not (at least as far as I am aware). The impact that enabling the NONE cipher has on throughput is considerable and when you are moving 15 terabytes cross country on a daily basis with scp these sort of performance improvements matter. Chris From michael at weiser.dinsnail.net Sat Jan 6 03:59:12 2007 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Fri, 5 Jan 2007 17:59:12 +0100 Subject: nologin not working with openssh >= 4.3 and authentication != password Message-ID: <20070105165912.GA23074@weiser.dinsnail.net> Hi developers, today I tried to disable logins to an ssh server by putting a nologin file into /etc. This only worked for logins that use the password authentication mechanism. publickey-based authentications still succeeded and the users were allowed into the system. This seems straightforward to me since openssh 4.3 disabled the evaluation of /etc/nologin in favour of pam_nologin but doesn't use PAM for anything other than password-based logins, does it? Is this a known issue or even a non-issue due to a misunderstanding on my part? -- Thanks in advance, bye, Michael From rwaite1 at tampabay.rr.com Mon Jan 8 12:54:01 2007 From: rwaite1 at tampabay.rr.com (Robert Waite) Date: Sun, 7 Jan 2007 20:54:01 -0500 Subject: How to remove group1 and group14 from OpenSSH.. Message-ID: <9BAED83ED2CB4C97832F9FFBF6171A72@Arrakis> Hello everyone.. I am fairly new to the patching format.. so I just decided to post a basic info about how to remove group1 and group14 diffie key exchange in OpenSSH. I know that they are listed as required in RFC 4253 but I don't want a client to have the choice to use a 1024 bit prime for the key exchange. If someone is getting into my system.. they should upgrade to a new client. I am a fan of 8192 bit primes : ) I also give instructions to allow only RSA host auth keys because DSA only allow 1024 bit (I am sleepy and don't want to look that up so maybe it is a different bit size). I am pretty sure (not 100 percent) that this does not affect the security of OpenSSH. If anyone out there wants to comment, please feel free. Below is my basic explanation of what to change. It is just meant to show what should change. I do apologize for not using the patch format and I also apologize if we are not supposed to post patch-like info. Also.. if you do try to recompile.. you might need to change your Makefiles. All of these files are in /usr/src/ssh/ TO REMOVE GROUP1 and GROUP14 IN myproposal.h #define KEX_DEFAULT_KEX "diffie-hellman-group-exchange-sha256," \ "diffie-hellman-group-exchange-sha1," \ "diffie-hellman-group14-sha1," \ "diffie-hellman-group1-sha1" CHANGE TO #define KEX_DEFAULT_KEX "diffie-hellman-group-exchange-sha256," \ "diffie-hellman-group-exchange-sha1" IN sshd.c kex = kex_setup(myproposal); kex->kex[KEX_DH_GRP1_SHA1] = kexdh_server; kex->kex[KEX_DH_GRP14_SHA1] = kexdh_server; kex->kex[KEX_DH_GEX_SHA1] = kexgex_server; kex->kex[KEX_DH_GEX_SHA256] = kexgex_server; kex->server = 1; CHANGE TO kex = kex_setup(myproposal); kex->kex[KEX_DH_GEX_SHA1] = kexgex_server; kex->kex[KEX_DH_GEX_SHA256] = kexgex_server; kex->server = 1; IN kex.h #define KEX_DH1 "diffie-hellman-group1-sha1" #define KEX_DH14 "diffie-hellman-group14-sha1" #define KEX_DHGEX_SHA1 "diffie-hellman-group-exchange-sha1" #define KEX_DHGEX_SHA256 "diffie-hellman-group-exchange-sha256" CHANGE TO #define KEX_DHGEX_SHA1 "diffie-hellman-group-exchange-sha1" #define KEX_DHGEX_SHA256 "diffie-hellman-group-exchange-sha256" AND ALSO enum kex_exchange { KEX_DH_GRP1_SHA1, KEX_DH_GRP14_SHA1, KEX_DH_GEX_SHA1, KEX_DH_GEX_SHA256, KEX_MAX }; CHANGE TO enum kex_exchange { KEX_DH_GEX_SHA1, KEX_DH_GEX_SHA256, KEX_MAX }; IN kex.c static void choose_kex(Kex *k, char *client, char *server) { k->name = match_list(client, server, NULL); if (k->name == NULL) fatal("no kex alg"); if (strcmp(k->name, KEX_DH1) == 0) { k->kex_type = KEX_DH_GRP1_SHA1; k->evp_md = EVP_sha1(); } else if (strcmp(k->name, KEX_DH14) == 0) { k->kex_type = KEX_DH_GRP14_SHA1; k->evp_md = EVP_sha1(); } else if (strcmp(k->name, KEX_DHGEX_SHA1) == 0) { k->kex_type = KEX_DH_GEX_SHA1; k->evp_md = EVP_sha1(); } else if (strcmp(k->name, KEX_DHGEX_SHA256) == 0) { k->kex_type = KEX_DH_GEX_SHA256; k->evp_md = evp_ssh_sha256(); } else fatal("bad kex alg %s", k->name); } CHANGE TO static void choose_kex(Kex *k, char *client, char *server) { k->name = match_list(client, server, NULL); if (k->name == NULL) fatal("no kex alg"); if (strcmp(k->name, KEX_DHGEX_SHA1) == 0) { k->kex_type = KEX_DH_GEX_SHA1; k->evp_md = EVP_sha1(); } else if (strcmp(k->name, KEX_DHGEX_SHA256) == 0) { k->kex_type = KEX_DH_GEX_SHA256; k->evp_md = evp_ssh_sha256(); } else fatal("bad kex alg %s", k->name); } IN monitor.c kex->we_need = buffer_get_int(m); kex->kex[KEX_DH_GRP1_SHA1] = kexdh_server; kex->kex[KEX_DH_GRP14_SHA1] = kexdh_server; kex->kex[KEX_DH_GEX_SHA1] = kexgex_server; kex->kex[KEX_DH_GEX_SHA256] = kexgex_server; kex->server = 1; CHANGE TO kex->we_need = buffer_get_int(m); kex->kex[KEX_DH_GEX_SHA1] = kexgex_server; kex->kex[KEX_DH_GEX_SHA256] = kexgex_server; kex->server = 1; TO REMOVE DSA HOST KEY IN servconf.c if (options->protocol & SSH_PROTO_2) { options->host_key_files[options->num_host_key_files++] = _PATH_HOST_RSA_KEY_FILE; options->host_key_files[options->num_host_key_files++] = _PATH_HOST_DSA_KEY_FILE; } CHANGE TO if (options->protocol & SSH_PROTO_2) { options->host_key_files[options->num_host_key_files++] = _PATH_HOST_RSA_KEY_FILE; } /etc/rc REMOVE LINES ABOUT GENERATING THE UNWANTED KEYS AT STARTUP (cant print the lines because I already deleted them.. sorry) From enrique.moliner at aragon.catastro.meh.es Mon Jan 8 19:17:42 2007 From: enrique.moliner at aragon.catastro.meh.es (enrique moliner) Date: Mon, 8 Jan 2007 09:17:42 +0100 Subject: priotc text hp-ux renicer program (new version 1.5) Message-ID: <007801c732fd$782e6690$b9d5390a@zaragoza.catastro.minhac.es> PRIOTC Author: Enrique Moliner Martinez, from Zaragoza (Spain) version 1.5 (2/1/2007) with FREE_ENDUSER license version 1.4.a have a bug, only if missing config label values. Automatic HP-UX pid renicer and serializer For use in HP-9000 (others?) unix systems with 'HP-UX' B.10.20 or higher This is an 'automatic renicer' program: Get variable CPU time to pids depending on defined nice-value and names or patterns in configuration file, by once renice if matching: -At startup, priotc renice all pids to defined nice. .When priotc is already running, watch ONLY for renice NEW pids or equal pid if a change in command-name or program-name is detected (like occurs in an exec command). Then, at any time, any nice value or serialize is valid by manually 'renicer', 'serialize' user commands and the hp-ux restrictions. This is also an 'automatic serializer program: Serialize a pid with nice >= that defined in configuration file if actually low free pages in the system. -For system performance, all serialized pids run togheter in a sequential no timeshare cpu use, only if hp-ux detect low free pages. If enough pages, serialized pids run also timeshare. Priotc serialize pids with high nice value (run slow) >=that defined nice for serialize in the configuration file. ---------------------------------------------------------------------------- ------------ This FREE ENDUSER license: -Is free unloaded with the source program -This program (source/executable) can be distributed ONLY in original form and ever completely free. .This program only can be modified for internal use, and in this case can not be distributed. The modified program ever must show the program author name (initial credits). -The documentation can be modified and distributed, ever free and with the reference of the program author name. FILES priotc.c source code rutinas.h include file priotc.cfg.example configuration file example priotc.comp for compiling priotc priotc.doc documentation file priotcv.log log example priotc.ver versions (read before installing) Download bellow if you accept free_enduser license: Backup your old version before load this version. priotc.zip Report bugs to cmolimar at hotmail.com ********************************************************************************************** PAntes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos Before printing this email, assess if it is really needed. ********************* Aviso Legal ********************* Este mensaje y cualquier fichero adjunto est? dirigido ?nicamente a sus destinatarios y contiene informaci?n confidencial. Si usted considera que ha recibido este correo electr?nico por error (por el asunto, por el remitente o por cualquier otra causa), le informamos que cualquier revisi?n, alteraci?n, impresi?n, copia o transmisi?n de este mensaje o de cualquier fichero adjunto est? prohibida y puede constituir un acto ilegal. Por favor, notif?quele el error al remitente respondiendo a este e-mail y elimine el mensaje y su contenido inmediatamente. El Ministerio de Econom?a y Hacienda se reserva las acciones legales que le correspondan contra todo tercero que acceda de forma ileg?tima al contenido de cualquier mensaje externo procedente del mismo. ********************* Disclaimer ********************* This e-mail and any files transmitted with it are intended solely for the use of the intended recipients and may contain confidential information. If it appears (from the subject matter or address information or otherwise) that you received this email in error, please note that any review, dissemination, disclosure, alteration, printing, copying or transmission of this e-mail or any file transmitted with it is prohibited and may be unlawful. Please notify us by return email and delete this email and its contents immediately. Spanish Ministry of Finances may take any legal action, according with the illegal access to the content of any external message from the Ministry. ********************************************************************************************** From dtucker at zip.com.au Tue Jan 9 03:35:57 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 09 Jan 2007 03:35:57 +1100 Subject: nologin not working with openssh >= 4.3 and authentication != password In-Reply-To: <20070105165912.GA23074@weiser.dinsnail.net> References: <20070105165912.GA23074@weiser.dinsnail.net> Message-ID: <45A272ED.4020206@zip.com.au> Michael Weiser wrote: > Hi developers, > > today I tried to disable logins to an ssh server by putting a nologin > file into /etc. This only worked for logins that use the password > authentication mechanism. publickey-based authentications still > succeeded and the users were allowed into the system. This seems > straightforward to me since openssh 4.3 disabled the evaluation of > /etc/nologin in favour of pam_nologin but doesn't use PAM for anything > other than password-based logins, does it? sshd uses the PAM auth stack for password or challenge-response (aka kbdint) authentications but uses the account and session stacks for all authentication methods. > Is this a known issue or even a non-issue due to a misunderstanding on > my part? Do you have pam_nologin in the auth stack only in the PAM config file? I suspect that you just need to add pam_nologin to the account stack. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From michael at weiser.dinsnail.net Tue Jan 9 04:25:53 2007 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Mon, 8 Jan 2007 18:25:53 +0100 Subject: nologin not working with openssh >= 4.3 and authentication != password In-Reply-To: <45A272ED.4020206@zip.com.au> References: <20070105165912.GA23074@weiser.dinsnail.net> <45A272ED.4020206@zip.com.au> Message-ID: <20070108172553.GA27144@weiser.dinsnail.net> On Tue, Jan 09, 2007 at 03:35:57AM +1100, Darren Tucker wrote: > > file into /etc. This only worked for logins that use the password > > authentication mechanism. publickey-based authentications still > sshd uses the PAM auth stack for password or challenge-response (aka > kbdint) authentications but uses the account and session stacks for all > authentication methods. > > Is this a known issue or even a non-issue due to a misunderstanding on > > my part? > Do you have pam_nologin in the auth stack only in the PAM config file? Yes, exactly. > I suspect that you just need to add pam_nologin to the account stack. Thanks, that did it. The Gentoo sshd pam config seems to be broken that way. I'll open a bug with them. Thanks for your help and sorry for the (perhaps) FAQ. -- bye, Micha From sxw at inf.ed.ac.uk Thu Jan 11 05:39:37 2007 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Wed, 10 Jan 2007 18:39:37 +0000 Subject: Patches to current gssapi-with-mic support Message-ID: <69B8B234-8E12-4221-B120-9D2CBA8D5625@inf.ed.ac.uk> Would it be possible for one of the developers to look at the following Bugzilla entries, and, if suitable, apply the patches attached to each bug? http://bugzilla.mindrot.org/show_bug.cgi?id=1220 Fix error messages for multiple mechanism GSSAPI libraries http://bugzilla.mindrot.org/show_bug.cgi?id=1225 Tidy up GSSAPI code http://bugzilla.mindrot.org/show_bug.cgi?id=928 Kerberos/GSSAPI authentication does not work with multihomed hosts http://bugzilla.mindrot.org/show_bug.cgi?id=1008 GSSAPI authentication failes with Round Robin DNS hosts http://bugzilla.mindrot.org/show_bug.cgi?id=1244 Detect auth configuration failures and don't count them against the client http://bugzilla.mindrot.org/show_bug.cgi?id=1245 Add support for Darwin CCAPI Thanks, Simon. From r3r2 at yahoo.com Thu Jan 11 08:56:03 2007 From: r3r2 at yahoo.com (Ryan Robertson) Date: Wed, 10 Jan 2007 13:56:03 -0800 (PST) Subject: ssh 4.x using aix 5.3 auditing Message-ID: <20070110215603.85688.qmail@web51908.mail.yahoo.com> I'm still a bit confused as to how control-d is interpreted in ssh vs telnet. The only thing I can figure is that telnet traps control-d as User_Exit or USER_Logout and ssh interprets it as EOF. If EOF is triggered, then the auditing subsystem doesnt care. The 'logout' command is only affected if you are NOT logged into the console. ==================== test_citi:/root # grep UseLogin /usr/etc/sshd_config UseLogin no test_citi:/root # tty /dev/pts/0 test_citi:/root # logout 3004-065 You must be on the login terminal. test_citi:/root # ====================== test_citi:/root # grep UseLogin /usr/etc/sshd_config UseLogin no test_citi:/root # tty /dev/vty0 test_citi:/root # logout ============= In order to trigger the auditing subsystem, I have to do the following: add 'set -o ignoreeof'' in /etc/profile change UseLogin to "yes". this is due to the tty issue listed above. -Thanks, Ryan ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index From jochen.kirn at gmail.com Wed Jan 10 20:25:43 2007 From: jochen.kirn at gmail.com (Jochen Kirn) Date: Wed, 10 Jan 2007 10:25:43 +0100 Subject: chan_read_failed for istate 3 on serverside when scp'ing file Message-ID: <4bd05a460701100125oa3753ddnb780e93cca9ed49@mail.gmail.com> Hi, when scp'ing a file from hostA to hostB I receive following error message on the server side. Message in authlog: Jan 9 15:01:32 zapphod sshd[3229]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 The file itself is transfered correctly, so I'm wondering why this error is being logged and what this error message means It seems that the occurance of this message is not platform specific, as I have tested it on following systems platform: SuSE SLES 9, Solaris 8 & 9 SSH version: OpenSSH 4.5p1 + OpenSSL 0.98d can anybody clear me up on this ? thanks Jochen From bhanua at aztecsoft.com Thu Jan 11 16:21:42 2007 From: bhanua at aztecsoft.com (Bhanu Prakash Adhikari) Date: Thu, 11 Jan 2007 10:51:42 +0530 Subject: To restrict concurrent connections in OpenSSH 3.8p1 - developed patch Message-ID: <93F0E3CFC1ABB646B8808894FC7CDD25091900CC@azindbaex01.aztec.soft> Hi, ? I have developed a module/an enhancement for SSHD on the top of OpenSSH 3.8p1 which restricts the max no. of allowed concurrent (authenticated/non-authenticated) connections from clients. ? This restricts the cumulative sum of all the ssh activities. ? The max no. of concurrent connections allowed is a configurable parameter. ? In sshd_config, ? ??????????? MaxConcurrentConns 5 ? This will limit the allowed connections to 5. ? Would anybody be interested on the patch? ? PS: I find the feature is not supported in current OpenSSH (atleast on 3.8p1 which is of my interest). ? Thanks and rgds, Bhanu Prakash Adhikari Bangalore India ? ? ? The information contained in, or attached to, this e-mail, contains confidential information and is intended solely for the use of the individual or entity to whom they are addressed and is subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. www.aztecsoft.com From fcusack at fcusack.com Mon Jan 15 13:48:11 2007 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 14 Jan 2007 18:48:11 -0800 Subject: utmp ut_syslen bug? Message-ID: loginrec.c:794 /* ut_syslen is the length of the utx_host string */ utx->ut_syslen = MIN(strlen(li->hostname), sizeof(utx->ut_host)); But utmpx.h (on Solaris) says: short ut_syslen; /* significant length of ut_host */ /* including terminating null */ So shouldn't the code above add +1 in the strlen case? -frank From gogu at l.route666.net Tue Jan 16 23:51:26 2007 From: gogu at l.route666.net (catam) Date: Tue, 16 Jan 2007 14:51:26 +0200 (EET) Subject: patch to enable ssh use sock fd 3,4 Message-ID: Hi all I was thinking maybe other ppl need this small hack :) So ssh supports ProxyCommand which use a separate proccess for in/out chans to remote sshd. But sometimes this extra proc is not desired but ssh should use a specific socket (in below patch is fd 3 and 4) for same thing.. For example a reverse ssh connection where sshd connects back to ssh(which is executed by a a script that binds to the port then execute ssh: on sshd side: $ nc -w 60 -c '/usr/sbin/sshd -i' ssh_host 12345 on ssh side: #!/usr/bin/perl use Socket qw(:all); our $bind_port = 12345; our $bind_addr = "0"; $^F = 5; socket(my $sfd, AF_INET, SOCK_STREAM, 6) || die "socket: $!"; bind($sfd, sockaddr_in($bind_port, inet_aton $bind_addr)) || die "bind: $!"; listen($sfd,SOMAXCONN) || die "listen: $!"; accept (Cfd,$sfd); close $sfd; open 3,"<&Cfd"; open 4,"<&Cfd"; if(! grep fileno(Cfd) == $_,(3,4)) { close Cfd;} exec {ssh} qw(ssh -D2085 -oProxyCommand=:socket: user at sshd_host); So if you pass -oProxyCommand=:socket: to ssh it will not make a new child but use those 2 fd. diff -rNu openssh-4.5p1/sshconnect.c openssh-4.5p1-ssh-socket/sshconnect.c --- openssh-4.5p1/sshconnect.c 2006-10-23 20:02:24.000000000 +0300 +++ openssh-4.5p1-ssh-socket/sshconnect.c 2007-01-16 14:06:31.000000000 +0200 @@ -310,8 +310,14 @@ debug2("ssh_connect: needpriv %d", needpriv); /* If a proxy command is given, connect using it. */ - if (proxy_command != NULL) - return ssh_proxy_connect(host, port, proxy_command); + if (proxy_command != NULL) { + if(strcmp(proxy_command,":socket:")) + return ssh_proxy_connect(host, port, proxy_command); + else { + packet_set_connection(3, 4); + return 0; + } + } /* No proxy command. */ From valqk at lozenetz.org Wed Jan 17 19:05:34 2007 From: valqk at lozenetz.org (Anton Blajev - Valqk) Date: Wed, 17 Jan 2007 10:05:34 +0200 Subject: login_get_lastlog - nss enviornment - works in shell env, doesn't work when sshd calls it. Message-ID: <45ADD8CE.5040901@lozenetz.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello to every one! Maybe this is not exactly the right place, but I don't know where to ask, so... I have a FreeBSD-6-STABLE machine, setuped with custom nss lib which reads from pgsql database. It seems to be working just fine except that I can't login trought ssh, when trying the normal method. When I do $>ssh host.com tcsh I get logged and everything works - getpwent etc. but with no accounting and enviornment setuped. in the messages logs I get after a quite hard debuging and nothing found, I've decided to do some coding... C isn't my strong side, I can read(and understand) code, but I can't write good C apps....just a hacks. I've researched and exracted the function that appears in the logs: $>tail /var/log/message Jan 16 23:59:01 user sshd[74154]: fatal: login_get_lastlog: Cannot find account for uid 1010 Jan 16 23:59:01 user sshd[74148]: fatal: login_init_entry: Cannot find user "test" (the login_init_entry is there because I've turned on PrintLastLog yes before that it wasn't showing. I've found a similar problem with nss_ldap in this list but there was no answer to it. http://marc.theaimsgroup.com/?l=sun-managers&m=110686236715213&w=2 I hope I'll et one ;-) I've extracted some fucntions from loginrec.c and at the bottom of the mail is the src. The main idea is that I got the 'login_get_lastlog' function in a separate executable so I can see if it's working ok and if not I can gdb it. The interesting thing is that this app is workign just fine! The only app where the getpwuid is not wokring is sshd and I can't understand why... maybe it's in the nss implementation but please gime me ANY ideas!! Thanks and any help will be useful! BTW, I'm _not_ subscribed to this list because I'm not C dev. Please 'reply all' or to me personal.10q. Have a nice day :) Laters. [--code getpwuid.c --] #include #include #include #include #include #include #include #include #include union login_netinfo { struct sockaddr sa; struct sockaddr_in sa_in; struct sockaddr_storage sa_storage; }; /* * * logininfo structure * */ /* types - different to utmp.h 'type' macros */ /* (though set to the same value as linux, openbsd and others...) */ #define LTYPE_LOGIN 7 #define LTYPE_LOGOUT 8 /* string lengths - set very long */ #define LINFO_PROGSIZE 64 #define LINFO_LINESIZE 64 #define LINFO_NAMESIZE 128 #define LINFO_HOSTSIZE 256 struct logininfo { char progname[LINFO_PROGSIZE]; /* name of program (for PAM) */ int progname_null; short int type; /* type of login (LTYPE_*) */ int pid; /* PID of login process */ int uid; /* UID of this user */ char line[LINFO_LINESIZE]; /* tty/pty name */ char username[LINFO_NAMESIZE]; /* login username */ char hostname[LINFO_HOSTSIZE]; /* remote hostname */ /* 'exit_status' structure components */ int exit; /* process exit status */ int termination; /* process termination status */ /* struct timeval (sys/time.h) isn't always available, if it isn't we'll * use time_t's value as tv_sec and set tv_usec to 0 */ unsigned int tv_sec; unsigned int tv_usec; union login_netinfo hostaddr; /* caller's host address(es) */ }; /* struct logininfo */ /* construct a new login entry */ struct logininfo *login_alloc_entry(int pid, const char *username, const char *hostname, const char *line); /* lastlog *entry* functions fill out a logininfo */ struct logininfo *login_get_lastlog(struct logininfo *li, const int uid); int main() { int uid=1010; struct passwd *pw; struct logininfo li; pw = getpwuid(uid); printf("Starting...\n"); login_get_lastlog(&li,uid); printf("U: %s\n",li.username); printf("Done.\n"); } /* * Returns the time when the user last logged in. Returns 0 if the * information is not available. This must be called before record_login. * The host the user logged in from will be returned in buf. */ time_t get_last_login_time(uid_t uid, const char *logname, char *buf, size_t bufsize) { struct logininfo li; login_get_lastlog(&li, uid); strlcpy(buf, li.hostname, bufsize); return (time_t)li.tv_sec; } /** ** getlast_entry: Call low-level functions to retrieve the last login ** time. **/ /* take the uid in li and return the last login time */ int getlast_entry(struct logininfo *li) { #ifdef USE_LASTLOG return(lastlog_get_entry(li)); #else /* !USE_LASTLOG */ #if defined(DISABLE_LASTLOG) /* On some systems we shouldn't even try to obtain last login * time, e.g. AIX */ return (0); # elif defined(USE_WTMP) && \ (defined(HAVE_TIME_IN_UTMP) || defined(HAVE_TV_IN_UTMP)) /* retrieve last login time from utmp */ return (wtmp_get_entry(li)); # elif defined(USE_WTMPX) && \ (defined(HAVE_TIME_IN_UTMPX) || defined(HAVE_TV_IN_UTMPX)) /* If wtmp isn't available, try wtmpx */ return (wtmpx_get_entry(li)); # else /* Give up: No means of retrieving last login time */ return (0); # endif /* DISABLE_LASTLOG */ #endif /* USE_LASTLOG */ } struct logininfo * login_get_lastlog(struct logininfo *li, const int uid) { struct passwd *pw; memset(li, '\0', sizeof(*li)); li->uid = uid; /* * If we don't have a 'real' lastlog, we need the username to * reliably search wtmp(x) for the last login (see * wtmp_get_entry().) */ pw = getpwuid(uid); if (pw == NULL) { printf("FATAL::: %s: Cannot find account for uid %i", __func__, uid); exit(1); } /* No MIN_SIZEOF here - we absolutely *must not* truncate the * username (XXX - so check for trunc!) */ strlcpy(li->username, pw->pw_name, sizeof(li->username)); if (getlast_entry(li)) return (li); else return (NULL); } [--endcode--] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFrdjOzpU6eaWiiWgRAvLEAJ9k1JsYcJKqqZHBHAWdVW4zxX8/ogCeIJtA 8ZDq6uy5Eeq8m2egG7Gkwqw= =2xpF -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From Jan.Pechanec at Sun.COM Fri Jan 19 05:52:51 2007 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Thu, 18 Jan 2007 19:52:51 +0100 (CET) Subject: proposal: new DisableBanner client side option Message-ID: hi all, we had quite a few requests recently so that SunSSH allowed to hush a banner on client side when in command-mode only. The argument usually is that the banner is mandatory due to legal reasons so first time login users should see it but that it causes problems when ssh is used from scripts after that. '-q' often seems not an option. RFC 4252 permits hushing banner in section 5.4. we want to add DisableBanner option to SunSSH with yes/no/in-exec-mode arguments, default to "no". It's designed to be extendable in a backward compatible way to a comma separated list of "in--mode" strings if needed in the future. "in-subsystem-mode" could be the next candidate. since we try to avoid divergence with upstream (= OpenSSH) if possible I would like to ask, in case you would be interested in adding such functionality to OpenSSH in which case I can provide a patch then, whether this would be an acceptible syntax for both. thanks, Jan. -- Jan Pechanec Sun Microsystems From djm at mindrot.org Fri Jan 19 08:37:27 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 19 Jan 2007 08:37:27 +1100 (EST) Subject: proposal: new DisableBanner client side option In-Reply-To: References: Message-ID: On Thu, 18 Jan 2007, Jan Pechanec wrote: > > hi all, we had quite a few requests recently so that SunSSH allowed > to hush a banner on client side when in command-mode only. The argument > usually is that the banner is mandatory due to legal reasons so first time > login users should see it but that it causes problems when ssh is used from > scripts after that. '-q' often seems not an option. RFC 4252 permits hushing > banner in section 5.4. "ssh -q" or the "Loglevel quiet" config option will hush the banner fine on OpenSSH. IMO not doing so "for legal reasons" is just silly. What next, will Solaris disable stderr redirection to prevent someone from missing a disclaimer? If people want to stick their heads in the sand then they will find a way. > we want to add DisableBanner option to SunSSH with > yes/no/in-exec-mode arguments, default to "no". It's designed to be > extendable in a backward compatible way to a comma separated list of > "in--mode" strings if needed in the future. "in-subsystem-mode" could > be the next candidate. > > since we try to avoid divergence with upstream (= OpenSSH) if > possible I would like to ask, in case you would be interested in adding such > functionality to OpenSSH in which case I can provide a patch then, whether > this would be an acceptible syntax for both. Thanks for making the effort to retain compatibility, but OpenSSH won't adopt such an option. I don't think it is necessary, and there is a strong consensus among the developers to have fewer, rather than more, options. -d From Jan.Pechanec at Sun.COM Fri Jan 19 09:33:00 2007 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Thu, 18 Jan 2007 23:33:00 +0100 (CET) Subject: proposal: new DisableBanner client side option In-Reply-To: <200701182223.l0IMNBtn009116@ganymede.nas.nasa.gov> References: <200701182223.l0IMNBtn009116@ganymede.nas.nasa.gov> Message-ID: On Thu, 18 Jan 2007, Iain Morgan wrote: >Hi Jan, > >At the risk of pointing out what you may already be aware of, the >banner can be suppressed by setting the LogLevel to quiet, fatal, or >error. Setting it to 'error' allows the banner to be suppressed without hello Iain, I know that, my note about '-q' option was probably an overly subtle attempt to say that some customers really want to hush banner but they do want to see other warnings at the same time. So, using '-q' is not an solution for them. thanks, Jan. -- Jan Pechanec From imorgan at nas.nasa.gov Fri Jan 19 09:23:11 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 18 Jan 2007 14:23:11 -0800 (PST) Subject: proposal: new DisableBanner client side option In-Reply-To: from Jan Pechanec at "Jan 18, 2007 07:52:51 pm" Message-ID: <200701182223.l0IMNBtn009116@ganymede.nas.nasa.gov> Sometime ago, Jan Pechanec wrote: > > hi all, we had quite a few requests recently so that SunSSH allowed > to hush a banner on client side when in command-mode only. The argument > usually is that the banner is mandatory due to legal reasons so first time > login users should see it but that it causes problems when ssh is used from > scripts after that. '-q' often seems not an option. RFC 4252 permits hushing > banner in section 5.4. > > we want to add DisableBanner option to SunSSH with > yes/no/in-exec-mode arguments, default to "no". It's designed to be > extendable in a backward compatible way to a comma separated list of > "in--mode" strings if needed in the future. "in-subsystem-mode" could > be the next candidate. > > since we try to avoid divergence with upstream (= OpenSSH) if > possible I would like to ask, in case you would be interested in adding such > functionality to OpenSSH in which case I can provide a patch then, whether > this would be an acceptible syntax for both. > > thanks, Jan. > Hi Jan, At the risk of pointing out what you may already be aware of, the banner can be suppressed by setting the LogLevel to quiet, fatal, or error. Setting it to 'error' allows the banner to be suppressed without throwing away authentication errors etc. -- Iain Morgan From martin at oneiros.de Fri Jan 19 10:28:51 2007 From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=) Date: Fri, 19 Jan 2007 00:28:51 +0100 Subject: proposal: new DisableBanner client side option In-Reply-To: References: <200701182223.l0IMNBtn009116@ganymede.nas.nasa.gov> Message-ID: <68c491a60701181528x727d7284g115cde46f056b44b@mail.gmail.com> 2007/1/18, Jan Pechanec : > I know that, my note about '-q' option was probably an overly subtle > attempt to say that some customers really want to hush banner but they do > want to see other warnings at the same time. So, using '-q' is not an > solution for them. Have these "customers" supported OpenSSH in any way? http://www.openssh.com/donations.html Best Martin From Jan.Pechanec at Sun.COM Fri Jan 19 11:02:35 2007 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Fri, 19 Jan 2007 01:02:35 +0100 (CET) Subject: proposal: new DisableBanner client side option In-Reply-To: <68c491a60701181528x727d7284g115cde46f056b44b@mail.gmail.com> References: <200701182223.l0IMNBtn009116@ganymede.nas.nasa.gov> <68c491a60701181528x727d7284g115cde46f056b44b@mail.gmail.com> Message-ID: On Fri, 19 Jan 2007, [ISO-8859-1] Martin Schr?der wrote: >2007/1/18, Jan Pechanec : >> I know that, my note about '-q' option was probably an overly subtle >> attempt to say that some customers really want to hush banner but they do >> want to see other warnings at the same time. So, using '-q' is not an >> solution for them. > >Have these "customers" supported OpenSSH in any way? > >http://www.openssh.com/donations.html not sure about that. I did. Martin, I don't think it matters here, they want it in SunSSH, we think it's reasonable and we developers just wanted to make sure we had the same interface in case OpenSSH team liked the idea. Jan. -- Jan Pechanec From Jan.Pechanec at Sun.COM Sat Jan 20 00:53:15 2007 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Fri, 19 Jan 2007 14:53:15 +0100 (CET) Subject: proposal: new DisableBanner client side option In-Reply-To: <20070119125933.GA1197@folly> References: <200701182223.l0IMNBtn009116@ganymede.nas.nasa.gov> <20070119125933.GA1197@folly> Message-ID: On Fri, 19 Jan 2007, Markus Friedl wrote: >On Thu, Jan 18, 2007 at 11:33:00PM +0100, Jan Pechanec wrote: >> I know that, my note about '-q' option was probably an overly subtle >> attempt to say that some customers really want to hush banner but they do >> want to see other warnings at the same time. So, using '-q' is not an >> solution for them. > >LogLevel=ERROR > >suppresses banners and keeps other warnings. otherwise you have yes, but logit() uses default INFO level and still is used for warnings sometimes. To change level of some mesages seems more confusing for me that adding an option for a special case of banner message. Jan. -- Jan Pechanec From lsloan at umich.edu Fri Jan 19 07:24:58 2007 From: lsloan at umich.edu (Lance E Sloan) Date: Thu, 18 Jan 2007 15:24:58 -0500 Subject: SSH_ASKPASS behavior change proposal Message-ID: <20070118152458.4cepi1r1cggoc8ow@web.mail.umich.edu> Hello, OpenSSH Developers! I'm not a member of the OpenSSH development team or a member of this mailing list. I have a small change to propose for OpenSSH and since the mailing list page at openssh.com indicated the general discussion list is for support, I thought this list would be a better place to discuss this. Please forgive me if I've committed a faux pas. I propose that the ssh command-line client be changed so that it will use whatever program is specified in the SSH_ASKPASS environment variable regardless of whether ssh has a terminal associated with it or not. In order for this to work, SSH_ASKPASS would need to contain the full path to a program that prompts for a password, DISPLAY would also need to be set, and some additional environment variable would need to be set to instruct ssh to ignore the no-tty requirement. My reason for proposing this is because the system administrators at my organization do not allow us to keep public keys for ssh authentication. They have put a "PubkeyAuthentication no" directive in the sshd_config file on our servers. They have two reasons for doing this. First, I believe they think this is more secure. Second, and more importantly, the interactive password authentication on these servers also gets Kerberos tickets and AFS tokens for the user as they log in. This latter part could probably be accomplished by the user keeping their Kerberos authentication information in an encrypted file, but it would be very hard to guarantee the security of that file. This inability to use public key authentication with ssh makes it very difficult, sometimes even impossible, to use CVS or Subversion clients with repositories on those servers. Some operations with these clients may require several individual commands to the repository. Some CVS or SVN clients might then prompt the user for their password with each command while some clients just fail. Using a stock ssh client from OpenSSH with the path to a password prompting and caching program in the SSH_ASKPASS environment variable will solve the problem for most CVS or SVN GUI clients, since they usually do not have a terminal associated with them. Using a command-line CVS or SVN client with repositories on those servers is still a problem, though. The command-line client obviously has a terminal associated with it, so ssh would not normally invoke the password prompting program indicated by SSH_ASKPASS. If the user is to run a script with many CVS or SVN commands in it, they will be prompted for their password every time. Besides running scripts, there are plenty or reasons why one would want to use a command-line CVS or SVN client, especially if the available GUI clients are broken or quirky. As a test of my proposal, I changed the readpass.c file in my copy of the source to look for an environment variable named "SSH_ASKPASS_IGNORETTY". If that environment variable is set, the use_askpass variable is set in the code. With that variable set (SSH_ASKPASS and DISPLAY are set appropriately, too), when I run a command-line CVS or SVN client against a repository through ssh on a server that requires passwords, the program I specified is started and supplies the password to ssh. Currently, the program I specify with SSH_ASKPASS prompts me for my password and can optionally cache the password in my account to avoid prompts in the future. It is a GUI program written just for this purpose that I found on the Internet. I am working on a replacement for this program that would prompt for and optionally cache passwords, but also give the user the choice of storing it (as the current program does) or to just cache the password in memory for as long as the user is logged in. I hope that my proposal is reasonable. I welcome your thoughts, discussion, and critique. (Constructive criticism only, please.) Thank you for your time! -- Lance E Sloan, Application Developer Evil is my middle name. Some people think it's Eugene, though. U-M ITCS ITCom Information Systems http://www.itcom.itcs.umich.edu/ From markus.r.friedl at arcor.de Fri Jan 19 23:59:33 2007 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Fri, 19 Jan 2007 13:59:33 +0100 Subject: proposal: new DisableBanner client side option In-Reply-To: References: <200701182223.l0IMNBtn009116@ganymede.nas.nasa.gov> Message-ID: <20070119125933.GA1197@folly> On Thu, Jan 18, 2007 at 11:33:00PM +0100, Jan Pechanec wrote: > I know that, my note about '-q' option was probably an overly subtle > attempt to say that some customers really want to hush banner but they do > want to see other warnings at the same time. So, using '-q' is not an > solution for them. LogLevel=ERROR suppresses banners and keeps other warnings. otherwise you have to add options for every message printed. From vincenzo.sciarra at gmail.com Sat Jan 20 03:40:11 2007 From: vincenzo.sciarra at gmail.com (Vincenzo Sciarra) Date: Fri, 19 Jan 2007 17:40:11 +0100 Subject: PMI patch for OpenSSH 4.4p1 In-Reply-To: <199b4dc20701190045h70849340td81f8f337c916c6d@mail.gmail.com> References: <199b4dc20701190045h70849340td81f8f337c916c6d@mail.gmail.com> Message-ID: <199b4dc20701190840h248ffe7awbacda40b52b9ad44@mail.gmail.com> I have just published a pre-alfa of a patch that has the goal to make OpenSSH aware with PMI. Reference site : http://nutmay.sourceforge.net -- Vincenzo Sciarra From imorgan at nas.nasa.gov Sat Jan 20 04:08:49 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 19 Jan 2007 09:08:49 -0800 (PST) Subject: SSH_ASKPASS behavior change proposal In-Reply-To: <20070118152458.4cepi1r1cggoc8ow@web.mail.umich.edu> from Lance E Sloan at "Jan 18, 2007 03:24:58 pm" Message-ID: <200701191708.l0JH8n7u002505@ganymede.nas.nasa.gov> You could address the CVS/SVN issue using session multiplexing. See the entries for ControlMaster and ControlPath in the ssh(1) man page. Sometime ago, Lance E Sloan wrote: > Hello, OpenSSH Developers! > > I'm not a member of the OpenSSH development team or a member of this > mailing list. I have a small change to propose for OpenSSH and since > the mailing list page at openssh.com indicated the general discussion > list is for support, I thought this list would be a better place to > discuss this. Please forgive me if I've committed a faux pas. > > I propose that the ssh command-line client be changed so that it will > use whatever program is specified in the SSH_ASKPASS environment > variable regardless of whether ssh has a terminal associated with it or > not. In order for this to work, SSH_ASKPASS would need to contain the > full path to a program that prompts for a password, DISPLAY would also > need to be set, and some additional environment variable would need to > be set to instruct ssh to ignore the no-tty requirement. > > My reason for proposing this is because the system administrators at my > organization do not allow us to keep public keys for ssh > authentication. They have put a "PubkeyAuthentication no" directive in > the sshd_config file on our servers. They have two reasons for doing > this. First, I believe they think this is more secure. Second, and > more importantly, the interactive password authentication on these > servers also gets Kerberos tickets and AFS tokens for the user as they > log in. This latter part could probably be accomplished by the user > keeping their Kerberos authentication information in an encrypted file, > but it would be very hard to guarantee the security of that file. > > This inability to use public key authentication with ssh makes it very > difficult, sometimes even impossible, to use CVS or Subversion clients > with repositories on those servers. Some operations with these clients > may require several individual commands to the repository. Some CVS or > SVN clients might then prompt the user for their password with each > command while some clients just fail. Using a stock ssh client from > OpenSSH with the path to a password prompting and caching program in > the SSH_ASKPASS environment variable will solve the problem for most > CVS or SVN GUI clients, since they usually do not have a terminal > associated with them. > > Using a command-line CVS or SVN client with repositories on those > servers is still a problem, though. The command-line client obviously > has a terminal associated with it, so ssh would not normally invoke the > password prompting program indicated by SSH_ASKPASS. If the user is to > run a script with many CVS or SVN commands in it, they will be prompted > for their password every time. Besides running scripts, there are > plenty or reasons why one would want to use a command-line CVS or SVN > client, especially if the available GUI clients are broken or quirky. > > As a test of my proposal, I changed the readpass.c file in my copy of > the source to look for an environment variable named > "SSH_ASKPASS_IGNORETTY". If that environment variable is set, the > use_askpass variable is set in the code. With that variable set > (SSH_ASKPASS and DISPLAY are set appropriately, too), when I run a > command-line CVS or SVN client against a repository through ssh on a > server that requires passwords, the program I specified is started and > supplies the password to ssh. > > Currently, the program I specify with SSH_ASKPASS prompts me for my > password and can optionally cache the password in my account to avoid > prompts in the future. It is a GUI program written just for this > purpose that I found on the Internet. I am working on a replacement > for this program that would prompt for and optionally cache passwords, > but also give the user the choice of storing it (as the current program > does) or to just cache the password in memory for as long as the user > is logged in. > > I hope that my proposal is reasonable. I welcome your thoughts, > discussion, and critique. (Constructive criticism only, please.) > > Thank you for your time! > > -- > Lance E Sloan, Application Developer > Evil is my middle name. Some people think it's Eugene, though. > U-M ITCS ITCom Information Systems > http://www.itcom.itcs.umich.edu/ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Iain Morgan From rapier at psc.edu Sat Jan 20 04:57:39 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 19 Jan 2007 12:57:39 -0500 Subject: proposal: new DisableBanner client side option In-Reply-To: <68c491a60701181528x727d7284g115cde46f056b44b@mail.gmail.com> References: <200701182223.l0IMNBtn009116@ganymede.nas.nasa.gov> <68c491a60701181528x727d7284g115cde46f056b44b@mail.gmail.com> Message-ID: <45B10693.8090405@psc.edu> So the implication of this is that if we give OpenSSH money then they'll incorporate our patches? So how much money? Is there a price list somewhere? ;) Chris (yes, I'm kidding around) Martin Schr?der wrote: > 2007/1/18, Jan Pechanec : >> I know that, my note about '-q' option was probably an overly subtle >> attempt to say that some customers really want to hush banner but they do >> want to see other warnings at the same time. So, using '-q' is not an >> solution for them. > > Have these "customers" supported OpenSSH in any way? > > http://www.openssh.com/donations.html > > Best > Martin > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dkg-openssh.com at fifthhorseman.net Sat Jan 20 05:02:17 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Jan 2007 13:02:17 -0500 Subject: PMI patch for OpenSSH 4.4p1 In-Reply-To: <199b4dc20701190840h248ffe7awbacda40b52b9ad44@mail.gmail.com> References: <199b4dc20701190045h70849340td81f8f337c916c6d@mail.gmail.com> <199b4dc20701190840h248ffe7awbacda40b52b9ad44@mail.gmail.com> Message-ID: <17841.1961.922345.560721@squeak.fifthhorseman.net> At 2007-01-19 17:40, vincenzo.sciarra at gmail.com said: > I have just published a pre-alfa of a patch that has the goal to > make OpenSSH aware with PMI. > > Reference site : http://nutmay.sourceforge.net I don't know what PMI is. Google suggests "Project Management Institute" or maybe "Plumbing Manufacturers Institute", but i don't see how these are relevant to ssh. A short blurb about what PMI is would help me understand why i should care about nutmay. Thanks, --dkg From imorgan at nas.nasa.gov Sat Jan 20 06:56:44 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 19 Jan 2007 11:56:44 -0800 (PST) Subject: SSH_ASKPASS behavior change proposal In-Reply-To: <20070119141756.mgrxjv3io8sw00c8@web.mail.umich.edu> from Lance E Sloan at "Jan 19, 2007 02:17:56 pm" Message-ID: <200701191956.l0JJuigQ027404@ganymede.nas.nasa.gov> Sometime ago, Lance E Sloan wrote: > Mr. Morgan, thank you very much for the response. > > Yes, I think I see how that could help. I could start up an ssh > control master in another window that connects to the CVS/SVN > repository before I start a client. It doesn't have to be in a separate window. You can use -fN to have ssh prompt for the password and then background itself. > > I have a question about the "ask" setting for ControlMaster. The > manpage says: > > Setting this to ``ask'' will cause ssh to listen for control > connections, but require confirmation using the SSH_ASKPASS program > before they are accepted (see ssh-add(1) for details). > > I tried this, and ssh did indeed invoke my SSH_ASKPASS, but I wasn't > sure what the correct response was. I tried my password for the remote > host and password for my local host. Neither worked. Then I noticed > that it was prompting "Allow shared connection to [hostname_here]?", so > I tried answering "y" and "yes", but neither of those worked, either. > > What kind of answer is it expecting? In this context, no password is required. Simply select either 'OK' or 'Cancel. > > Quoting Iain Morgan (Fri 19 Jan 2007 12:08:49 PM EST): > > You could address the CVS/SVN issue using session multiplexing. See > > the entries for ControlMaster and ControlPath in the ssh(1) man page. > > > > Sometime ago, Lance E Sloan wrote: > >> I propose that the ssh command-line client be changed so that it will > >> use whatever program is specified in the SSH_ASKPASS environment > >> variable regardless of whether ssh has a terminal associated with it > >> or not. > > -- > Lance E Sloan, Application Developer > Evil is my middle name. Some people think it's Eugene, though. > U-M ITCS ITCom Information Systems > http://www.itcom.itcs.umich.edu/ > -- Iain Morgan From lsloan at umich.edu Sat Jan 20 06:17:56 2007 From: lsloan at umich.edu (Lance E Sloan) Date: Fri, 19 Jan 2007 14:17:56 -0500 Subject: SSH_ASKPASS behavior change proposal In-Reply-To: <200701191708.l0JH8n7u002505@ganymede.nas.nasa.gov> References: <200701191708.l0JH8n7u002505@ganymede.nas.nasa.gov> Message-ID: <20070119141756.mgrxjv3io8sw00c8@web.mail.umich.edu> Mr. Morgan, thank you very much for the response. Yes, I think I see how that could help. I could start up an ssh control master in another window that connects to the CVS/SVN repository before I start a client. I have a question about the "ask" setting for ControlMaster. The manpage says: Setting this to ``ask'' will cause ssh to listen for control connections, but require confirmation using the SSH_ASKPASS program before they are accepted (see ssh-add(1) for details). I tried this, and ssh did indeed invoke my SSH_ASKPASS, but I wasn't sure what the correct response was. I tried my password for the remote host and password for my local host. Neither worked. Then I noticed that it was prompting "Allow shared connection to [hostname_here]?", so I tried answering "y" and "yes", but neither of those worked, either. What kind of answer is it expecting? Quoting Iain Morgan (Fri 19 Jan 2007 12:08:49 PM EST): > You could address the CVS/SVN issue using session multiplexing. See > the entries for ControlMaster and ControlPath in the ssh(1) man page. > > Sometime ago, Lance E Sloan wrote: >> I propose that the ssh command-line client be changed so that it will >> use whatever program is specified in the SSH_ASKPASS environment >> variable regardless of whether ssh has a terminal associated with it >> or not. -- Lance E Sloan, Application Developer Evil is my middle name. Some people think it's Eugene, though. U-M ITCS ITCom Information Systems http://www.itcom.itcs.umich.edu/ From dtucker at zip.com.au Sat Jan 20 13:30:06 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 20 Jan 2007 13:30:06 +1100 Subject: PMI patch for OpenSSH 4.4p1 In-Reply-To: <199b4dc20701190840h248ffe7awbacda40b52b9ad44@mail.gmail.com> References: <199b4dc20701190045h70849340td81f8f337c916c6d@mail.gmail.com> <199b4dc20701190840h248ffe7awbacda40b52b9ad44@mail.gmail.com> Message-ID: <45B17EAE.4020600@zip.com.au> Vincenzo Sciarra wrote: > I have just published a pre-alfa of a patch that has the goal to make > OpenSSH aware with PMI. > > Reference site : http://nutmay.sourceforge.net Out of curiosity I looked at the patch. I'm still none the wiser about what PMI is. The patch makes interesting reading, though. +char identity[80]; [...] + sprintf(identity,"NULL"); sprintf is generally frowned apon. This one is not really a problem since it's a static string of known size but is still bad form. I suggest strlcpy(identity, "NULL", sizeof(identity)) instead (if you really need to have the literal string of "NULL", which I suspect you don't). This one, however: + type=packet_read(); + if (type==SSH2_ACMSG_PATH) { + ACpath = packet_get_string(NULL); [...] + char patholo[100]; + sprintf(patholo,"%s",ACpath); ... reads an arbitrary string from the network the sprintf's it into fixed-length string on the stack. This is not a great idea. Moving along, + mfp=fopen("/etc/ssh/identity","r"); + if (mfp==NULL) + debug3("No identity file found. Skipping Attribute Authentication"); + + if (mfp!=NULL) { if-else would make this easier to read. + debug3("Looking for your Attribute Identity"); + debug3("/etc/ssh/identity opened"); + + while (!feof(mfp)) { + fscanf(mfp,"%s",mkey); + fscanf(mfp,"%s",temp); mkey and temp are fixed length strings, so larger-than-expected contents of /etc/ssh/identity will overflow them. + if (strcmp(fp,mkey) == 0) { + debug2("Client Attribute identity seems to be : %s ",&temp); temp is a char array, so &temp is a pointer to the array. Surprisingly this works, but gcc will generate a warning for such constructs. I suggest you use -Wall or equivalent and fix anything in your code that it complains about. + strcpy(options.ACid,temp); strcpy bad too. Use strlcpy at least. The code also doesn't fclose(mfp) and so leaks FILE structs. The next bit is from auth2-pubkey.c, which is only used in sshd: + printf("\nLooking for your Attribute Certificate"); sshd is a daemon and normally runs without stdio connected. This will write to fd 1 which, when daemonized, could be anything, but will probably be the socket connected to the client. In that case it will break protocol and the client will disconnect. Use debug() instead. The following sequence is from server_loop2: + sprintf(buffer,"GET %s HTTP/1.0\n\n",patholo); sprintf bad. + gethostname(protocol,80); + sockadd=socket_init(protocol,port); This is confusing, but it looks like this is trying to connect to the local host, reusing "protocol" for the hostname. gethostname can fail and you're not checking for it. You would probably be better off using getaddrinfo with a NULL host to talk to the loopback interface. + write(sockadd,buffer,50); What if there's more that 50 characters in the buffer? I gave up at this point, but there's also declarations after code, which some (pre C99) compilers won't accept, and many no-op changes in the diff that only make it harder to read. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jon at cybus.co.uk Sat Jan 20 15:09:06 2007 From: jon at cybus.co.uk (Jonathan Miles) Date: Sat, 20 Jan 2007 04:09:06 +0000 Subject: Configurable restrictions Message-ID: <45B195E2.7020007@cybus.co.uk> Today I modified OpenSSH so that it allows me to configure in a generic way, restrictions on what server functions can be used by system users after they authenticate. The partial implementation of my plans only works for SSH2, but allows me to write entries like the following in sshd_config: ChannelReqDeny shell g restricted ChannelReqDeny exec g restricted ChannelReqDeny x11-req u * ... to deny access to those channel requests for group 'restricted'. Using my modified sftp-server, I can also write this: Subsystem sftp /path/to/sftp-server SetIf g restricted Subsystem sftp /path/to/sftp-server --chroot ... and anyone in the same group is jailed to the cwd, i.e. their home directory. The above works fine, but I want to expand it further. Bearing in mind that 2 days ago I'd never before looked at the SSH code or the RFCs, I thought I'd get some feedback from people on this list. What do you think? Are these features useful for other people? Am I taking the right approach? It's a really simple implementation, using single-linked lists in the Options struct which are scanned at the right places. The SetIf list is checked in do_authenticated() and the command processed as a normal configuration line. Due to the fork() model, I'm under the impression that the latter option's changes can't persist beyond the current session. I considered all sorts of other more flexible approaches, but I don't have a lot of time to spend on this. IMHO this way allows expansion for features that immediately come to mind, such as matching on IP, allow lists and then choosing deny/allow order. Given a few of hours of free time in the next week, I'd like to decide what to do about connections using other versions of the protocol (which currently bypass these restrictions) and further develop the approach to cover the other 2 major messages detailed below. * SSH_MSG_GLOBAL_REQUEST {"tcpip-forward", "cancel-tcpip-forward", "direct-tcpip"} returning SSH_MSG_REQUEST_FAILURE * SSH_MSG_CHANNEL_OPEN {"session", "x11", etc...} returning SSH_OPEN_ADMINISTRATIVELY_PROHIBITED I'm also going to resolve an issue where sftp-server can't send the client the real user/group after chroot(). Eventually, I could see this code becoming a base for more user-friendly options based on functionality rather than protocol messages. e.g. the option 'X11Forwarding no' could add to the ChannelDeny list rather than cluttering the code with the existing extra variables; 'AllowExec no' could do the same as denying 'exec' and 'shell'. I'll have to grab the latest version of OpenSSH (this was done on the version distributed with Ubuntu stable - 4.3p2) and sync the changes up before posting a patch. Jon. From dtucker at zip.com.au Sat Jan 20 16:26:26 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 20 Jan 2007 16:26:26 +1100 Subject: Configurable restrictions In-Reply-To: <45B195E2.7020007@cybus.co.uk> References: <45B195E2.7020007@cybus.co.uk> Message-ID: <45B1A802.9020204@zip.com.au> Jonathan Miles wrote: > Today I modified OpenSSH so that it allows me to configure in a generic > way, restrictions on what server functions can be used by system users > after they authenticate. The partial implementation of my plans only > works for SSH2, but allows me to write entries like the following in > sshd_config: > > ChannelReqDeny shell g restricted > ChannelReqDeny exec g restricted > ChannelReqDeny x11-req u * > > ... to deny access to those channel requests for group 'restricted'. > > Using my modified sftp-server, I can also write this: > > Subsystem sftp /path/to/sftp-server > SetIf g restricted Subsystem sftp /path/to/sftp-server --chroot > > ... and anyone in the same group is jailed to the cwd, i.e. their home > directory. > > The above works fine, but I want to expand it further. Bearing in mind > that 2 days ago I'd never before looked at the SSH code or the RFCs, I > thought I'd get some feedback from people on this list. > > What do you think? Are these features useful for other people? Am I > taking the right approach? You should have a look at the Match directive that's in 4.4 and up, which provides a general mechanism for matching users, groups, networks and hosts. It works similarly to the Hosts directive in ssh_config. Your example above would be: Match Group restricted ChannelReqDeny shell ChannelReqDeny exec (and so on). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From brhamon at cisco.com Sun Jan 21 07:00:31 2007 From: brhamon at cisco.com (Brian Hamon (brhamon)) Date: Sat, 20 Jan 2007 12:00:31 -0800 Subject: PMI patch for OpenSSH 4.4p1 In-Reply-To: <45B17EAE.4020600@zip.com.au> References: <199b4dc20701190045h70849340td81f8f337c916c6d@mail.gmail.com><199b4dc20701190840h248ffe7awbacda40b52b9ad44@mail.gmail.com> <45B17EAE.4020600@zip.com.au> Message-ID: <66EB4A5E3F739E40BFC2567243002B8302B9F390@xmb-sjc-228.amer.cisco.com> I also browsed that code and found that new messages were being added to the protocol that would allow an unauthenticated client to provide the hostname and URL that the ssh server host would then connect to and read 2K into a buffer. Ignoring the buffer overflow issues Darren raised, it is almost never a good idea to allow a client to drive that kind of behavior. It opens up a terrible denial of service capability, as the vast installed base of OpenSSH servers could be turned into a widely distributed DoS attack engine that some nefarious person could direct against a single web server. At that point I stopped reading. I do think there is a correct way to provide a distributed authentication mechanism, perhaps by leveraging LDAP or secure DNS. The domain for these discussions would be on within the LDAP, sDNS or Kerberos development communities. -----Original Message----- From: openssh-unix-dev-bounces+brhamon=cisco.com at mindrot.org [mailto:openssh-unix-dev-bounces+brhamon=cisco.com at mindrot.org] On Behalf Of Darren Tucker Sent: Friday, January 19, 2007 8:30 PM To: Vincenzo Sciarra Cc: openssh-unix-dev at mindrot.org Subject: Re: PMI patch for OpenSSH 4.4p1 Vincenzo Sciarra wrote: > I have just published a pre-alfa of a patch that has the goal to make > OpenSSH aware with PMI. > > Reference site : http://nutmay.sourceforge.net Out of curiosity I looked at the patch. I'm still none the wiser about what PMI is. The patch makes interesting reading, though. +char identity[80]; [...] + sprintf(identity,"NULL"); sprintf is generally frowned apon. This one is not really a problem since it's a static string of known size but is still bad form. I suggest strlcpy(identity, "NULL", sizeof(identity)) instead (if you really need to have the literal string of "NULL", which I suspect you don't). This one, however: + type=packet_read(); + if (type==SSH2_ACMSG_PATH) { + ACpath = packet_get_string(NULL); [...] + char patholo[100]; + sprintf(patholo,"%s",ACpath); ... reads an arbitrary string from the network the sprintf's it into fixed-length string on the stack. This is not a great idea. Moving along, + mfp=fopen("/etc/ssh/identity","r"); + if (mfp==NULL) + debug3("No identity file found. Skipping Attribute Authentication"); + + if (mfp!=NULL) { if-else would make this easier to read. + debug3("Looking for your Attribute Identity"); + debug3("/etc/ssh/identity opened"); + + while (!feof(mfp)) { + fscanf(mfp,"%s",mkey); + fscanf(mfp,"%s",temp); mkey and temp are fixed length strings, so larger-than-expected contents of /etc/ssh/identity will overflow them. + if (strcmp(fp,mkey) == 0) { + debug2("Client Attribute identity seems to be : %s ",&temp); temp is a char array, so &temp is a pointer to the array. Surprisingly this works, but gcc will generate a warning for such constructs. I suggest you use -Wall or equivalent and fix anything in your code that it complains about. + strcpy(options.ACid,temp); strcpy bad too. Use strlcpy at least. The code also doesn't fclose(mfp) and so leaks FILE structs. The next bit is from auth2-pubkey.c, which is only used in sshd: + printf("\nLooking for your Attribute Certificate"); sshd is a daemon and normally runs without stdio connected. This will write to fd 1 which, when daemonized, could be anything, but will probably be the socket connected to the client. In that case it will break protocol and the client will disconnect. Use debug() instead. The following sequence is from server_loop2: + sprintf(buffer,"GET %s HTTP/1.0\n\n",patholo); sprintf bad. + gethostname(protocol,80); + sockadd=socket_init(protocol,port); This is confusing, but it looks like this is trying to connect to the local host, reusing "protocol" for the hostname. gethostname can fail and you're not checking for it. You would probably be better off using getaddrinfo with a NULL host to talk to the loopback interface. + write(sockadd,buffer,50); What if there's more that 50 characters in the buffer? I gave up at this point, but there's also declarations after code, which some (pre C99) compilers won't accept, and many no-op changes in the diff that only make it harder to read. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From lucho at ionkov.net Sun Jan 21 16:14:14 2007 From: lucho at ionkov.net (Latchesar Ionkov) Date: Sat, 20 Jan 2007 22:14:14 -0700 Subject: remote port forwarding with dynamic port on the far end Message-ID: Hi, I would like to use ssh in a quite a strange setup. For every ssh connection the near end starts a service (listening on a free TCP port) that has to be available to the program running on the far end. I would like to have the connection going through SSH (for encryption) so I decided to use remote port forwarding. The problem is that there could be multiple connections of that type to the remote box, so I cannot use constant port on the far end. The first question I have is whether a (fairly trivial) patch that allows ssh -R 0:host:hostport for unprivileged user is going to be accepted? bind on a zero port will pick a free port on the far end, exactly what I need. -R 0:host:port dynamically chosing the port on the far end is not very useful if I don't know the port that was chosen by the system :) So the second question is whether it is acceptible to add a new environment variable passed to the client (say SSH_FORWARDS) that lists all port forwards that the client initiated? Thanks, Lucho From michael at weiser.dinsnail.net Tue Jan 23 09:06:27 2007 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Mon, 22 Jan 2007 22:06:27 -0000 Subject: nologin not working with openssh >= 4.3 and authentication != password Message-ID: <20070105165912.GA23074@weiser.dinsnail.net> Hi developers, today I tried to disable logins to an ssh server by putting a nologin file into /etc. This only worked for logins that use the password authentication mechanism. publickey-based authentications still succeeded and the users were allowed into the system. This seems straightforward to me since openssh 4.3 disabled the evaluation of /etc/nologin in favour of pam_nologin but doesn't use PAM for anything other than password-based logins, does it? Is this a known issue or even a non-issue due to a misunderstanding on my part? -- Thanks in advance, bye, Michael From djm at mindrot.org Tue Jan 23 09:27:46 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 23 Jan 2007 09:27:46 +1100 (EST) Subject: nologin not working with openssh >= 4.3 and authentication != password In-Reply-To: <20070105165912.GA23074@weiser.dinsnail.net> References: <20070105165912.GA23074@weiser.dinsnail.net> Message-ID: On Fri, 5 Jan 2007, Michael Weiser wrote: > Hi developers, > > today I tried to disable logins to an ssh server by putting a nologin > file into /etc. This only worked for logins that use the password > authentication mechanism. publickey-based authentications still > succeeded and the users were allowed into the system. This seems > straightforward to me since openssh 4.3 disabled the evaluation of > /etc/nologin in favour of pam_nologin but doesn't use PAM for anything > other than password-based logins, does it? Yes, PAM account and session modules are run for non-password authentications. My guess is that you have the nologin module in the authentication section of your PAM config. -d From petesea at bigfoot.com Tue Jan 23 14:22:03 2007 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Mon, 22 Jan 2007 19:22:03 -0800 (Pacific Standard Time) Subject: Move servers public/private keys to a new host Message-ID: Is it possible to move a server's public and private keys from one host to another? Or perhaps a better way to ask what I really want... is it possible to configure a server on a new host to return the same public key it did on the old host? I'm in the process of migrating our CVS server from a Solaris host to a Linux host (this weekend) and I just realized the hostkey is going to change. I tried copying the old host's pub/priv keys to the new host, but when I start sshd on the new host (using -ddd) I get: debug3: Not a RSA1 key file /usr/local/etc/ssh/old_ssh_host_rsa_key debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type Could not load host key: /usr/local/etc/ssh/old_ssh_host_rsa_key The biggest problem is with all our Windows users. Since they only use SSH (really plink) for CVS access, the CVS command fails if plink detects the hostkey has changed. This is really because the cvs command will fail if it gets ANY response it doesn't understand. Many (most) of our Windows users use various GUI CVS clients that often hide any output plink might display, but even if they DO happen to see any output, 99% wouldn't know what to do based on the error. I'm trying to avoid a barrage of tech support calls the day after the server changes. From rapier at psc.edu Wed Jan 24 01:01:03 2007 From: rapier at psc.edu (chris rapier) Date: Tue, 23 Jan 2007 09:01:03 -0500 Subject: Move servers public/private keys to a new host In-Reply-To: References: Message-ID: <45B6151F.6010705@psc.edu> petesea at bigfoot.com wrote: > Is it possible to move a server's public and private keys from one host to > another? Or perhaps a better way to ask what I really want... is it > possible to configure a server on a new host to return the same public key > it did on the old host? Yes, you can move them. All you need to do is copy the files over. Make sure they are in the right place and away you go. If the keys were actualy tied to the hardware this would be more difficult but they aren't. From Cynthia.K.Mullis at state.or.us Wed Jan 24 04:44:01 2007 From: Cynthia.K.Mullis at state.or.us (Cynthia K MULLIS) Date: Tue, 23 Jan 2007 09:44:01 -0800 Subject: support of locale Message-ID: When I ssh to a server, the locale information is set to "C" regardless of the settings in the /etc/default/init. For example: root at server: />locale LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= root at server: />cat /etc/default/init #ident "@(#)init.dfl 1.6 00/05/27 SMI" # # This file is /etc/default/init. /etc/TIMEZONE is a symlink to this file. # This file looks like a shell script, but it is not. To maintain # compatibility with old versions of /etc/TIMEZONE, some shell constructs # (i.e., export commands) are allowed in this file, but are ignored. # # Lines of this file should be of the form VAR=value, where VAR is one of # TZ, LANG, CMASK, or any of the LC_* environment variables. # TZ=US/Pacific CMASK=022 #LANG=C LANG=en_US LC_ALL=en_US If I telnet to the server then the information shows correctly: root at server2: />telnet server Trying ... Connected to server Escape character is '^]'. SunOS 5.9 login: user Password: Last login: Tue Jan 23 09:28:04 from server2 Setting erase to ^H user at server: />locale LANG=en_US LC_CTYPE="en_US" LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_ALL=en_US From dtucker at zip.com.au Wed Jan 24 09:46:13 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 24 Jan 2007 09:46:13 +1100 Subject: support of locale In-Reply-To: References: Message-ID: <45B69035.5030207@zip.com.au> Cynthia K MULLIS wrote: > When I ssh to a server, the locale information is set to "C" regardless > of the settings in the /etc/default/init. OpenSSH's sshd does not parse /etc/default/init, so unless your shell does then you won't see them. I don't know what normally parses it on Solaris, but if it's a PAM module then enabling PAM might help. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jmknoble at pobox.com Wed Jan 24 09:33:35 2007 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 23 Jan 2007 17:33:35 -0500 Subject: Move servers public/private keys to a new host In-Reply-To: References: Message-ID: <20070123223335.GN29660@crawfish.ais.com> Circa 2007-01-22 22:22 dixit petesea at bigfoot.com: : Is it possible to move a server's public and private keys from one host to : another? Or perhaps a better way to ask what I really want... is it : possible to configure a server on a new host to return the same public key : it did on the old host? : : I'm in the process of migrating our CVS server from a Solaris host to a : Linux host (this weekend) and I just realized the hostkey is going to : change. : : I tried copying the old host's pub/priv keys to the new host, but when I : start sshd on the new host (using -ddd) I get: : : debug3: Not a RSA1 key file /usr/local/etc/ssh/old_ssh_host_rsa_key : debug1: PEM_read_PrivateKey failed : debug1: read PEM private key done: type : Could not load host key: /usr/local/etc/ssh/old_ssh_host_rsa_key Apparently sshd on the Linux host is unable to read the key in .../old_ssh_host_rsa_key. What SSH server were you using on the Solaris host? Does old_ssh_host_rsa_key have the proper BEGIN and END lines around it? For example: # head -1 /etc/ssh/ssh_host_rsa_key -----BEGIN RSA PRIVATE KEY----- # tail -1 /etc/ssh/ssh_host_rsa_key -----END RSA PRIVATE KEY----- # Is openssl able to read the key? For example: # openssl rsa -text -noout -in /etc/ssh/ssh_host_rsa_key |head -1 Private-Key: (2048 bit) # How did you copy the key from the Solaris machine to the Linux machine? Is it possible the key got corrupted or truncated in transit? : : The biggest problem is with all our Windows users. Since they only use : SSH (really plink) for CVS access, the CVS command fails if plink detects : the hostkey has changed. This is really because the cvs command will fail : if it gets ANY response it doesn't understand. : : Many (most) of our Windows users use various GUI CVS clients that often : hide any output plink might display, but even if they DO happen to see any : output, 99% wouldn't know what to do based on the error. : : I'm trying to avoid a barrage of tech support calls the day after the : server changes. : _______________________________________________ : openssh-unix-dev mailing list : openssh-unix-dev at mindrot.org : http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev : -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From carson at taltos.org Wed Jan 24 11:37:23 2007 From: carson at taltos.org (Carson Gaspar) Date: Tue, 23 Jan 2007 16:37:23 -0800 Subject: support of locale In-Reply-To: <45B69035.5030207@zip.com.au> References: <45B69035.5030207@zip.com.au> Message-ID: <45B6AA43.90808@taltos.org> Darren Tucker wrote: > Cynthia K MULLIS wrote: >> When I ssh to a server, the locale information is set to "C" regardless >> of the settings in the /etc/default/init. > > OpenSSH's sshd does not parse /etc/default/init, so unless your shell > does then you won't see them. > > I don't know what normally parses it on Solaris, but if it's a PAM > module then enabling PAM might help. It's parsed by "init", oddly enough ;-) If you change /etc/default/init, you need to reboot (sadly, there is no way to get init to re-read the config file). Then init will have the new settings, and all children of init will inherit them. I haven't looked at the source to see if sshd will pass said environment along to its children or not. -- Carson From dtucker at zip.com.au Wed Jan 24 12:21:53 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 24 Jan 2007 12:21:53 +1100 Subject: support of locale In-Reply-To: <45B6AA43.90808@taltos.org> References: <45B69035.5030207@zip.com.au> <45B6AA43.90808@taltos.org> Message-ID: <20070124012153.GA8449@gate.dtucker.net> On Tue, Jan 23, 2007 at 04:37:23PM -0800, Carson Gaspar wrote: > Darren Tucker wrote: > > Cynthia K MULLIS wrote: > >> When I ssh to a server, the locale information is set to "C" regardless > >> of the settings in the /etc/default/init. > > > > OpenSSH's sshd does not parse /etc/default/init, so unless your shell > > does then you won't see them. > > > > I don't know what normally parses it on Solaris, but if it's a PAM > > module then enabling PAM might help. > > It's parsed by "init", oddly enough ;-) Ah, right. That would make sense :-) > If you change /etc/default/init, you need to reboot (sadly, there is no > way to get init to re-read the config file). Then init will have the new > settings, and all children of init will inherit them. OK, but unless you have sshd spawned out of inittab that still won't help much. > I haven't looked at the source to see if sshd will pass said environment > along to its children or not. It doesn't, but it's not hard to make it do so, eg: Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/session.c,v retrieving revision 1.349 diff -u -p -r1.349 session.c --- session.c 23 Oct 2006 17:01:56 -0000 1.349 +++ session.c 24 Jan 2007 01:18:13 -0000 @@ -1024,6 +1024,15 @@ do_setup_env(Session *s, const char *she free_windows_environment(p); } #endif + { + char *var, *val, *localevar[] = { "LANG", "LC_CTYPE", + "LC_NUMERIC", "LC_TIME", "LC_COLLATE", "LC_MONETARY", + "LC_MESSAGES", "LC_ALL", NULL }; + + for (i = 0; (var = localevar[i]) != NULL; i++) + if ((val = getenv(var)) != NULL) + child_set_env(&env, &envsize, var, val); + } #ifdef GSSAPI /* Allow any GSSAPI methods that we've used to alter -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From fcusack at fcusack.com Wed Jan 24 13:20:07 2007 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 23 Jan 2007 18:20:07 -0800 Subject: support of locale In-Reply-To: <20070124012153.GA8449@gate.dtucker.net> References: <45B69035.5030207@zip.com.au> <45B6AA43.90808@taltos.org> <20070124012153.GA8449@gate.dtucker.net> Message-ID: <110B21EF01F75F26A1B2AF5F@sucksless.local> On January 24, 2007 12:21:53 PM +1100 Darren Tucker wrote: > On Tue, Jan 23, 2007 at 04:37:23PM -0800, Carson Gaspar wrote: >> I haven't looked at the source to see if sshd will pass said environment >> along to its children or not. > > It doesn't, but it's not hard to make it do so, eg: If it's not already passing the LC_* vars on, the shell is picking it up somewhere else and will probably continue to do so even if sshd passes it on. -frank From petesea at bigfoot.com Wed Jan 24 14:47:45 2007 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Tue, 23 Jan 2007 19:47:45 -0800 (Pacific Standard Time) Subject: Move servers public/private keys to a new host In-Reply-To: References: Message-ID: OK.... never mind, I panicked too soon. My cut and paste of the private key missed a few bits on the cut and/or the paste. Once I got the private key correct everything started to work. On Mon, 22 Jan 2007, petesea at bigfoot.com wrote: > Is it possible to move a server's public and private keys from one host to > another? Or perhaps a better way to ask what I really want... is it possible > to configure a server on a new host to return the same public key it did on > the old host? > > I'm in the process of migrating our CVS server from a Solaris host to a Linux > host (this weekend) and I just realized the hostkey is going to change. > > I tried copying the old host's pub/priv keys to the new host, but when I > start sshd on the new host (using -ddd) I get: > > debug3: Not a RSA1 key file /usr/local/etc/ssh/old_ssh_host_rsa_key > debug1: PEM_read_PrivateKey failed > debug1: read PEM private key done: type > Could not load host key: /usr/local/etc/ssh/old_ssh_host_rsa_key > > The biggest problem is with all our Windows users. Since they only use SSH > (really plink) for CVS access, the CVS command fails if plink detects the > hostkey has changed. This is really because the cvs command will fail if it > gets ANY response it doesn't understand. > > Many (most) of our Windows users use various GUI CVS clients that often hide > any output plink might display, but even if they DO happen to see any output, > 99% wouldn't know what to do based on the error. > > I'm trying to avoid a barrage of tech support calls the day after the server > changes. > From carson at taltos.org Thu Jan 25 07:38:31 2007 From: carson at taltos.org (Carson Gaspar) Date: Wed, 24 Jan 2007 12:38:31 -0800 Subject: support of locale In-Reply-To: <20070124012153.GA8449@gate.dtucker.net> References: <45B69035.5030207@zip.com.au> <45B6AA43.90808@taltos.org> <20070124012153.GA8449@gate.dtucker.net> Message-ID: <45B7C3C7.8000601@taltos.org> Darren Tucker wrote: > On Tue, Jan 23, 2007 at 04:37:23PM -0800, Carson Gaspar wrote: > >> If you change /etc/default/init, you need to reboot (sadly, there is no >> way to get init to re-read the config file). Then init will have the new >> settings, and all children of init will inherit them. > > OK, but unless you have sshd spawned out of inittab that still won't help > much. Not quite, as init's environment is inherited by things spawned at boot time (or later via svcadm). If you're using classic init.d scripts, you can fix the env and re-spawn them, but if you're using svcadm you must change init's environment and reboot (or work some magic with svc* that is beyond my knowledge). -- Carson From andrew at gaul.org Thu Jan 25 18:04:32 2007 From: andrew at gaul.org (Andrew Gaul) Date: Thu, 25 Jan 2007 02:04:32 -0500 Subject: sshd unhandled SIGALRM Message-ID: <20070125070432.GA48155@paat.pair.com> sshd will die from an unhandled SIGALRM if you allow SSH1 connections, ssh in, HUP sshd, and don't ssh in again for KeyRegenerationInterval. The HUP handler calls exec which resets signal handlers but persists alarm timers. Chapter and verse: http://www.opengroup.org/onlinepubs/000095399/functions/alarm.html -- Andrew Gaul http://gaul.org/ -------------- next part -------------- Index: sshd.c =================================================================== RCS file: /cvs/openssh/sshd.c,v retrieving revision 1.345 diff -u -r1.345 sshd.c --- sshd.c 24 Jul 2006 04:51:01 -0000 1.345 +++ sshd.c 3 Aug 2006 06:13:53 -0000 @@ -291,6 +291,7 @@ logit("Received SIGHUP; restarting."); close_listen_socks(); close_startup_pipes(); + alarm(0); /* alarm timer persists across exec */ execv(saved_argv[0], saved_argv); logit("RESTART FAILED: av[0]='%.100s', error: %.100s.", saved_argv[0], strerror(errno)); From rapier at psc.edu Sat Jan 27 05:59:17 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 26 Jan 2007 13:59:17 -0500 Subject: Disk I/O with OpenSSH Message-ID: <45BA4F85.5030900@psc.edu> I was wondering if the disk I/O in OpenSSH is synchronous or asynchronous. If its not asynchronous is there any reason why doing at least asynch writes would be a bad idea? I'm just wondering if I'm over looking some obvious problem. Thanks for the clue Chris From djm at mindrot.org Sat Jan 27 09:46:01 2007 From: djm at mindrot.org (Damien Miller) Date: Sat, 27 Jan 2007 09:46:01 +1100 (EST) Subject: Disk I/O with OpenSSH In-Reply-To: <45BA4F85.5030900@psc.edu> References: <45BA4F85.5030900@psc.edu> Message-ID: On Fri, 26 Jan 2007, Chris Rapier wrote: > I was wondering if the disk I/O in OpenSSH is synchronous or > asynchronous. If its not asynchronous is there any reason why doing at > least asynch writes would be a bad idea? I'm just wondering if I'm over > looking some obvious problem. What disk IO? Do you mean sftp/scp? -d From bob at proulx.com Sun Jan 28 05:03:52 2007 From: bob at proulx.com (Bob Proulx) Date: Sat, 27 Jan 2007 11:03:52 -0700 Subject: support of locale In-Reply-To: <20070124012153.GA8449@gate.dtucker.net> References: <45B69035.5030207@zip.com.au> <45B6AA43.90808@taltos.org> <20070124012153.GA8449@gate.dtucker.net> Message-ID: <20070127180352.GA6512@dementia.proulx.com> Darren Tucker wrote: > Carson Gaspar wrote: > > I haven't looked at the source to see if sshd will pass said environment > > along to its children or not. > > It doesn't, but it's not hard to make it do so, eg: The trend these days seems to be to let PAM handle this for all login sessions. PAM is usually configured to load settings such as this from /etc/environment. Therefore I think /etc/environment is the right place for setting the default user locale. However PAM does not affect system daemons started at boot time. Therefore the normal init configuration for system daemons is still required. Bob From rapier at psc.edu Tue Jan 30 01:51:17 2007 From: rapier at psc.edu (chris rapier) Date: Mon, 29 Jan 2007 09:51:17 -0500 Subject: Disk I/O with OpenSSH In-Reply-To: References: <45BA4F85.5030900@psc.edu> Message-ID: <45BE09E5.5020904@psc.edu> Damien Miller wrote: > On Fri, 26 Jan 2007, Chris Rapier wrote: > > >>I was wondering if the disk I/O in OpenSSH is synchronous or >>asynchronous. If its not asynchronous is there any reason why doing at >>least asynch writes would be a bad idea? I'm just wondering if I'm over >>looking some obvious problem. > > > What disk IO? Do you mean sftp/scp? Yes. Mostly I'm wondering if a momentary hiccup on I/O could cause a stoppage along the entire IO chain and end up causing a delayed ACK which might push the connection back into slow start. Even with a reasonably fast disk on a fat enough connection seek time can exceed RTT and sometimes by several multiples. This just came up at a meeting at work and I had no worthwhile answer for them so I'm doing a little research. My feeling is that HW disk buffering will prevent it from being a factor in 99% of the time. However, I thought I would ask. From johnpell at mac.com Tue Jan 30 08:40:56 2007 From: johnpell at mac.com (John Davidorff Pell) Date: Mon, 29 Jan 2007 13:40:56 -0800 Subject: ControlPersist and multiple X11 forwarding. Message-ID: <841AFCF9-4872-407C-89B6-DA39C8B15B07@mac.com> Good afternoon! I've been looking for a way to avoid having to keep my "master" ssh session open while I have others open. This is particularly a pain when my "master" is an scp connection. After searching the archives, I came up with this thread "ControlPersist and multiple X11 forwardings." However, I can't find anything saying that it was incorporated or not, or what has happened. The last reply to this thread was in 2005. Unlike the originator of the thread, I don't have a patch to offer, only a request to make: I would find the ControlPersist option very useful, but I would find a slight alteration even more useful: an option to background the "master" process *so long as there are open channels*. I don't want an open ssh connection just hanging around, but I also don't like an extra, useless xterm left open doing nothing at all while another window has something going. Thanks! JP -- if (message.signature==FUNNY) steal(message.signature); else message=message->next; -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2520 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070129/c7fdfa1f/attachment.bin From dwmw2 at infradead.org Wed Jan 31 01:12:23 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 30 Jan 2007 14:12:23 +0000 Subject: SSH_ASKPASS behavior change proposal In-Reply-To: <20070118152458.4cepi1r1cggoc8ow@web.mail.umich.edu> References: <20070118152458.4cepi1r1cggoc8ow@web.mail.umich.edu> Message-ID: <1170166343.29759.86.camel@pmac.infradead.org> On Thu, 2007-01-18 at 15:24 -0500, Lance E Sloan wrote: > I propose that the ssh command-line client be changed so that it will > use whatever program is specified in the SSH_ASKPASS environment > variable regardless of whether ssh has a terminal associated with it or > not. In order for this to work, SSH_ASKPASS would need to contain the > full path to a program that prompts for a password, DISPLAY would also > need to be set, and some additional environment variable would need to > be set to instruct ssh to ignore the no-tty requirement. I'd like this. I currently have a horrid wrapper which deliberately disassociates from the ctty before executing /usr/bin/ssh, and it would be much nicer if SSH could be asked to use $SSH_ASKPASS unconditionally instead. -- dwmw2 From dwmw2 at infradead.org Wed Jan 31 01:09:32 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 30 Jan 2007 14:09:32 +0000 Subject: ControlPersist and multiple X11 forwarding. In-Reply-To: <841AFCF9-4872-407C-89B6-DA39C8B15B07@mac.com> References: <841AFCF9-4872-407C-89B6-DA39C8B15B07@mac.com> Message-ID: <1170166172.29759.83.camel@pmac.infradead.org> On Mon, 2007-01-29 at 13:40 -0800, John Davidorff Pell wrote: > After searching the archives, I came up with this thread > "ControlPersist and multiple X11 forwardings." However, I can't find > anything saying that it was incorporated or not, or what has > happened. The last reply to this thread was in 2005. Bits of it were incorporated but other parts are still outstanding. I build my own packages for Fedora Core with the remaining bits applied. http://david.woodhou.se/openssh-control.html has the patches, although the packages linked from there are old -- the current packages are at ftp://ftp.infradead.org/pub/dwmw2-fc6/ > Unlike the originator of the thread, I don't have a patch to offer, > only a request to make: > > I would find the ControlPersist option very useful, but I would find > a slight alteration even more useful: an option to background the > "master" process *so long as there are open channels*. I don't want > an open ssh connection just hanging around, but I also don't like an > extra, useless xterm left open doing nothing at all while another > window has something going. Would you settle for a timeout -- letting the master background itself but then disconnect after a period of inactivity which you can configure as low as you like, and which I can set to infinite? -- dwmw2 From lsloan at umich.edu Wed Jan 31 02:10:39 2007 From: lsloan at umich.edu (Lance E Sloan) Date: Tue, 30 Jan 2007 10:10:39 -0500 Subject: SSH_ASKPASS behavior change proposal In-Reply-To: <1170166343.29759.86.camel@pmac.infradead.org> References: <20070118152458.4cepi1r1cggoc8ow@web.mail.umich.edu> <1170166343.29759.86.camel@pmac.infradead.org> Message-ID: <20070130101039.yvejghps0woc8sw4@web.mail.umich.edu> Quoting David Woodhouse (Tue 30 Jan 2007 09:12:23 AM EST): > On Thu, 2007-01-18 at 15:24 -0500, Lance E Sloan wrote: >> I propose that the ssh command-line client be changed so that it will >> use whatever program is specified in the SSH_ASKPASS environment >> variable regardless of whether ssh has a terminal associated with it or >> not. In order for this to work, SSH_ASKPASS would need to contain the >> full path to a program that prompts for a password, DISPLAY would also >> need to be set, and some additional environment variable would need to >> be set to instruct ssh to ignore the no-tty requirement. > > I'd like this. I currently have a horrid wrapper which deliberately > disassociates from the ctty before executing /usr/bin/ssh, and it would > be much nicer if SSH could be asked to use $SSH_ASKPASS unconditionally > instead. I'm glad you like my suggestion. I suppose it's up to the OpenSSH development team to decide if they want to implement it. If anybody is interested, I can forward a patch to the OpenSSH source code that makes it possible. It's very short and simple, but one would have to compile ssh from source after applying the patch. As it turns out, Iain Morgan replied to my proposal with the suggestion that I try session multiplexing. I've tried that and I really like it a lot. When I set up the multiplexing master session, I enter my password and following that, all other sessions to the same host, port, and username do not require authentication. I've been able to run the multiplexing master session in the background, but that makes it difficult for me to see if the connection is still alive and working. (I might lose the connection if I take my laptop elsewhere.) So I've settled on running the master session in a terminal window of its own, in verbose mode. I wanted to find an application (or Mac OS X Dashboard widget) that would let me create and monitor these master sessions, but I haven't found any. Maybe I will eventually find time to make a Dashboard widget of my own. -- Lance E Sloan, Application Developer Evil is my middle name. Some people think it's Eugene, though. U-M ITCS ITCom Information Systems http://www.itcom.itcs.umich.edu/ From dwmw2 at infradead.org Wed Jan 31 02:16:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 30 Jan 2007 15:16:18 +0000 Subject: SSH_ASKPASS behavior change proposal In-Reply-To: <20070130101039.yvejghps0woc8sw4@web.mail.umich.edu> References: <20070118152458.4cepi1r1cggoc8ow@web.mail.umich.edu> <1170166343.29759.86.camel@pmac.infradead.org> <20070130101039.yvejghps0woc8sw4@web.mail.umich.edu> Message-ID: <1170170178.29759.109.camel@pmac.infradead.org> On Tue, 2007-01-30 at 10:10 -0500, Lance E Sloan wrote: > I'm glad you like my suggestion. I suppose it's up to the OpenSSH > development team to decide if they want to implement it. If anybody is > interested, I can forward a patch to the OpenSSH source code that makes > it possible. It's very short and simple, but one would have to compile > ssh from source after applying the patch. I think I had such a patch once too. It may be in the archives. Or maybe I didn't find a way to do it that I liked well enough to post, because I was doing it with a config option and readpass.c is used from contexts which don't have access to that (like ssh-add). -- dwmw2 From johnpell at mac.com Wed Jan 31 10:53:45 2007 From: johnpell at mac.com (John Davidorff Pell) Date: Tue, 30 Jan 2007 15:53:45 -0800 Subject: ControlPersist and multiple X11 forwarding. In-Reply-To: <1170166172.29759.83.camel@pmac.infradead.org> References: <841AFCF9-4872-407C-89B6-DA39C8B15B07@mac.com> <1170166172.29759.83.camel@pmac.infradead.org> Message-ID: <16400768-4271-4B85-B74A-38C2AA59A6E7@mac.com> Absolutely! That would be even better. That way, if I accidentally closed a remote shell, or if I were doing several scp's in a row, I could reuse the same connection several times without it hanging around unnecessarily. JP On Jan 30, 2007, at 6:09 AM, David Woodhouse wrote: > Would you settle for a timeout -- letting the master background itself > but then disconnect after a period of inactivity which you can > configure > as low as you like, and which I can set to infinite? -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2520 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070130/cbf8fa7e/attachment.bin From ryan at neomindstudio.com Wed Jan 31 05:24:30 2007 From: ryan at neomindstudio.com (Ryan Findley) Date: Tue, 30 Jan 2007 13:24:30 -0500 Subject: Verbose messaging about why public key auth was rejected Message-ID: <3109E259-4D89-4A8D-A218-A10A5D16CD92@neomindstudio.com> I had a small battle with public key authentication today at the end of which I realized that the problem was the permissions on my home directory (previously I though ~/.ssh was all that mattered. You learn something new every day!). While I was trying to track this problem down, I used ssh -v and sshd -ddd to get as much information as possible about why my public key wasn't working, and neither mentioned that it was a simple permissions issue. My question: is there a way to have ssh and/or sshd tell you WHY a public key is being rejected (specifically the permissions thing)? If so, can someone point me at a good document? I'm using OpenSSH 3.9p1 under RHEL4 (at the moment) and can upgrade if it's in a newer version. If not, would the OpenSSH team consider adding this feature? I'm betting I could probably manage the changes necessary, and submit a patch... Thanks, -ryan findley