From vinschen at redhat.com Mon Dec 1 02:09:33 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 30 Nov 2008 16:09:33 +0100 Subject: openssh on interix In-Reply-To: References: Message-ID: <20081130150933.GD12905@calimero.vinschen.de> On Nov 30 13:21, Martin Koeppe wrote: > On 2008-11-28, Corinna Vinschen wrote: > > On Nov 23 02:39, Martin Koeppe wrote: > >> The regpwd stored passwords are stored in the same (Windows > >> standard) way as e.g. Dial-in passwords or service account > >> passwords are stored, i.e. under: > >> > >> HKLM\Security\Policy\Secrets\ > >[...] > > I now implemented this for Cygwin. The next major version 1.7.0 will > > come with a `passwd -R' option which is what `regpwd' does on Interix. > > Will `passwd -R' and `regpwd' be comnpatible, i.e. store the password > unter the same reg value, so that I could use `passwd -R' on cygwin to > store the password and then use it from interix daemons or vice versa? > > regpwd uses this format: > HKLM\Security\Policy\Secrets\DOMAIN_USERNAME_microsoft_sfu_utility > where DOMAIN is the PC name (=local domain) or the NETBIOS domain > name. > The password itself is converted to Unicode (UCS-2LE) before being > stored. > > If cygwin used this format, too, users had to maintain only one entry. Cygwin uses a key "L$CYGWIN_usersid" in the first place. Maybe you can understand why I don't feel comfortable to write a registry key called "*_microsoft_sfu_utility"? Another reason is that the SFU key is accessible from remote. It's bad enough that every admin (instead of just LocalSystem) can access the key, but I'm using the L$ prefix so that this works at least only from the local machine. However, if a "L$CYGWIN" key doesn't exist, Cygwin looks if a "*_microsoft_sfu_utility" key exists and uses that to try to logon the user. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From michalp at ics.muni.cz Tue Dec 2 22:53:11 2008 From: michalp at ics.muni.cz (Michal Prochazka) Date: Tue, 02 Dec 2008 12:53:11 +0100 Subject: SSHD does not cleanup kerberos ticket while root logins Message-ID: <493521A7.4010901@ics.muni.cz> Hi all, It looks like a bug for me, but I'd like to ask if someone has the same problem. We are using OpenSSH 4.3p2 from Debian 4.0 (stable), but the same problem is with original OpenSSH 4.3p2. When root logins with his kerberos ticket and then logout, his ticket remains on the machine. I found in source (sshd.c) in privsep_postauth function, that if root logins then use_privsep is set to 0 and call of function do_setusercontext is skipped. But the function do_setusercontext calls ssh_gssapi_storecreds where structure client->store.filename is filled with the filename of kerberos ticket. So then if ssh_gssapi_cleanup_creds is called it does nothing because gssapi_client.store.filename is empty. We are using also pam_krb5, but with option minimal_uid=200, so the root login is not affected. My sshd_config: Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no RhostsRSAAuthentication PermitEmptyPasswords no ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes Regards, Michal P. -- Michal Prochazka // michalp at ics.muni.cz Supercomputing Center Brno Institute of Computer Science Masaryk University Botanicka 68a, 60200 Brno, CZ CESNET z.s.p.o. Zikova 4, 16200 Praha 6, CZ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2933 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081202/5c92c9bd/attachment-0001.bin From sfandino at yahoo.com Thu Dec 4 22:30:26 2008 From: sfandino at yahoo.com (Salvador Fandino) Date: Thu, 04 Dec 2008 12:30:26 +0100 Subject: [patch] muxserver_listen() doesn't restore umask when bind fails Message-ID: Cheers, - Salva $ diff -c mux.c~ mux.c *** mux.c~ 2008-06-14 01:01:54.000000000 +0200 --- mux.c 2008-12-04 12:24:45.000000000 +0100 *************** *** 148,153 **** --- 148,154 ---- error("ControlSocket %s already exists, " "disabling multiplexing", options.control_path); close(muxserver_sock); + umask(old_umask); muxserver_sock = -1; xfree(options.control_path); options.control_path = NULL; From kyrieuon at gmail.com Mon Dec 8 01:36:08 2008 From: kyrieuon at gmail.com (Richard Stoughton) Date: Sun, 7 Dec 2008 15:36:08 +0100 Subject: No subject Message-ID: From sim at netnation.com Wed Dec 10 11:07:17 2008 From: sim at netnation.com (Simon Kirby) Date: Tue, 9 Dec 2008 16:07:17 -0800 Subject: DSA harmful for remote authentication to compromised hosts? Message-ID: <20081210000717.GA28487@hostway.ca> Hello! I'd just like to run this by some people who are more familiar with the RSA and DSA algorithms and their use within (Open)SSH. I've been using OpenSSH happily with the assumption that using key-based authentication (RSA or DSA public keys pushed to .ssh/authorized_keys on remote hosts) provides a number of benefits, including an important security-related one -- Logging in to a known-root-compromised host is "safe" in that whatever is done on the remote machine would not compromise my private key in any way that would allow an attacker to further use data from an established session to compromise other hosts where the same pulic key is installed. However, a little while ago, as part of the whole Debian "oops we commented out the rand() part of the random function", their announcements at the time mentioned that use of DSA keys to hosts with broken random generators would also compromise the DSA key. If this is true, any compromised host could also have a compromised random generator, and this breaks my containment assumption. Does anybody know if this is true, and if so, is RSA also in a similar boat? If not, is it really safe to use DSA keys at all where a remote random generator cannot be trusted? Simon- From josh-lists at untruth.org Wed Dec 10 12:55:05 2008 From: josh-lists at untruth.org (Joshua Hill) Date: Tue, 9 Dec 2008 17:55:05 -0800 Subject: DSA harmful for remote authentication to compromised hosts? In-Reply-To: <20081210000717.GA28487@hostway.ca>; from sim@netnation.com on Tue, Dec 09, 2008 at 04:07:17PM -0800 References: <20081210000717.GA28487@hostway.ca> Message-ID: <20081209175505.A11693@chiba.halibut.com> On Tue, Dec 09, 2008 at 04:07:17PM -0800, Simon Kirby wrote: > [...] use of DSA keys to hosts with > broken random generators would also compromise the DSA key. > > If this is true, any compromised host could also have a compromised > random generator, and this breaks my containment assumption. > > Does anybody know if this is true, and if so, is RSA also in a similar > boat? If not, is it really safe to use DSA keys at all where a remote > random generator cannot be trusted? This is true for DSA because a DSA signature features a per-signature random 'k' variable which is used in the signing calculation and then discarded. This k value must be kept secret. If the attacker can guess this k value (and they know the message being signed and the domain parameters, which are all normally considered public) they can almost always calculate the client's private key with no extended calculation. Hence, if the attacker can break the client's RNG and witness a signature, they can break the private key. RSA does not suffer from this particular problem. There is no non-deterministic element to the basic RSA signature generation (though certain padding methods do feature non-deterministic elements) In either case the private key resides on the client, so a client vulnerability can result in the private key being compromised. An insecure RNG is just one sort of host vulnerability in this context. Josh From kyrieuon at gmail.com Wed Dec 10 10:26:56 2008 From: kyrieuon at gmail.com (Richard Stoughton) Date: Wed, 10 Dec 2008 00:26:56 +0100 Subject: Feature request: AlwaysDenyLogin, LoginDelayTime Message-ID: Please consider adding the following features to sshd: 1. AlwaysDenyLogin - a setting that will result in always denying login regardless of the credentials given by the client. 2. LoginDelayTime - to specify a delay in milliseconds before the server responds to a client's login attempt. These would help to employ brute force bots. Regards From openssh at roumenpetrov.info Thu Dec 11 07:16:04 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Wed, 10 Dec 2008 22:16:04 +0200 Subject: Feature request: AlwaysDenyLogin, LoginDelayTime In-Reply-To: References: Message-ID: <49402384.2030600@roumenpetrov.info> Richard Stoughton wrote: > Please consider adding the following features to sshd: > > 1. AlwaysDenyLogin - a setting that will result in always denying > login regardless of the credentials given by the client. > > 2. LoginDelayTime - to specify a delay in milliseconds before the > server responds to a client's login attempt. > > These would help to employ brute force bots. Usually we use firewalls to do this. Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From jmknoble at pobox.com Thu Dec 11 10:40:54 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 10 Dec 2008 18:40:54 -0500 Subject: Feature request: AlwaysDenyLogin, LoginDelayTime In-Reply-To: References: Message-ID: <20081210234054.GA18396@crawfish.ais.com> Circa 2008-12-09 18:26 dixit Richard Stoughton: : Please consider adding the following features to sshd: : : 1. AlwaysDenyLogin - a setting that will result in always denying : login regardless of the credentials given by the client. This capabality is already available, via several different methods: (a) Use the 'AllowGroups' keyword in your sshd_config file, together with a group containing no members. For example, on a system which has useradd/groupadd: su /usr/sbin/groupadd -g 2222 allowssh cd /etc/ssh cp -p sshd_config sshd_config.BACKUP echo 'AllowGroups allowssh' >>sshd_config (Of course, this method is even more useful if the 'allowssh' group actually contains members who should be allowed to log in via ssh...). (b) If your OpenSSH is configured with support for TCP wrappers, use /etc/hosts.allow and/or /etc/hosts.deny to configure what source IP addresses may use the ssh service. For example: su cd /etc test -f hosts.allow && cp -p hosts.allow hosts.allow.BACKUP cat >>hosts.allow <'EOF' sshd: 127.0.0.1: ALLOW sshd: ALL: DENY EOF The above will only allow use of the ssh service from the local host. (Of course, this method is even more useful if you specify remote hosts which are allowed to connect to the ssh service). A similar configuration can be achieved using firewall rules. (c) If there is an ssh service where no user should be allowed to log in, then consider turning off the service. If your goal isn't to deny all forms of login, but to restrict users to the use of specific commands (such as scp or sftp), then you need a different solution. Consider using a restricted shell such as rssh or scponly . Some notes about rssh are available . Alternatively, consider restricting authentication methods to PubkeyAuthentication and restricting available commands in users' .ssh/authorized_keys file. If your goal is something else (for example, only allowing portforwarding), you might try to be more specific. : 2. LoginDelayTime - to specify a delay in milliseconds before the : server responds to a client's login attempt. This should be done using firewall rules, either at a network gateway or on the host where the ssh server is running. : These would help to employ brute force bots. By 'employ', i am guessing you mean 'reduce risk from'. Good luck. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[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 kaizaad at sharcnet.ca Fri Dec 12 03:58:01 2008 From: kaizaad at sharcnet.ca (Kaizaad Bilimorya) Date: Thu, 11 Dec 2008 11:58:01 -0500 (EST) Subject: 5.0 vs 5.1 remote command execution Message-ID: Hello, I am experiencing some strange behaviour that I am hoping someone can shed some light on. OS and kernel: Red Hat Enterprise Linux AS release 4 (Nahant Update 5) Linux host135 2.6.9-67.9hp.7sp.XCsmp #1 SMP Thu Jul 3 18:55:59 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux built both openssh-5.0p1 and openssh-5.1p1 with the following options: ./configure --prefix=/usr --libexecdir=/usr/libexec/openssh --localstatedir=/var/empty/sshd \ --sysconfdir=/etc/ssh --with-pam --with-md5-passwords --with-zlib=/home/XXX/software/zlib-1.2.3 \ --with-tcp-wrappers With everything else being identical and just swapping the sshd binaries, I noticed the following: # ssh -v host135 debug1: match: OpenSSH_5.0 pat OpenSSH* ...snip # ssh host135 'echo $PATH' /opt/octave/current:/opt/mpiblast/current/bin:/opt/lammps/current/bin:/opt/dlpoly/current/execute: ...snip # ssh -v host135 debug1: match: OpenSSH_5.1 pat OpenSSH* ...snip # ssh host135 'echo $PATH' /usr/bin:/bin:/usr/sbin:/sbin According to the docs, the behaviour exhibited by v5.1 is correct, remote command execution should not process the user's login shell and env. But why was this happening in v5.0? I can't find anything in the 5.1 change log that explains this change in behaviour. thanks -k From adrya1984 at gmail.com Fri Dec 12 21:19:49 2008 From: adrya1984 at gmail.com (Adriana Rodean) Date: Fri, 12 Dec 2008 12:19:49 +0200 Subject: Can't connect client when runned from Windows Service Message-ID: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> Hi, I have a client on a Windows machine that connects through openssh on a linux server. I have this script (tunnel.cmd): @echo off :RUN echo Connecting? "C:/Program Files/OpenSSH/bin/ssh.exe" -R 40201:localhost:50300 -o TCPKeepAlive=no -o ServerAliveInterval=15 -o ServerAliveCountMax=2 -i id_rsa visma at 10.55.40.123 echo Restarting in 10 seconds? GOTO RUN It is runned from another application that starts as windows service. When i run the same script manually it makes the connection to linux machine. Is not working when we run it from the application that starts as windows service. Any help greatly appreciated. Thanks in advance, Adriana From kyrieuon at gmail.com Fri Dec 12 08:57:33 2008 From: kyrieuon at gmail.com (Richard Stoughton) Date: Thu, 11 Dec 2008 22:57:33 +0100 Subject: Feature request: AlwaysDenyLogin, LoginDelayTime In-Reply-To: <20081210234054.GA18396@crawfish.ais.com> References: <20081210234054.GA18396@crawfish.ais.com> Message-ID: Thank you for your reply. On Thu, Dec 11, 2008 at 12:40 AM, Jim Knoble wrote: > Circa 2008-12-09 18:26 dixit Richard Stoughton: > > : Please consider adding the following features to sshd: > : > : 1. AlwaysDenyLogin - a setting that will result in always denying > : login regardless of the credentials given by the client. > > This capabality is already available, via several different methods: > ... The basic idea behind the feature request is to let easily setup a kind of tarpit sshd in parallel to a 'normal' sshd: |--------------------------| | ------ | | | | | | | sshd |--- Port 22 ------ <-- dumb bots | | | login disabled | | ------ | | | | ------ | | | | | | | sshd |-- Port != 22 ---- <-- more intelligent clients | | | | | ------ | |--------------------------| (needs a monospace font) The sshd at port 22 would get the attention of dumb bots and slow them down, while the second instance would identify more intelligent clients such as legitimate users or not-so-dumb attackers. > (a) Use the 'AllowGroups' keyword in your sshd_config file, together > with a group containing no members. For example, on a system > which has useradd/groupadd: > > su > /usr/sbin/groupadd -g 2222 allowssh > cd /etc/ssh > cp -p sshd_config sshd_config.BACKUP > echo 'AllowGroups allowssh' >>sshd_config > > (Of course, this method is even more useful if the 'allowssh' > group actually contains members who should be allowed to log in > via ssh...). If denial of login via DenyUsers or AllowGroups cannot be distinguished from an ordinarily failed login these would suffice for my point 1. > (b) If your OpenSSH is configured with support for TCP wrappers, use > /etc/hosts.allow and/or /etc/hosts.deny to configure what source > IP addresses may use the ssh service.... > > (c) If there is an ssh service where no user should be allowed to > log in, then consider turning off the service. (b) and (c) would not work for my use case ;) > ... > : 2. LoginDelayTime - to specify a delay in milliseconds before the > : server responds to a client's login attempt. > > This should be done using firewall rules, either at a network gateway or > on the host where the ssh server is running. Hm, configuring a firewall requires a lot more expertise than simply setting a sshd configuration parameter. It makes things unneccessarily comlex. And im not sure if an attacker would not be able to identify a tarpit if the delay doesn't come from the sshd process. From mouring at eviladmin.org Sat Dec 13 03:02:33 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 12 Dec 2008 10:02:33 -0600 Subject: Feature request: AlwaysDenyLogin, LoginDelayTime In-Reply-To: References: <20081210234054.GA18396@crawfish.ais.com> Message-ID: <7D7FB39B-9015-47F1-A22A-AA01343A70C0@eviladmin.org> On Dec 11, 2008, at 3:57 PM, Richard Stoughton wrote: > Thank you for your reply. > > On Thu, Dec 11, 2008 at 12:40 AM, Jim Knoble > wrote: >> Circa 2008-12-09 18:26 dixit Richard Stoughton: >> >> : Please consider adding the following features to sshd: >> : >> : 1. AlwaysDenyLogin - a setting that will result in always denying >> : login regardless of the credentials given by the client. >> >> This capabality is already available, via several different methods: >> ... > > The basic idea behind the feature request is to let easily setup > a kind of tarpit sshd in parallel to a 'normal' sshd: > Why would you run OpenSSH in a tarpit mode? This seems like a broken idea. Tarpit software should be small and non-functional (e.g. OpenBSD's spamd). And OpenSSH is not. =) - Ben From kyrieuon at gmail.com Sat Dec 13 10:23:03 2008 From: kyrieuon at gmail.com (Richard Stoughton) Date: Sat, 13 Dec 2008 00:23:03 +0100 Subject: Feature request: AlwaysDenyLogin, LoginDelayTime In-Reply-To: <7D7FB39B-9015-47F1-A22A-AA01343A70C0@eviladmin.org> References: <20081210234054.GA18396@crawfish.ais.com> <7D7FB39B-9015-47F1-A22A-AA01343A70C0@eviladmin.org> Message-ID: On Fri, Dec 12, 2008 at 5:02 PM, Ben Lindstrom wrote: > > On Dec 11, 2008, at 3:57 PM, Richard Stoughton wrote: >> ... >> The basic idea behind the feature request is to let easily setup >> a kind of tarpit sshd in parallel to a 'normal' sshd: >> > > Why would you run OpenSSH in a tarpit mode? This seems like a broken idea. > Tarpit software should be small and non-functional (e.g. OpenBSD's spamd). > And OpenSSH is not. =) In general this is surely a good rule of thumb. But in the aforementioned scenario, where two ssh daemons would run in parallel, a dedicated tarpit ssh daemon would not add any additional security. And the absence of a running tarpit sshd of any kind would probably not reduce the overall system load. From mouring at eviladmin.org Sat Dec 13 11:32:29 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 12 Dec 2008 18:32:29 -0600 Subject: Feature request: AlwaysDenyLogin, LoginDelayTime In-Reply-To: References: <20081210234054.GA18396@crawfish.ais.com> <7D7FB39B-9015-47F1-A22A-AA01343A70C0@eviladmin.org> Message-ID: <0142D896-38BF-41BB-AA1C-5E806DBA79FB@eviladmin.org> On Dec 12, 2008, at 5:23 PM, Richard Stoughton wrote: > On Fri, Dec 12, 2008 at 5:02 PM, Ben Lindstrom > wrote: >> >> On Dec 11, 2008, at 3:57 PM, Richard Stoughton wrote: >>> ... >>> The basic idea behind the feature request is to let easily setup >>> a kind of tarpit sshd in parallel to a 'normal' sshd: >>> >> >> Why would you run OpenSSH in a tarpit mode? This seems like a >> broken idea. >> Tarpit software should be small and non-functional (e.g. OpenBSD's >> spamd). >> And OpenSSH is not. =) > > In general this is surely a good rule of thumb. But in the > aforementioned scenario, where two ssh daemons would run in parallel, > a dedicated tarpit ssh daemon would not add any additional security. > And the absence of a running tarpit sshd of any kind would probably > not reduce the overall system load. The use "tarpit" and "security" in the same sentence. Tarpitting doesn't improve security. Weak passwords are still weak. Badly coded apps are still badly written apps. It adds no more protection than running sshd on an alternate port. And in fact "AlwaysDenyLogin" in OpenSSH would cost higher loads because it should go through all the steps of authentication before denying. Otherwise there is timing attacks that could tell the attacker that they are being blocked. Plus remember that this will eats a "non-authentication" connection on your real server if they are a single deamon. - Ben From dan at nf15.lightwave.net.ru Sun Dec 14 04:10:42 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Sat, 13 Dec 2008 20:10:42 +0300 Subject: Can't connect client when runned from Windows Service In-Reply-To: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> Message-ID: <4943EC92.7010807@nf15.lightwave.net.ru> On 12.12.2008 13:19, Adriana Rodean wrote: > Hi, > > I have a client on a Windows machine that connects through openssh on a > linux server. > I have this script (tunnel.cmd): > > @echo off > :RUN echo Connecting? > "C:/Program Files/OpenSSH/bin/ssh.exe" -R 40201:localhost:50300 -o > TCPKeepAlive=no -o ServerAliveInterval=15 -o ServerAliveCountMax=2 -i id_rsa > visma at 10.55.40.123 > echo Restarting in 10 seconds? > GOTO RUN > > It is runned from another application that starts as windows service. > When i run the same script manually it makes the connection to linux > machine. Is not working when we run it from the application that starts as > windows service. > '-ddd' ssh command line parameter and output redirection will help you. -- Sincerely Your, Dan. From adrya1984 at gmail.com Sun Dec 14 07:27:08 2008 From: adrya1984 at gmail.com (Adriana Rodean) Date: Sat, 13 Dec 2008 22:27:08 +0200 Subject: Can't connect client when runned from Windows Service In-Reply-To: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> Message-ID: <496c8fcc0812131227x5f197d55n71670d70ef191a90@mail.gmail.com> Thanks for the advice Dan, will try it. Script makes the connection if is started manually from command line, or if program is started as executable. But when i start it as windows service i see it running in task manger (cmd.exe and ssh.exe) but it doesn't make the tunnel with the server. I've tried different user accounts to make it connect as service. Only one that could connect is if is runned under the user that is logged on, but that means user has to input username and password. Is it a way to make connection if is runned as Local service or Network Service or Local System? Thanks in advance, Adriana From adrya1984 at gmail.com Sun Dec 14 07:42:26 2008 From: adrya1984 at gmail.com (Adriana Rodean) Date: Sat, 13 Dec 2008 22:42:26 +0200 Subject: Can't connect client when runned from Windows Service In-Reply-To: <496c8fcc0812131219x774eb6e9nfe456c7840a34bbe@mail.gmail.com> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> <4943EC92.7010807@nf15.lightwave.net.ru> <496c8fcc0812131219x774eb6e9nfe456c7840a34bbe@mail.gmail.com> Message-ID: <496c8fcc0812131242q639451d7r73b5f38f680aa2e0@mail.gmail.com> Also, what does '-ddd' do? Looked on manual and only thing i could find is *-D* [*bind_address*:]*port* Specifies a local ``dynamic'' application-level port forwarding. Googled it also but didn't find anything about it Thanks again, Adriana From dan at nf15.lightwave.net.ru Sun Dec 14 09:31:58 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Sun, 14 Dec 2008 01:31:58 +0300 Subject: Can't connect client when runned from Windows Service In-Reply-To: <496c8fcc0812131242q639451d7r73b5f38f680aa2e0@mail.gmail.com> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> <4943EC92.7010807@nf15.lightwave.net.ru> <496c8fcc0812131219x774eb6e9nfe456c7840a34bbe@mail.gmail.com> <496c8fcc0812131242q639451d7r73b5f38f680aa2e0@mail.gmail.com> Message-ID: <494437DE.9000101@nf15.lightwave.net.ru> On 13.12.2008 23:42, Adriana Rodean wrote: > Also, what does '-ddd' do? Looked on manual and only thing i could find is > > *-D* [/bind_address/:]/port/ > Specifies a local ``dynamic'' application-level port forwarding. > '-ddd' is a derivative of '-d' meaning the most verbose debug level. -- Sincerely Your, Dan. From peter at stuge.se Mon Dec 15 12:05:05 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 15 Dec 2008 02:05:05 +0100 Subject: Can't connect client when runned from Windows Service In-Reply-To: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> Message-ID: <20081215010505.6900.qmail@stuge.se> Adriana Rodean wrote: > "C:/Program Files/OpenSSH/bin/ssh.exe" -R 40201:localhost:50300 -o > TCPKeepAlive=no -o ServerAliveInterval=15 -o ServerAliveCountMax=2 -i id_rsa > visma at 10.55.40.123 .. > When i run the same script manually it makes the connection to > linux machine. Is not working when we run it from the application > that starts as windows service. First of all, always supply the full path for the id_rsa file so that the file is found regardless of the current working directory. Second, run ssh with -N and -T. Check out the ssh(1) man page to learn more about their meaning. -T is important for all automated runs. //Peter From adrya1984 at gmail.com Tue Dec 16 03:22:30 2008 From: adrya1984 at gmail.com (Adriana Rodean) Date: Mon, 15 Dec 2008 18:22:30 +0200 Subject: Can't connect client when runned from Windows Service In-Reply-To: <20081215010505.6900.qmail@stuge.se> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> <20081215010505.6900.qmail@stuge.se> Message-ID: <496c8fcc0812150822w7fbf41a2w1a66da39afbc6a7b@mail.gmail.com> Hi, thanks for replying. I tried: "C:/Program Files/OpenSSH/bin/ssh.exe" -R 40201:localhost:50300 -o TCPKeepAlive=no -o ServerAliveInterval=15 -o ServerAliveCountMax=2 -T -N -i "C:/id_rsa" visma at 10.55.40.123 still doesn't connect when started as service. With previous command it connected from windows service only if the service was started as logged in user, but like this user had to input username and password, that's why we need to start it as Network Service or Local System or Local Service, that don't require password. I am thinking that it allows to connect with user account because the known_hosts file was previous created. As soon as i deleted that file ssh asked if i am sure to connect to the linux machine because is not known. If i answered yes known_hosts file was created in c:\documents and settings\[user]\.ssh folder. If i copyed the .ssh folder in c:\documents and settings\NetworkService folder still didn't work. Is it a way to make ssh not ask that first question (we can't input yes from service)? or make it recognize the known_hosts file? And is it a way to output the verbose to a file? Tried '-ddd' it said invalid command. Thanks, Adriana From jmknoble at pobox.com Tue Dec 16 08:18:13 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 15 Dec 2008 16:18:13 -0500 Subject: Can't connect client when runned from Windows Service In-Reply-To: <496c8fcc0812150822w7fbf41a2w1a66da39afbc6a7b@mail.gmail.com> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> <20081215010505.6900.qmail@stuge.se> <496c8fcc0812150822w7fbf41a2w1a66da39afbc6a7b@mail.gmail.com> Message-ID: <20081215211813.GB14850@crawfish.ais.com> Circa 2008-12-15 11:22 dixit Adriana Rodean: : Hi, thanks for replying. : I tried: : : "C:/Program Files/OpenSSH/bin/ssh.exe" -R 40201:localhost:50300 -o : TCPKeepAlive=no -o ServerAliveInterval=15 -o ServerAliveCountMax=2 -T : -N -i "C:/id_rsa" visma at 10.55.40.123 : : still doesn't connect when started as service. : [...] : I am thinking that it allows to connect with user account because the : known_hosts file was previous created. As soon as i deleted that file : ssh asked if i am sure to connect to the linux machine because is not : known. If i answered yes known_hosts file was created in c:\documents : and settings\[user]\.ssh folder. [...] : Is it a way to make ssh not ask that first question (we can't input : yes from service)? or make it recognize the known_hosts file? Look for 'StrictHostKeyChecking' in the 'ssh_config' man page. : And is it a way to output the verbose to a file? Tried '-ddd' it said : invalid command. The '-d' switch is for sshd (the server). Use '-v' (lowercase vee) for ssh (the client). You probably need to create either a (Cygwin or MinGW) bash.exe script or a CMD/BAT script in order to redirect the output to a file. Good luck. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[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 adrya1984 at gmail.com Tue Dec 16 19:08:13 2008 From: adrya1984 at gmail.com (Adriana Rodean) Date: Tue, 16 Dec 2008 10:08:13 +0200 Subject: Can't connect client when runned from Windows Service In-Reply-To: <20081215211813.GB14850@crawfish.ais.com> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> <20081215010505.6900.qmail@stuge.se> <496c8fcc0812150822w7fbf41a2w1a66da39afbc6a7b@mail.gmail.com> <20081215211813.GB14850@crawfish.ais.com> Message-ID: <496c8fcc0812160008o562130f7n95bcfd7e4cb8455b@mail.gmail.com> Hi all, Thank you all for the help :) Finally good news, made it to work as Network Service and connects successfully :) This is the correct script: @echo off :RUN echo Connecting? "C:/Program Files/OpenSSH/bin/ssh.exe" -R 20210:localhost:50300 -o BatchMode=yes -o StrictHostKeyChecking=no -o VerifyHostKeyDNS=no -o TCPKeepAlive=no -o ServerAliveInterval=15 -o ServerAliveCountMax=2 -i "C:/Program Files/Visma/OPGatewayService/id_rsa" visma at 10.55.40.123 echo Restarting in 10 seconds? GOTO RUN Best regards and thanks again, Adriana On Mon, Dec 15, 2008 at 23:18, Jim Knoble wrote: > Circa 2008-12-15 11:22 dixit Adriana Rodean: > > : Hi, thanks for replying. > : I tried: > : > : "C:/Program Files/OpenSSH/bin/ssh.exe" -R 40201:localhost:50300 -o > : TCPKeepAlive=no -o ServerAliveInterval=15 -o ServerAliveCountMax=2 -T > : -N -i "C:/id_rsa" visma at 10.55.40.123 > : > : still doesn't connect when started as service. > : > [...] > : I am thinking that it allows to connect with user account because the > : known_hosts file was previous created. As soon as i deleted that file > : ssh asked if i am sure to connect to the linux machine because is not > : known. If i answered yes known_hosts file was created in c:\documents > : and settings\[user]\.ssh folder. > [...] > : Is it a way to make ssh not ask that first question (we can't input > : yes from service)? or make it recognize the known_hosts file? > > Look for 'StrictHostKeyChecking' in the 'ssh_config' man page. > > : And is it a way to output the verbose to a file? Tried '-ddd' it said > : invalid command. > > The '-d' switch is for sshd (the server). Use '-v' (lowercase vee) for > ssh (the client). > > You probably need to create either a (Cygwin or MinGW) bash.exe script > or a CMD/BAT script in order to redirect the output to a file. > > Good luck. > > -- > jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ > (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) > (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) > +----------------------------------------------------------------------+ > |[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 adrya1984 at gmail.com Tue Dec 16 20:32:13 2008 From: adrya1984 at gmail.com (Adriana Rodean) Date: Tue, 16 Dec 2008 11:32:13 +0200 Subject: Patch for OpenSSH for Windows to allow authentication through certificates Message-ID: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> Hi all, Does anyone know if it exists a patch for OpenSSH for Windows to allow authentication through certificates? Is it possible to make one if it doesn't exists? Using OpenSSH for Windows 3.8p1-1 20040709 Build. I know there is Roumen Petrov patch, but is for unix machines if i'm not mistaken. I need a similar one for Windows that work with the Roumen Petrov patch so i can have authentication through certificates between Windows machine and Linux machine. Any help greatly appreciated, Adriana From rosmi.jose at wipro.com Thu Dec 18 00:18:45 2008 From: rosmi.jose at wipro.com (rosmi.jose at wipro.com) Date: Wed, 17 Dec 2008 18:48:45 +0530 Subject: OpenSSH_4.6p1 - Not taking authmethod_Lookup parameter- keyboard-interactive Message-ID: Hi, I have the below version of openssh and openssl on solaris 10 machine (say wcars9bd). OpenSSH_4.6p1, OpenSSL 0.9.8e I have the below version of openssh and openssl on solaris 9 machine (say wcars99q). OpenSSH_4.3p2, OpenSSL 0.9.8a My concern is there if i initiate a connection to wcars9bd (OpenSSH_4.6p1, OpenSSL 0.9.8e, Solaris10), I could see that its not taking the authmethod_Lookup parameter as keyboard-interactive at all. I see debug3: remaining preferred: ,password. But if i see the connection logs to wcars99q (OpenSSH_4.3p2, OpenSSL 0.9.8a, Solaris9), I could see that first it tries in Pubickey, then keyboad-interactive mode. I have read somewhere that for GUI based applications it needs keyboard interactive mode. I would like to know whether this is a bug in OpenSSH_4.6p1. Do we have any patch for this? Could you please help me in this? If i initiate a connection from other server to this server (wcars9bd), ssh -v -v -v -l root wcars9bd, at the end i could see the debug logs from ssh as debug3: preferred hostbased,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: Trying private key: /home/rosmi/.ssh/id_rsa debug3: no such identity: /home/rosmi/.ssh/id_rsa debug1: Trying private key: /home/rosmi/.ssh/id_dsa debug3: no such identity: /home/rosmi/.ssh/id_dsa debug1: Trying private key: /home/rosmi/.ssh/identity debug3: no such identity: /home/rosmi/.ssh/identity debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password root at wcars9bd's password: If i initiate a connection from other server to this server (wcars99q), ssh -v -v -v -l root wcars9bd, at the end i could see the debug logs from ssh as 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: Trying private key: /home/rosmi/.ssh/identity debug3: no such identity: /home/rosmi/.ssh/identity debug1: Trying private key: /home/rosmi/.ssh/id_rsa debug3: no such identity: /home/rosmi/.ssh/id_rsa debug1: Trying private key: /home/rosmi/.ssh/id_dsa debug3: no such identity: /home/rosmi/.ssh/id_dsa 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 debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: Regards, Rosmi C. Jose _______________________ Nortel SSPFS Design Wipro Technologies Bangalore ESN : 6-877-8712 _______________________ Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From kaizaad at sharcnet.ca Thu Dec 18 03:02:38 2008 From: kaizaad at sharcnet.ca (Kaizaad Bilimorya) Date: Wed, 17 Dec 2008 11:02:38 -0500 (EST) Subject: 5.0 vs 5.1 remote command execution In-Reply-To: References: Message-ID: Any developers (or others) have some insight into this behaviour? thanks -k On Thu, 11 Dec 2008, Kaizaad Bilimorya wrote: > Hello, > > I am experiencing some strange behaviour that I am hoping someone can > shed some light on. > > OS and kernel: > Red Hat Enterprise Linux AS release 4 (Nahant Update 5) > Linux host135 2.6.9-67.9hp.7sp.XCsmp #1 SMP Thu Jul 3 18:55:59 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux > > > built both openssh-5.0p1 and openssh-5.1p1 with the following options: > ./configure --prefix=/usr --libexecdir=/usr/libexec/openssh --localstatedir=/var/empty/sshd \ > --sysconfdir=/etc/ssh --with-pam --with-md5-passwords --with-zlib=/home/XXX/software/zlib-1.2.3 \ > --with-tcp-wrappers > > > With everything else being identical and just swapping the sshd binaries, > I noticed the following: > > # ssh -v host135 > debug1: match: OpenSSH_5.0 pat OpenSSH* > ...snip > # ssh host135 'echo $PATH' > /opt/octave/current:/opt/mpiblast/current/bin:/opt/lammps/current/bin:/opt/dlpoly/current/execute: > ...snip > > # ssh -v host135 > debug1: match: OpenSSH_5.1 pat OpenSSH* > ...snip > # ssh host135 'echo $PATH' > /usr/bin:/bin:/usr/sbin:/sbin > > > According to the docs, the behaviour exhibited by v5.1 is correct, remote > command execution should not process the user's login shell and env. But > why was this happening in v5.0? I can't find anything in the 5.1 change > log that explains this change in behaviour. > > thanks > -k > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From ems at mdacc.tmc.edu Wed Dec 17 06:48:36 2008 From: ems at mdacc.tmc.edu (Eric Sisson) Date: Tue, 16 Dec 2008 13:48:36 -0600 Subject: Request change to file match.c, function match_pattern_list Message-ID: <68A6F62B-C005-488A-B71A-20B9DA53E809@mdacc.tmc.edu> Greetings, This request is in the grey area between a bug report and an enhancement request. Request ------- Please apply the following diff (or something functionally similar) to file ``match.c'' in OpenSSH-5.1p1: 161a162,164 > } else { > if (negated) > got_positive = 1; /* Negative match, negated = Positive */ In case the lines above wrapped in the email transmission, the diff is attached as a .gz file. -------------- next part -------------- A non-text attachment was scrubbed... Name: match.c.diff.gz Type: application/x-gzip Size: 104 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081216/fe35d5b5/attachment.bin -------------- next part -------------- Justification ------------- On a system running Red Hat Enterprise Linux 4, I wanted to use a configuration of the following form in sshd_config: DenyUsers oracle@!localhost.localdomain that would prevent user ``oracle'' from logging into the host from any host except the host itself (localhost). Rephrased, I want to allow logins to user ``oracle'' only by users who already are logged into the same host that has user ``oracle''. The above construct fails in OpenSSH, and I traced the failure to the absence of code handling this case in an ``if'' statement (that checks the result of function ``match_pattern'') near the end of the main ``for'' loop in function ``match_pattern_list'' in file ``match.c''. The diff above is an example of code to handle this case. The meaning of this new code is the following: - If a string fails to match the subpattern of the configuration, then execution will flow into ``else'' branch. - Normally, the failure of a match is a failure (``got_positive'' retains its initialized value of zero). - However, where a failure is desired (the ``!'' in the specification subpattern), then the occurrence of a failure is a ``success'', so ``got_positive'' should be set to one. Initially, I was working with OpenSSH-3.9p1, but I see that the code remains consistent through OpenSSH-5.1p1, so I am reporting this change request relative to the newer version. Respectfully, Eric Sisson -- Eric M. Sisson, Systems Analyst III email: ems at mdacc.tmc.edu Clinical Research Information Systems - Box 237 voice: 713-792-2629 University of Texas M. D. Anderson Cancer Center fax: 713-745-0615 1515 Holcombe Boulevard Houston, Texas 77030-4009 From jmknoble at pobox.com Thu Dec 18 09:36:48 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 17 Dec 2008 17:36:48 -0500 Subject: Can't connect client when runned from Windows Service In-Reply-To: <496c8fcc0812160008o562130f7n95bcfd7e4cb8455b@mail.gmail.com> References: <496c8fcc0812120219o45c79eaax894591b4dee2b1a1@mail.gmail.com> <20081215010505.6900.qmail@stuge.se> <496c8fcc0812150822w7fbf41a2w1a66da39afbc6a7b@mail.gmail.com> <20081215211813.GB14850@crawfish.ais.com> <496c8fcc0812160008o562130f7n95bcfd7e4cb8455b@mail.gmail.com> Message-ID: <20081217223648.GB10088@crawfish.ais.com> Circa 2008-12-16 03:08 dixit Adriana Rodean: : Finally good news, made it to work as Network Service and connects : successfully :) : : This is the correct script: : : @echo off : :RUN echo Connecting... : "C:/Program Files/OpenSSH/bin/ssh.exe" [etc....] : echo Restarting in 10 seconds... : GOTO RUN This looks like you want a persistent SSH tunnel. You might look into AutoSSH, which is designed for exactly that: http://www.harding.motd.ca/autossh/ Notable among its features: - Backs off on rate of connection attempts when experiencing rapid failures such as connection refused It's available as a precompiled package in Cygwin . -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[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 jmknoble at pobox.com Thu Dec 18 09:41:27 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 17 Dec 2008 17:41:27 -0500 Subject: Request change to file match.c, function match_pattern_list In-Reply-To: <68A6F62B-C005-488A-B71A-20B9DA53E809@mdacc.tmc.edu> References: <68A6F62B-C005-488A-B71A-20B9DA53E809@mdacc.tmc.edu> Message-ID: <20081217224127.GC10088@crawfish.ais.com> Circa 2008-12-16 14:48 dixit Eric Sisson: : This request is in the grey area between a bug report and an : enhancement request. Probably best to file this in the OpenSSH Bugzilla: http://www.openssh.com/report.html (and follow the "Bugzilla" link). This may avoid your report getting lost amid mailing list noise. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[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 imorgan at nas.nasa.gov Thu Dec 18 10:34:57 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 17 Dec 2008 15:34:57 -0800 Subject: Request change to file match.c, function match_pattern_list In-Reply-To: <68A6F62B-C005-488A-B71A-20B9DA53E809@mdacc.tmc.edu> References: <68A6F62B-C005-488A-B71A-20B9DA53E809@mdacc.tmc.edu> Message-ID: <20081217233457.GA26708@linux55.nas.nasa.gov> On Tue, Dec 16, 2008 at 13:48:36 -0600, Eric Sisson wrote: > > On a system running Red Hat Enterprise Linux 4, I wanted to use a > configuration of the following form in sshd_config: > > DenyUsers oracle@!localhost.localdomain > You might want to try this instead: DenyUsers oracle@*,!localhost.localdomain -- Iain Morgan From fede_home at yahoo.it Fri Dec 19 13:12:38 2008 From: fede_home at yahoo.it (Fede Rico) Date: Fri, 19 Dec 2008 02:12:38 +0000 (GMT) Subject: only root without password Message-ID: <778656.78601.qm@web26008.mail.ukl.yahoo.com> Hi all, I have a very strange problem with the public key authentication with 2 machines. I generated the key, configured the authorized_keys etc.. etc.. This is all ok, now: The ssh works without the password for the "root" user, any other user cannot use the key and ssh ask me for the password !! I cannot understand why only the root is able to connect without the password. So, the ssh works and I think there is a wrong config file but I cannt find it !!!! Just to understand the issue, let's see the strace of sshd daemon. As you can see when the root connect the sshd reads the key file, but when another user try to connect, sshd open the file and the close it without read the key...... Any ideas?? Federico *********** for the root: 26728 read(4, "root:x:0:rootnbin:x:1:root,bin,d"..., 4096) = 946 26728 read(4, "", 4096) = 0 26728 close(4) = 0 26728 munmap(0xb7dce000, 4096) = 0 26728 setgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 0 26728 getgroups32(0, NULL) = 7 26728 getgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 7 26728 setgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 0 26728 setresgid32(-1, 0, -1) = 0 26728 setresuid32(-1, 0, -1) = 0 26728 stat64("/root/.ssh/authorized_keys", {st_mode=S_IFREG|0600, st_size=1664, ...}) = 0 26728 open("/root/.ssh/authorized_keys", O_RDONLY|O_LARGEFILE) = 4 26728 lstat64("/root", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 26728 lstat64("/root/.ssh", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 26728 lstat64("/root/.ssh/authorized_keys", {st_mode=S_IFREG|0600, st_size=1664, ...}) = 0 26728 lstat64("/root", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 26728 fstat64(4, {st_mode=S_IFREG|0600, st_size=1664, ...}) = 0 26728 stat64("/root/.ssh", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 26728 stat64("/root", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 26728 fstat64(4, {st_mode=S_IFREG|0600, st_size=1664, ...}) = 0 26728 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dce000 26728 read(4, "ssh-dss AAAAB3NzaC1kc3MAAACBALxI"..., 4096) = 1664 26728 setresuid32(-1, 0, -1) = 0 *************** and for another user: 23996 read(4, "root:x:0:rootnbin:x:1:root,bin,d"..., 4096) = 946 23996 read(4, "", 4096) = 0 23996 close(4) = 0 23996 munmap(0xb7e7c000, 4096) = 0 23996 setgroups32(2, [501, 502]) = 0 23996 getgroups32(0, NULL) = 2 23996 getgroups32(2, [501, 502]) = 2 23996 setgroups32(2, [501, 502]) = 0 23996 setresgid32(-1, 501, -1) = 0 23996 setresuid32(-1, 501, -1) = 0 23996 stat64("/u1/oracle/.ssh/authorized_keys", {st_mode=S_IFREG|0644, st_size=836, ...}) = 0 23996 open("/u1/oracle/.ssh/authorized_keys", O_RDONLY|O_LARGEFILE) = 4 23996 lstat64("/u1", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 23996 lstat64("/u1/oracle", {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 23996 lstat64("/u1/oracle/.ssh", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 23996 lstat64("/u1/oracle/.ssh/authorized_keys", {st_mode=S_IFREG|0644, st_size=836, ...}) = 0 23996 lstat64("/u1", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 23996 lstat64("/u1/oracle", {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 23996 fstat64(4, {st_mode=S_IFREG|0644, st_size=836, ...}) = 0 23996 stat64("/u1/oracle/.ssh", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 23996 stat64("/u1/oracle", {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 23996 close(4) = 0 23996 time(NULL) = 1229609500 23996 open("/etc/localtime", O_RDONLY) = 4 From mloftis at wgops.com Fri Dec 19 20:16:55 2008 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 19 Dec 2008 02:16:55 -0700 Subject: only root without password In-Reply-To: <778656.78601.qm@web26008.mail.ukl.yahoo.com> References: <778656.78601.qm@web26008.mail.ukl.yahoo.com> Message-ID: <5558FE1FBD1865B195C3BA28@ZOP-MACTEL.local> make sure the directory and file are owned by the user. the directory especially has to be the right mode. 0700 on ~/.ssh owned by the user. key files i think it wants them to not be writeable by others. The SSH daemon must also be able to access the keyfiles - usually root can but in some weird setups (EG with ACLs) it might be inaccessible to root. --On December 19, 2008 2:12:38 AM +0000 Fede Rico wrote: > Hi all, > I have a very strange problem with the public key authentication with 2 > machines. > I generated the key, configured the authorized_keys etc.. etc.. This is > all ok, now: > The ssh works without the password for the "root" user, any other user > cannot use the key and ssh ask me for the password !! > I cannot understand why only the root is able to connect without the > password. So, the ssh works and I think there is a wrong config file but I > cannt find it !!!! > Just to understand the issue, let's see the strace of sshd daemon. As you > can see when the root connect the sshd reads the key file, but when > another user try to connect, sshd open the file and the close it without > read the key...... > Any ideas?? > > Federico > > *********** > for the root: > 26728 read(4, "root:x:0:rootnbin:x:1:root,bin,d"..., 4096) = 946 > 26728 read(4, "", 4096) = 0 > 26728 close(4) = 0 > 26728 munmap(0xb7dce000, 4096) = 0 > 26728 setgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 0 > 26728 getgroups32(0, NULL) = 7 > 26728 getgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 7 > 26728 setgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 0 > 26728 setresgid32(-1, 0, -1) = 0 > 26728 setresuid32(-1, 0, -1) = 0 > 26728 stat64("/root/.ssh/authorized_keys", {st_mode=S_IFREG|0600, > st_size=1664, ...}) = 0 > 26728 open("/root/.ssh/authorized_keys", O_RDONLY|O_LARGEFILE) = 4 > 26728 lstat64("/root", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 > 26728 lstat64("/root/.ssh", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 > 26728 lstat64("/root/.ssh/authorized_keys", {st_mode=S_IFREG|0600, > st_size=1664, ...}) = 0 > 26728 lstat64("/root", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 > 26728 fstat64(4, {st_mode=S_IFREG|0600, st_size=1664, ...}) = 0 > 26728 stat64("/root/.ssh", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 > 26728 stat64("/root", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 > 26728 fstat64(4, {st_mode=S_IFREG|0600, st_size=1664, ...}) = 0 > 26728 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0xb7dce000 > 26728 read(4, "ssh-dss AAAAB3NzaC1kc3MAAACBALxI"..., 4096) = 1664 > 26728 setresuid32(-1, 0, -1) = 0 > > *************** > and for another user: > 23996 read(4, "root:x:0:rootnbin:x:1:root,bin,d"..., 4096) = 946 > 23996 read(4, "", 4096) = 0 > 23996 close(4) = 0 > 23996 munmap(0xb7e7c000, 4096) = 0 > 23996 setgroups32(2, [501, 502]) = 0 > 23996 getgroups32(0, NULL) = 2 > 23996 getgroups32(2, [501, 502]) = 2 > 23996 setgroups32(2, [501, 502]) = 0 > 23996 setresgid32(-1, 501, -1) = 0 > 23996 setresuid32(-1, 501, -1) = 0 > 23996 stat64("/u1/oracle/.ssh/authorized_keys", {st_mode=S_IFREG|0644, > st_size=836, ...}) = 0 > 23996 open("/u1/oracle/.ssh/authorized_keys", O_RDONLY|O_LARGEFILE) = 4 > 23996 lstat64("/u1", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 > 23996 lstat64("/u1/oracle", {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > 23996 lstat64("/u1/oracle/.ssh", {st_mode=S_IFDIR|0700, st_size=4096, > ...}) = 0 > 23996 lstat64("/u1/oracle/.ssh/authorized_keys", {st_mode=S_IFREG|0644, > st_size=836, ...}) = 0 > 23996 lstat64("/u1", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 > 23996 lstat64("/u1/oracle", {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > 23996 fstat64(4, {st_mode=S_IFREG|0644, st_size=836, ...}) = 0 > 23996 stat64("/u1/oracle/.ssh", {st_mode=S_IFDIR|0700, st_size=4096, ...}) > = 0 > 23996 stat64("/u1/oracle", {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > 23996 close(4) = 0 > 23996 time(NULL) = 1229609500 > 23996 open("/etc/localtime", O_RDONLY) = 4 > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From fede_home at yahoo.it Fri Dec 19 20:44:15 2008 From: fede_home at yahoo.it (Fede Rico) Date: Fri, 19 Dec 2008 09:44:15 +0000 (GMT) Subject: only root without password In-Reply-To: <5558FE1FBD1865B195C3BA28@ZOP-MACTEL.local> Message-ID: <474055.27002.qm@web26006.mail.ukl.yahoo.com> Hi Michael, yes, the permissions and the owners are ok. I checked it. In the strace file, when I use the "oracle" user, I didn't fine any "permission denied". So I think the problem should be in some other side (pam, security, and so on). --- Ven 19/12/08, Michael Loftis ha scritto: > Da: Michael Loftis > Oggetto: Re: only root without password > A: fede_home at yahoo.it, openssh-unix-dev at mindrot.org > Data: Venerd? 19 dicembre 2008, 10:16 > make sure the directory and file are owned by the user. the > directory > especially has to be the right mode. 0700 on ~/.ssh owned > by the user. > key files i think it wants them to not be writeable by > others. The SSH > daemon must also be able to access the keyfiles - usually > root can but in > some weird setups (EG with ACLs) it might be inaccessible > to root. > > --On December 19, 2008 2:12:38 AM +0000 Fede Rico > > wrote: > > > Hi all, > > I have a very strange problem with the public key > authentication with 2 > > machines. > > I generated the key, configured the authorized_keys > etc.. etc.. This is > > all ok, now: > > The ssh works without the password for the > "root" user, any other user > > cannot use the key and ssh ask me for the password !! > > I cannot understand why only the root is able to > connect without the > > password. So, the ssh works and I think there is a > wrong config file but I > > cannt find it !!!! > > Just to understand the issue, let's see the strace > of sshd daemon. As you > > can see when the root connect the sshd reads the key > file, but when > > another user try to connect, sshd open the file and > the close it without > > read the key...... > > Any ideas?? > > > > Federico > > > > *********** > > for the root: > > 26728 read(4, > "root:x:0:rootnbin:x:1:root,bin,d"..., 4096) = 946 > > 26728 read(4, "", 4096) = 0 > > 26728 close(4) = 0 > > 26728 munmap(0xb7dce000, 4096) = 0 > > 26728 setgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 0 > > 26728 getgroups32(0, NULL) = 7 > > 26728 getgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 7 > > 26728 setgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 0 > > 26728 setresgid32(-1, 0, -1) = 0 > > 26728 setresuid32(-1, 0, -1) = 0 > > 26728 stat64("/root/.ssh/authorized_keys", > {st_mode=S_IFREG|0600, > > st_size=1664, ...}) = 0 > > 26728 open("/root/.ssh/authorized_keys", > O_RDONLY|O_LARGEFILE) = 4 > > 26728 lstat64("/root", > {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 > > 26728 lstat64("/root/.ssh", > {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 > > 26728 lstat64("/root/.ssh/authorized_keys", > {st_mode=S_IFREG|0600, > > st_size=1664, ...}) = 0 > > 26728 lstat64("/root", > {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 > > 26728 fstat64(4, {st_mode=S_IFREG|0600, st_size=1664, > ...}) = 0 > > 26728 stat64("/root/.ssh", > {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 > > 26728 stat64("/root", {st_mode=S_IFDIR|0750, > st_size=4096, ...}) = 0 > > 26728 fstat64(4, {st_mode=S_IFREG|0600, st_size=1664, > ...}) = 0 > > 26728 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, > > -1, 0) = 0xb7dce000 > > 26728 read(4, "ssh-dss > AAAAB3NzaC1kc3MAAACBALxI"..., 4096) = 1664 > > 26728 setresuid32(-1, 0, -1) = 0 > > > > *************** > > and for another user: > > 23996 read(4, > "root:x:0:rootnbin:x:1:root,bin,d"..., 4096) = 946 > > 23996 read(4, "", 4096) = 0 > > 23996 close(4) = 0 > > 23996 munmap(0xb7e7c000, 4096) = 0 > > 23996 setgroups32(2, [501, 502]) = 0 > > 23996 getgroups32(0, NULL) = 2 > > 23996 getgroups32(2, [501, 502]) = 2 > > 23996 setgroups32(2, [501, 502]) = 0 > > 23996 setresgid32(-1, 501, -1) = 0 > > 23996 setresuid32(-1, 501, -1) = 0 > > 23996 > stat64("/u1/oracle/.ssh/authorized_keys", > {st_mode=S_IFREG|0644, > > st_size=836, ...}) = 0 > > 23996 > open("/u1/oracle/.ssh/authorized_keys", > O_RDONLY|O_LARGEFILE) = 4 > > 23996 lstat64("/u1", {st_mode=S_IFDIR|0777, > st_size=4096, ...}) = 0 > > 23996 lstat64("/u1/oracle", > {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > > 23996 lstat64("/u1/oracle/.ssh", > {st_mode=S_IFDIR|0700, st_size=4096, > > ...}) = 0 > > 23996 > lstat64("/u1/oracle/.ssh/authorized_keys", > {st_mode=S_IFREG|0644, > > st_size=836, ...}) = 0 > > 23996 lstat64("/u1", {st_mode=S_IFDIR|0777, > st_size=4096, ...}) = 0 > > 23996 lstat64("/u1/oracle", > {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > > 23996 fstat64(4, {st_mode=S_IFREG|0644, st_size=836, > ...}) = 0 > > 23996 stat64("/u1/oracle/.ssh", > {st_mode=S_IFDIR|0700, st_size=4096, ...}) > > = 0 > > 23996 stat64("/u1/oracle", > {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > > 23996 close(4) = 0 > > 23996 time(NULL) = 1229609500 > > 23996 open("/etc/localtime", O_RDONLY) = 4 > > > > > > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- > "Genius might be described as a supreme capacity for > getting its possessors > into trouble of all kinds." > -- Samuel Butler From kaizaad at sharcnet.ca Sat Dec 20 01:59:27 2008 From: kaizaad at sharcnet.ca (Kaizaad Bilimorya) Date: Fri, 19 Dec 2008 09:59:27 -0500 (EST) Subject: 5.0 vs 5.1 remote command execution In-Reply-To: References: Message-ID: Anybody have any ideas on how to revert to the 5.0p1 behaviour? On Thu, 11 Dec 2008, Kaizaad Bilimorya wrote: > Hello, > > I am experiencing some strange behaviour that I am hoping someone can > shed some light on. > > OS and kernel: > Red Hat Enterprise Linux AS release 4 (Nahant Update 5) > Linux host135 2.6.9-67.9hp.7sp.XCsmp #1 SMP Thu Jul 3 18:55:59 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux > > > built both openssh-5.0p1 and openssh-5.1p1 with the following options: > ./configure --prefix=/usr --libexecdir=/usr/libexec/openssh --localstatedir=/var/empty/sshd \ > --sysconfdir=/etc/ssh --with-pam --with-md5-passwords --with-zlib=/home/XXX/software/zlib-1.2.3 \ > --with-tcp-wrappers > > > With everything else being identical and just swapping the sshd binaries, > I noticed the following: > > # ssh -v host135 > debug1: match: OpenSSH_5.0 pat OpenSSH* > ...snip > # ssh host135 'echo $PATH' > /opt/octave/current:/opt/mpiblast/current/bin:/opt/lammps/current/bin:/opt/dlpoly/current/execute: > ...snip > > # ssh -v host135 > debug1: match: OpenSSH_5.1 pat OpenSSH* > ...snip > # ssh host135 'echo $PATH' > /usr/bin:/bin:/usr/sbin:/sbin > > > According to the docs, the behaviour exhibited by v5.1 is correct, remote > command execution should not process the user's login shell and env. But > why was this happening in v5.0? I can't find anything in the 5.1 change > log that explains this change in behaviour. > > thanks > -k > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From fede_home at yahoo.it Sat Dec 20 01:12:26 2008 From: fede_home at yahoo.it (Fede Rico) Date: Fri, 19 Dec 2008 14:12:26 +0000 (GMT) Subject: only root without password In-Reply-To: <5558FE1FBD1865B195C3BA28@ZOP-MACTEL.local> Message-ID: <36591.7267.qm@web26006.mail.ukl.yahoo.com> Hi again. this is the .ssh permission: .ssh 4,0K drwx------ 2 oracle oinstall 4,0K 2008-12-04 22:44 .ssh .ssh/ 4,0K -rw-r--r-- 1 oracle oinstall 859 2008-12-04 22:44 authorized_keys 4,0K -rw------- 1 oracle oinstall 1,7K 2008-12-04 22:39 id_rsa 4,0K -rw-r--r-- 1 oracle oinstall 403 2008-12-04 22:39 id_rsa.pub 4,0K -rw-r--r-- 1 oracle oinstall 1,5K 2008-12-17 19:07 known_hosts I think it is all ok. Federico --- Ven 19/12/08, Michael Loftis ha scritto: > Da: Michael Loftis > Oggetto: Re: only root without password > A: fede_home at yahoo.it, openssh-unix-dev at mindrot.org > Data: Venerd? 19 dicembre 2008, 10:16 > make sure the directory and file are owned by the user. the > directory > especially has to be the right mode. 0700 on ~/.ssh owned > by the user. > key files i think it wants them to not be writeable by > others. The SSH > daemon must also be able to access the keyfiles - usually > root can but in > some weird setups (EG with ACLs) it might be inaccessible > to root. > > --On December 19, 2008 2:12:38 AM +0000 Fede Rico > > wrote: > > > Hi all, > > I have a very strange problem with the public key > authentication with 2 > > machines. > > I generated the key, configured the authorized_keys > etc.. etc.. This is > > all ok, now: > > The ssh works without the password for the > "root" user, any other user > > cannot use the key and ssh ask me for the password !! > > I cannot understand why only the root is able to > connect without the > > password. So, the ssh works and I think there is a > wrong config file but I > > cannt find it !!!! > > Just to understand the issue, let's see the strace > of sshd daemon. As you > > can see when the root connect the sshd reads the key > file, but when > > another user try to connect, sshd open the file and > the close it without > > read the key...... > > Any ideas?? > > > > Federico > > > > *********** > > for the root: > > 26728 read(4, > "root:x:0:rootnbin:x:1:root,bin,d"..., 4096) = 946 > > 26728 read(4, "", 4096) = 0 > > 26728 close(4) = 0 > > 26728 munmap(0xb7dce000, 4096) = 0 > > 26728 setgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 0 > > 26728 getgroups32(0, NULL) = 7 > > 26728 getgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 7 > > 26728 setgroups32(7, [0, 1, 2, 3, 4, 6, 10]) = 0 > > 26728 setresgid32(-1, 0, -1) = 0 > > 26728 setresuid32(-1, 0, -1) = 0 > > 26728 stat64("/root/.ssh/authorized_keys", > {st_mode=S_IFREG|0600, > > st_size=1664, ...}) = 0 > > 26728 open("/root/.ssh/authorized_keys", > O_RDONLY|O_LARGEFILE) = 4 > > 26728 lstat64("/root", > {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 > > 26728 lstat64("/root/.ssh", > {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 > > 26728 lstat64("/root/.ssh/authorized_keys", > {st_mode=S_IFREG|0600, > > st_size=1664, ...}) = 0 > > 26728 lstat64("/root", > {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 > > 26728 fstat64(4, {st_mode=S_IFREG|0600, st_size=1664, > ...}) = 0 > > 26728 stat64("/root/.ssh", > {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 > > 26728 stat64("/root", {st_mode=S_IFDIR|0750, > st_size=4096, ...}) = 0 > > 26728 fstat64(4, {st_mode=S_IFREG|0600, st_size=1664, > ...}) = 0 > > 26728 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, > > -1, 0) = 0xb7dce000 > > 26728 read(4, "ssh-dss > AAAAB3NzaC1kc3MAAACBALxI"..., 4096) = 1664 > > 26728 setresuid32(-1, 0, -1) = 0 > > > > *************** > > and for another user: > > 23996 read(4, > "root:x:0:rootnbin:x:1:root,bin,d"..., 4096) = 946 > > 23996 read(4, "", 4096) = 0 > > 23996 close(4) = 0 > > 23996 munmap(0xb7e7c000, 4096) = 0 > > 23996 setgroups32(2, [501, 502]) = 0 > > 23996 getgroups32(0, NULL) = 2 > > 23996 getgroups32(2, [501, 502]) = 2 > > 23996 setgroups32(2, [501, 502]) = 0 > > 23996 setresgid32(-1, 501, -1) = 0 > > 23996 setresuid32(-1, 501, -1) = 0 > > 23996 > stat64("/u1/oracle/.ssh/authorized_keys", > {st_mode=S_IFREG|0644, > > st_size=836, ...}) = 0 > > 23996 > open("/u1/oracle/.ssh/authorized_keys", > O_RDONLY|O_LARGEFILE) = 4 > > 23996 lstat64("/u1", {st_mode=S_IFDIR|0777, > st_size=4096, ...}) = 0 > > 23996 lstat64("/u1/oracle", > {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > > 23996 lstat64("/u1/oracle/.ssh", > {st_mode=S_IFDIR|0700, st_size=4096, > > ...}) = 0 > > 23996 > lstat64("/u1/oracle/.ssh/authorized_keys", > {st_mode=S_IFREG|0644, > > st_size=836, ...}) = 0 > > 23996 lstat64("/u1", {st_mode=S_IFDIR|0777, > st_size=4096, ...}) = 0 > > 23996 lstat64("/u1/oracle", > {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > > 23996 fstat64(4, {st_mode=S_IFREG|0644, st_size=836, > ...}) = 0 > > 23996 stat64("/u1/oracle/.ssh", > {st_mode=S_IFDIR|0700, st_size=4096, ...}) > > = 0 > > 23996 stat64("/u1/oracle", > {st_mode=S_IFDIR|0774, st_size=4096, ...}) = 0 > > 23996 close(4) = 0 > > 23996 time(NULL) = 1229609500 > > 23996 open("/etc/localtime", O_RDONLY) = 4 > > > > > > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- > "Genius might be described as a supreme capacity for > getting its possessors > into trouble of all kinds." > -- Samuel Butler From imorgan at nas.nasa.gov Sat Dec 20 03:58:34 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 19 Dec 2008 08:58:34 -0800 Subject: only root without password In-Reply-To: <778656.78601.qm@web26008.mail.ukl.yahoo.com> References: <778656.78601.qm@web26008.mail.ukl.yahoo.com> Message-ID: <20081219165834.GA25982@linux55.nas.nasa.gov> On Fri, Dec 19, 2008 at 02:12:38 +0000, Fede Rico wrote: > Hi all, > I have a very strange problem with the public key authentication with 2 > machines. > I generated the key, configured the authorized_keys etc.. etc.. This is > all ok, now: > The ssh works without the password for the "root" user, any other user > cannot use the key and ssh ask me for the password !! > I cannot understand why only the root is able to connect without the > password. So, the ssh works and I think there is a wrong config file but I > cannt find it !!!! > Just to understand the issue, let's see the strace of sshd daemon. As you > can see when the root connect the sshd reads the key file, but when > another user try to connect, sshd open the file and the close it without > read the key...... > Any ideas?? > > Federico > For debugging purposes, it's usually more useful to use the output of ssh-v (or sshd -d) rather than strace. Check teh output of ssh -v for both cases and confirm that the client is offering a public key in both cases. -- Iain Morgan From bob at proulx.com Sat Dec 20 04:18:34 2008 From: bob at proulx.com (Bob Proulx) Date: Fri, 19 Dec 2008 10:18:34 -0700 Subject: only root without password In-Reply-To: <36591.7267.qm@web26006.mail.ukl.yahoo.com> References: <5558FE1FBD1865B195C3BA28@ZOP-MACTEL.local> <36591.7267.qm@web26006.mail.ukl.yahoo.com> Message-ID: <20081219171833.GA22373@dementia.proulx.com> Fede Rico wrote: > this is the .ssh permission: > > .ssh > 4,0K drwx------ 2 oracle oinstall 4,0K 2008-12-04 22:44 .ssh > > .ssh/ > 4,0K -rw-r--r-- 1 oracle oinstall 859 2008-12-04 22:44 authorized_keys > 4,0K -rw------- 1 oracle oinstall 1,7K 2008-12-04 22:39 id_rsa > 4,0K -rw-r--r-- 1 oracle oinstall 403 2008-12-04 22:39 id_rsa.pub > 4,0K -rw-r--r-- 1 oracle oinstall 1,5K 2008-12-17 19:07 known_hosts You did not show the permissions on the home directory. Those are also considered and are often the source of problems. chmod go-w $HOME > The ssh works without the password for the "root" user, any other user > cannot use the key and ssh ask me for the password !! It is possible that root has an ssh-agent and the ssh-agent has an authorized key loaded but the non-root user does not? That could give the appearance of what you describe. ssh-add -l ssh-add -L Bob From fede_home at yahoo.it Sat Dec 20 07:02:00 2008 From: fede_home at yahoo.it (Fede Rico) Date: Fri, 19 Dec 2008 20:02:00 +0000 (GMT) Subject: only root without password In-Reply-To: <20081219171833.GA22373@dementia.proulx.com> Message-ID: <34151.53823.qm@web26008.mail.ukl.yahoo.com> Hi, for both root and oracle user: ssh-add -l Could not open a connection to your authentication agent. ssh-add -L Could not open a connection to your authentication agent. I changed the home perimission, same result. I will try to use a sshd with -ddd options and try to see why I have this issue. Federico --- Ven 19/12/08, Bob Proulx ha scritto: > Da: Bob Proulx > Oggetto: Re: only root without password > A: "Fede Rico" > Cc: openssh-unix-dev at mindrot.org > Data: Venerd? 19 dicembre 2008, 18:18 > Fede Rico wrote: > > this is the .ssh permission: > > > > .ssh > > 4,0K drwx------ 2 oracle oinstall 4,0K 2008-12-04 > 22:44 .ssh > > > > .ssh/ > > 4,0K -rw-r--r-- 1 oracle oinstall 859 2008-12-04 > 22:44 authorized_keys > > 4,0K -rw------- 1 oracle oinstall 1,7K 2008-12-04 > 22:39 id_rsa > > 4,0K -rw-r--r-- 1 oracle oinstall 403 2008-12-04 > 22:39 id_rsa.pub > > 4,0K -rw-r--r-- 1 oracle oinstall 1,5K 2008-12-17 > 19:07 known_hosts > > You did not show the permissions on the home directory. > Those are > also considered and are often the source of problems. > > chmod go-w $HOME > > > The ssh works without the password for the > "root" user, any other user > > cannot use the key and ssh ask me for the password !! > > It is possible that root has an ssh-agent and the ssh-agent > has an > authorized key loaded but the non-root user does not? That > could give > the appearance of what you describe. > > ssh-add -l > ssh-add -L > > Bob From fede_home at yahoo.it Sat Dec 20 07:24:07 2008 From: fede_home at yahoo.it (Fede Rico) Date: Fri, 19 Dec 2008 20:24:07 +0000 (GMT) Subject: only root without password In-Reply-To: <20081219171833.GA22373@dementia.proulx.com> Message-ID: <88137.95112.qm@web26001.mail.ukl.yahoo.com> The sshd -ddd output debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 321 debug2: parse_server_config: config /etc/ssh/sshd_config len 321 debug1: sshd version OpenSSH_3.9p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-ddd' debug1: rexec_argv[3]='-p' debug1: rexec_argv[4]='3333' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 3333 on ::. Server listening on :: port 3333. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 3333 on 0.0.0.0. Bind to port 3333 on 0.0.0.0 failed: Address already in use. Generating 768 bit RSA key. RSA key generation complete. debug3: fd 4 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 321 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 --- Ven 19/12/08, Bob Proulx ha scritto: > Da: Bob Proulx > Oggetto: Re: only root without password > A: "Fede Rico" > Cc: openssh-unix-dev at mindrot.org > Data: Venerd? 19 dicembre 2008, 18:18 > Fede Rico wrote: > > this is the .ssh permission: > > > > .ssh > > 4,0K drwx------ 2 oracle oinstall 4,0K 2008-12-04 > 22:44 .ssh > > > > .ssh/ > > 4,0K -rw-r--r-- 1 oracle oinstall 859 2008-12-04 > 22:44 authorized_keys > > 4,0K -rw------- 1 oracle oinstall 1,7K 2008-12-04 > 22:39 id_rsa > > 4,0K -rw-r--r-- 1 oracle oinstall 403 2008-12-04 > 22:39 id_rsa.pub > > 4,0K -rw-r--r-- 1 oracle oinstall 1,5K 2008-12-17 > 19:07 known_hosts > > You did not show the permissions on the home directory. > Those are > also considered and are often the source of problems. > > chmod go-w $HOME > > > The ssh works without the password for the > "root" user, any other user > > cannot use the key and ssh ask me for the password !! > > It is possible that root has an ssh-agent and the ssh-agent > has an > authorized key loaded but the non-root user does not? That > could give > the appearance of what you describe. > > ssh-add -l > ssh-add -L > > Bob From dan at aoindustries.com Sat Dec 20 09:25:46 2008 From: dan at aoindustries.com (Dan Armstrong) Date: Fri, 19 Dec 2008 16:25:46 -0600 Subject: Using realloc to remove MAX_LISTEN_SOCKS limit on sshd.c Message-ID: <494C1F6A.7010605@aoindustries.com> OpenSSH developers, I have removed the fixed, arbitrary limit on the number of ListenAddress allowed by using realloc to dynamically expand listen_socks as needed. This completely removes MAX_LISTEN_SOCKS from the source. I made this change on the version of OpenSSH shipped with CentOS 5.2, version 4.3p2. Please see the attached .c file and .diff file. Please add these changes to OpenSSH to save people from having to predetermine their workload before compilation. It can also save some people some grief - I've been unable to login to a server because of this one. sshd.c.orig is the original file bundled in the CentOS source RPM sshd.c is the new version sshd.c.diff is the difference between then: diff sshd.c.orig sshd.c Thank you, -- Dan Armstrong AO Industries, Inc. dan at aoindustries.com Work: (251) 607-9556 Cell: (205) 454-2556 -------------- next part -------------- A non-text attachment was scrubbed... Name: sshd.c Type: text/x-csrc Size: 56316 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081219/51d6495b/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: sshd.c.diff Type: text/x-patch Size: 925 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081219/51d6495b/attachment-0003.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshd.c.orig Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081219/51d6495b/attachment-0001.ksh From mouring at eviladmin.org Sat Dec 20 11:28:59 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 19 Dec 2008 18:28:59 -0600 Subject: only root without password In-Reply-To: <88137.95112.qm@web26001.mail.ukl.yahoo.com> References: <88137.95112.qm@web26001.mail.ukl.yahoo.com> Message-ID: <49949C8B-9B85-4F99-8C38-83BDB630E2AE@eviladmin.org> You need to actually show us the connection. Not that you started sshd. Plus you may need to run it on an alternate port (assuming you are not going to down the original deamon). e.g. sshd -ddd -p 35 then on the client side to ssh -p 35 machine. - Ben On Dec 19, 2008, at 2:24 PM, Fede Rico wrote: > The sshd -ddd output > > debug2: load_server_config: filename /etc/ssh/sshd_config > debug2: load_server_config: done config len = 321 > debug2: parse_server_config: config /etc/ssh/sshd_config len 321 > debug1: sshd version OpenSSH_3.9p1 > debug1: private host key: #0 type 0 RSA1 > debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #1 type 1 RSA > debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #2 type 2 DSA > debug1: rexec_argv[0]='/usr/sbin/sshd' > debug1: rexec_argv[1]='-D' > debug1: rexec_argv[2]='-ddd' > debug1: rexec_argv[3]='-p' > debug1: rexec_argv[4]='3333' > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 3333 on ::. > Server listening on :: port 3333. > debug2: fd 4 setting O_NONBLOCK > debug1: Bind to port 3333 on 0.0.0.0. > Bind to port 3333 on 0.0.0.0 failed: Address already in use. > Generating 768 bit RSA key. > RSA key generation complete. > debug3: fd 4 is not O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 7 config len 321 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 > > > > --- Ven 19/12/08, Bob Proulx ha scritto: > >> Da: Bob Proulx >> Oggetto: Re: only root without password >> A: "Fede Rico" >> Cc: openssh-unix-dev at mindrot.org >> Data: Venerd? 19 dicembre 2008, 18:18 >> Fede Rico wrote: >>> this is the .ssh permission: >>> >>> .ssh >>> 4,0K drwx------ 2 oracle oinstall 4,0K 2008-12-04 >> 22:44 .ssh >>> >>> .ssh/ >>> 4,0K -rw-r--r-- 1 oracle oinstall 859 2008-12-04 >> 22:44 authorized_keys >>> 4,0K -rw------- 1 oracle oinstall 1,7K 2008-12-04 >> 22:39 id_rsa >>> 4,0K -rw-r--r-- 1 oracle oinstall 403 2008-12-04 >> 22:39 id_rsa.pub >>> 4,0K -rw-r--r-- 1 oracle oinstall 1,5K 2008-12-17 >> 19:07 known_hosts >> >> You did not show the permissions on the home directory. >> Those are >> also considered and are often the source of problems. >> >> chmod go-w $HOME >> >>> The ssh works without the password for the >> "root" user, any other user >>> cannot use the key and ssh ask me for the password !! >> >> It is possible that root has an ssh-agent and the ssh-agent >> has an >> authorized key loaded but the non-root user does not? That >> could give >> the appearance of what you describe. >> >> ssh-add -l >> ssh-add -L >> >> Bob > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From imorgan at nas.nasa.gov Sat Dec 20 11:34:05 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 19 Dec 2008 16:34:05 -0800 Subject: only root without password In-Reply-To: <88137.95112.qm@web26001.mail.ukl.yahoo.com> References: <20081219171833.GA22373@dementia.proulx.com> <88137.95112.qm@web26001.mail.ukl.yahoo.com> Message-ID: <20081220003405.GA14864@linux55.nas.nasa.gov> The main observation from this output is that you're running a fairly old version of OpenSSH. While it includes the startup of sshd, it does not appear to have any information regarding attempted connections. I recommend taking a step back and debug from the client first. After all, it could be that the client is not offering a public key in the problematic case. Start with an ssh -v for each case (not -vvv). That will enable you to confirm whether or not the client is doing the right thing. After that, try sshd -d. On Fri, Dec 19, 2008 at 20:24:07 +0000, Fede Rico wrote: > The sshd -ddd output > > debug2: load_server_config: filename /etc/ssh/sshd_config > debug2: load_server_config: done config len = 321 > debug2: parse_server_config: config /etc/ssh/sshd_config len 321 > debug1: sshd version OpenSSH_3.9p1 > debug1: private host key: #0 type 0 RSA1 > debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #1 type 1 RSA > debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #2 type 2 DSA > debug1: rexec_argv[0]='/usr/sbin/sshd' > debug1: rexec_argv[1]='-D' > debug1: rexec_argv[2]='-ddd' > debug1: rexec_argv[3]='-p' > debug1: rexec_argv[4]='3333' > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 3333 on ::. > Server listening on :: port 3333. > debug2: fd 4 setting O_NONBLOCK > debug1: Bind to port 3333 on 0.0.0.0. > Bind to port 3333 on 0.0.0.0 failed: Address already in use. > Generating 768 bit RSA key. > RSA key generation complete. > debug3: fd 4 is not O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 7 config len 321 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 > > > > --- Ven 19/12/08, Bob Proulx ha scritto: > > > Da: Bob Proulx > > Oggetto: Re: only root without password > > A: "Fede Rico" > > Cc: openssh-unix-dev at mindrot.org > > Data: Venerd? 19 dicembre 2008, 18:18 > > Fede Rico wrote: > > > this is the .ssh permission: > > > > > > .ssh > > > 4,0K drwx------ 2 oracle oinstall 4,0K 2008-12-04 > > 22:44 .ssh > > > > > > .ssh/ > > > 4,0K -rw-r--r-- 1 oracle oinstall 859 2008-12-04 > > 22:44 authorized_keys > > > 4,0K -rw------- 1 oracle oinstall 1,7K 2008-12-04 > > 22:39 id_rsa > > > 4,0K -rw-r--r-- 1 oracle oinstall 403 2008-12-04 > > 22:39 id_rsa.pub > > > 4,0K -rw-r--r-- 1 oracle oinstall 1,5K 2008-12-17 > > 19:07 known_hosts > > > > You did not show the permissions on the home directory. > > Those are > > also considered and are often the source of problems. > > > > chmod go-w $HOME > > > > > The ssh works without the password for the > > "root" user, any other user > > > cannot use the key and ssh ask me for the password !! > > > > It is possible that root has an ssh-agent and the ssh-agent > > has an > > authorized key loaded but the non-root user does not? That > > could give > > the appearance of what you describe. > > > > ssh-add -l > > ssh-add -L > > > > Bob > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From tim at multitalents.net Sat Dec 20 14:30:41 2008 From: tim at multitalents.net (Tim Rice) Date: Fri, 19 Dec 2008 19:30:41 -0800 (PST) Subject: only root without password In-Reply-To: <34151.53823.qm@web26008.mail.ukl.yahoo.com> References: <34151.53823.qm@web26008.mail.ukl.yahoo.com> Message-ID: On Fri, 19 Dec 2008, Fede Rico wrote: > Hi, > for both root and oracle user: > ssh-add -l > Could not open a connection to your authentication agent. > ssh-add -L > Could not open a connection to your authentication agent. I may have missed this in earlier post but is ssh-agent running for those 2 users? And does their environment include SSH_AUTH_SOCK? > I changed the home perimission, same result. > I will try to use a sshd with -ddd options and try to see why I have this issue. > > Federico -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From fede_home at yahoo.it Mon Dec 22 04:55:00 2008 From: fede_home at yahoo.it (Fede Rico) Date: Sun, 21 Dec 2008 17:55:00 +0000 (GMT) Subject: only root without password In-Reply-To: <49949C8B-9B85-4F99-8C38-83BDB630E2AE@eviladmin.org> Message-ID: <222484.23464.qm@web26007.mail.ukl.yahoo.com> Hi, this is all the output thant I have. sorry for this long email.... SERVER [root at xxx ~]# /usr/sbin/sshd -D -ddd -p 3333 debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 321 debug2: parse_server_config: config /etc/ssh/sshd_config len 321 debug1: sshd version OpenSSH_3.9p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-ddd' debug1: rexec_argv[3]='-p' debug1: rexec_argv[4]='3333' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 3333 on ::. Server listening on :: port 3333. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 3333 on 0.0.0.0. Bind to port 3333 on 0.0.0.0 failed: Address already in use. Generating 768 bit RSA key. RSA key generation complete. debug3: fd 4 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 321 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 CLIENT [oracle at xxx log]$ ssh -vvv -p 3333 xxx OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to xxx [xxx.xxx.xxx.xxx] port 3333. debug1: Connection established. debug1: identity file /u1/oracle/.ssh/identity type 0 debug3: Not a RSA1 key file /u1/oracle/.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 /u1/oracle/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /u1/oracle/.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 /u1/oracle/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-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-cbc,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-cbc,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-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,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-group14-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-cbc,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-cbc,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-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,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(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 119/256 debug2: bits set: 513/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /u1/oracle/.ssh/known_hosts debug3: check_host_in_hostfile: match line 5 debug3: check_host_in_hostfile: filename /u1/oracle/.ssh/known_hosts debug3: check_host_in_hostfile: match line 5 debug1: Host 'xxx' is known and matches the RSA host key. debug1: Found key in /u1/oracle/.ssh/known_hosts:5 debug2: bits set: 501/1024 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: /u1/oracle/.ssh/id_rsa (0x8a0d658) debug2: key: /u1/oracle/.ssh/id_dsa (0x8a0d670) debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-with-mic,password debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /u1/oracle/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Offering public key: /u1/oracle/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password oracle at xxx's password: --- Sab 20/12/08, Ben Lindstrom ha scritto: > Da: Ben Lindstrom > Oggetto: Re: only root without password > A: fede_home at yahoo.it > Cc: openssh-unix-dev at mindrot.org > Data: Sabato 20 dicembre 2008, 01:28 > You need to actually show us the connection. Not that you > started > sshd. Plus you may need to run it on an alternate port > (assuming you > are not going to down the original deamon). e.g. sshd > -ddd -p 35 > then on the client side to ssh -p 35 machine. > > - Ben > > On Dec 19, 2008, at 2:24 PM, Fede Rico wrote: > > > The sshd -ddd output > > > > debug2: load_server_config: filename > /etc/ssh/sshd_config > > debug2: load_server_config: done config len = 321 > > debug2: parse_server_config: config > /etc/ssh/sshd_config len 321 > > debug1: sshd version OpenSSH_3.9p1 > > debug1: private host key: #0 type 0 RSA1 > > debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. > > debug1: read PEM private key done: type RSA > > debug1: private host key: #1 type 1 RSA > > debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. > > debug1: read PEM private key done: type DSA > > debug1: private host key: #2 type 2 DSA > > debug1: rexec_argv[0]='/usr/sbin/sshd' > > debug1: rexec_argv[1]='-D' > > debug1: rexec_argv[2]='-ddd' > > debug1: rexec_argv[3]='-p' > > debug1: rexec_argv[4]='3333' > > debug2: fd 3 setting O_NONBLOCK > > debug1: Bind to port 3333 on ::. > > Server listening on :: port 3333. > > debug2: fd 4 setting O_NONBLOCK > > debug1: Bind to port 3333 on 0.0.0.0. > > Bind to port 3333 on 0.0.0.0 failed: Address already > in use. > > Generating 768 bit RSA key. > > RSA key generation complete. > > debug3: fd 4 is not O_NONBLOCK > > debug1: Server will not fork when running in debugging > mode. > > debug3: send_rexec_state: entering fd = 7 config len > 321 > > debug3: ssh_msg_send: type 0 > > debug3: send_rexec_state: done > > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock > 7 > > > > > > > > --- Ven 19/12/08, Bob Proulx ha > scritto: > > > >> Da: Bob Proulx > >> Oggetto: Re: only root without password > >> A: "Fede Rico" > > >> Cc: openssh-unix-dev at mindrot.org > >> Data: Venerd? 19 dicembre 2008, 18:18 > >> Fede Rico wrote: > >>> this is the .ssh permission: > >>> > >>> .ssh > >>> 4,0K drwx------ 2 oracle oinstall 4,0K > 2008-12-04 > >> 22:44 .ssh > >>> > >>> .ssh/ > >>> 4,0K -rw-r--r-- 1 oracle oinstall 859 > 2008-12-04 > >> 22:44 authorized_keys > >>> 4,0K -rw------- 1 oracle oinstall 1,7K > 2008-12-04 > >> 22:39 id_rsa > >>> 4,0K -rw-r--r-- 1 oracle oinstall 403 > 2008-12-04 > >> 22:39 id_rsa.pub > >>> 4,0K -rw-r--r-- 1 oracle oinstall 1,5K > 2008-12-17 > >> 19:07 known_hosts > >> > >> You did not show the permissions on the home > directory. > >> Those are > >> also considered and are often the source of > problems. > >> > >> chmod go-w $HOME > >> > >>> The ssh works without the password for the > >> "root" user, any other user > >>> cannot use the key and ssh ask me for the > password !! > >> > >> It is possible that root has an ssh-agent and the > ssh-agent > >> has an > >> authorized key loaded but the non-root user does > not? That > >> could give > >> the appearance of what you describe. > >> > >> ssh-add -l > >> ssh-add -L > >> > >> Bob > > > > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From tteikhua at dso.org.sg Mon Dec 22 04:34:25 2008 From: tteikhua at dso.org.sg (Peter Teoh) Date: Mon, 22 Dec 2008 01:34:25 +0800 Subject: Using realloc to remove MAX_LISTEN_SOCKS limit on sshd.c In-Reply-To: <494C1F6A.7010605@aoindustries.com> References: <494C1F6A.7010605@aoindustries.com> Message-ID: <494E7E21.7000809@dso.org.sg> Dan Armstrong wrote: > OpenSSH developers, > > I have removed the fixed, arbitrary limit on the number of > ListenAddress allowed by using realloc to dynamically expand > listen_socks as needed. This completely removes MAX_LISTEN_SOCKS from > the source. I made this change on the version of OpenSSH shipped with > CentOS 5.2, version 4.3p2. Please see the attached .c file and .diff > file. Please add these changes to OpenSSH to save people from having > to predetermine their workload before compilation. It can also save > some people some grief - I've been unable to login to a server because > of this one. Sorry if I may ask the risks of this option - will it not lead to any potential scenario of Denial of Service, if some how the number of ListenAddress can be arbitrarily increase without limit, and thus leading to realloc() allocating large amount of memory? Thanks. From djm at mindrot.org Mon Dec 22 19:23:18 2008 From: djm at mindrot.org (Damien Miller) Date: Mon, 22 Dec 2008 19:23:18 +1100 (EST) Subject: only root without password In-Reply-To: <222484.23464.qm@web26007.mail.ukl.yahoo.com> References: <222484.23464.qm@web26007.mail.ukl.yahoo.com> Message-ID: Somehow you are still failing to post the output of the server actually accepting a connection. Perhaps there was a bug in 3.9p1 that made this not work, but it was so long ago that I forget. Can you replicate the problem with a recent (5.1p1) sshd? -d On Sun, 21 Dec 2008, Fede Rico wrote: > Hi, > this is all the output thant I have. > sorry for this long email.... > > SERVER > [root at xxx ~]# /usr/sbin/sshd -D -ddd -p 3333 > debug2: load_server_config: filename /etc/ssh/sshd_config > debug2: load_server_config: done config len = 321 > debug2: parse_server_config: config /etc/ssh/sshd_config len 321 > debug1: sshd version OpenSSH_3.9p1 > debug1: private host key: #0 type 0 RSA1 > debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #1 type 1 RSA > debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #2 type 2 DSA > debug1: rexec_argv[0]='/usr/sbin/sshd' > debug1: rexec_argv[1]='-D' > debug1: rexec_argv[2]='-ddd' > debug1: rexec_argv[3]='-p' > debug1: rexec_argv[4]='3333' > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 3333 on ::. > Server listening on :: port 3333. > debug2: fd 4 setting O_NONBLOCK > debug1: Bind to port 3333 on 0.0.0.0. > Bind to port 3333 on 0.0.0.0 failed: Address already in use. > Generating 768 bit RSA key. > RSA key generation complete. > debug3: fd 4 is not O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 7 config len 321 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 > > CLIENT > [oracle at xxx log]$ ssh -vvv -p 3333 xxx > OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to xxx [xxx.xxx.xxx.xxx] port 3333. > debug1: Connection established. > debug1: identity file /u1/oracle/.ssh/identity type 0 > debug3: Not a RSA1 key file /u1/oracle/.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 /u1/oracle/.ssh/id_rsa type 1 > debug3: Not a RSA1 key file /u1/oracle/.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 /u1/oracle/.ssh/id_dsa type 2 > debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1 > debug1: match: OpenSSH_3.9p1 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.9p1 > debug2: fd 3 setting O_NONBLOCK > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-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-cbc,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-cbc,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-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,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-group14-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-cbc,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-cbc,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-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,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(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: dh_gen_key: priv key bits set: 119/256 > debug2: bits set: 513/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: check_host_in_hostfile: filename /u1/oracle/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 5 > debug3: check_host_in_hostfile: filename /u1/oracle/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 5 > debug1: Host 'xxx' is known and matches the RSA host key. > debug1: Found key in /u1/oracle/.ssh/known_hosts:5 > debug2: bits set: 501/1024 > 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: /u1/oracle/.ssh/id_rsa (0x8a0d658) > debug2: key: /u1/oracle/.ssh/id_dsa (0x8a0d670) > debug1: Authentications that can continue: publickey,gssapi-with-mic,password > debug3: start over, passed a different list publickey,gssapi-with-mic,password > debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup gssapi-with-mic > debug3: remaining preferred: publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi-with-mic > debug1: Next authentication method: gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: publickey,gssapi-with-mic,password > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Authentications that can continue: publickey,gssapi-with-mic,password > debug2: we did not send a packet, disable method > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering public key: /u1/oracle/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey,gssapi-with-mic,password > debug1: Offering public key: /u1/oracle/.ssh/id_dsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey,gssapi-with-mic,password > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: ,password > debug3: authmethod_is_enabled password > debug1: Next authentication method: password > oracle at xxx's password: > > > > > > --- Sab 20/12/08, Ben Lindstrom ha scritto: > > > Da: Ben Lindstrom > > Oggetto: Re: only root without password > > A: fede_home at yahoo.it > > Cc: openssh-unix-dev at mindrot.org > > Data: Sabato 20 dicembre 2008, 01:28 > > You need to actually show us the connection. Not that you > > started > > sshd. Plus you may need to run it on an alternate port > > (assuming you > > are not going to down the original deamon). e.g. sshd > > -ddd -p 35 > > then on the client side to ssh -p 35 machine. > > > > - Ben > > > > On Dec 19, 2008, at 2:24 PM, Fede Rico wrote: > > > > > The sshd -ddd output > > > > > > debug2: load_server_config: filename > > /etc/ssh/sshd_config > > > debug2: load_server_config: done config len = 321 > > > debug2: parse_server_config: config > > /etc/ssh/sshd_config len 321 > > > debug1: sshd version OpenSSH_3.9p1 > > > debug1: private host key: #0 type 0 RSA1 > > > debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. > > > debug1: read PEM private key done: type RSA > > > debug1: private host key: #1 type 1 RSA > > > debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. > > > debug1: read PEM private key done: type DSA > > > debug1: private host key: #2 type 2 DSA > > > debug1: rexec_argv[0]='/usr/sbin/sshd' > > > debug1: rexec_argv[1]='-D' > > > debug1: rexec_argv[2]='-ddd' > > > debug1: rexec_argv[3]='-p' > > > debug1: rexec_argv[4]='3333' > > > debug2: fd 3 setting O_NONBLOCK > > > debug1: Bind to port 3333 on ::. > > > Server listening on :: port 3333. > > > debug2: fd 4 setting O_NONBLOCK > > > debug1: Bind to port 3333 on 0.0.0.0. > > > Bind to port 3333 on 0.0.0.0 failed: Address already > > in use. > > > Generating 768 bit RSA key. > > > RSA key generation complete. > > > debug3: fd 4 is not O_NONBLOCK > > > debug1: Server will not fork when running in debugging > > mode. > > > debug3: send_rexec_state: entering fd = 7 config len > > 321 > > > debug3: ssh_msg_send: type 0 > > > debug3: send_rexec_state: done > > > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock > > 7 > > > > > > > > > > > > --- Ven 19/12/08, Bob Proulx ha > > scritto: > > > > > >> Da: Bob Proulx > > >> Oggetto: Re: only root without password > > >> A: "Fede Rico" > > > > >> Cc: openssh-unix-dev at mindrot.org > > >> Data: Venerd? 19 dicembre 2008, 18:18 > > >> Fede Rico wrote: > > >>> this is the .ssh permission: > > >>> > > >>> .ssh > > >>> 4,0K drwx------ 2 oracle oinstall 4,0K > > 2008-12-04 > > >> 22:44 .ssh > > >>> > > >>> .ssh/ > > >>> 4,0K -rw-r--r-- 1 oracle oinstall 859 > > 2008-12-04 > > >> 22:44 authorized_keys > > >>> 4,0K -rw------- 1 oracle oinstall 1,7K > > 2008-12-04 > > >> 22:39 id_rsa > > >>> 4,0K -rw-r--r-- 1 oracle oinstall 403 > > 2008-12-04 > > >> 22:39 id_rsa.pub > > >>> 4,0K -rw-r--r-- 1 oracle oinstall 1,5K > > 2008-12-17 > > >> 19:07 known_hosts > > >> > > >> You did not show the permissions on the home > > directory. > > >> Those are > > >> also considered and are often the source of > > problems. > > >> > > >> chmod go-w $HOME > > >> > > >>> The ssh works without the password for the > > >> "root" user, any other user > > >>> cannot use the key and ssh ask me for the > > password !! > > >> > > >> It is possible that root has an ssh-agent and the > > ssh-agent > > >> has an > > >> authorized key loaded but the non-root user does > > not? That > > >> could give > > >> the appearance of what you describe. > > >> > > >> ssh-add -l > > >> ssh-add -L > > >> > > >> Bob > > > > > > > > > > > > _______________________________________________ > > > openssh-unix-dev mailing list > > > openssh-unix-dev at mindrot.org > > > > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From rwatki at gmail.com Tue Dec 23 00:49:15 2008 From: rwatki at gmail.com (Ron Watkins) Date: Mon, 22 Dec 2008 06:49:15 -0700 Subject: Progress meter Message-ID: There appears to be 2 different styles of progress meter. One style shows stars with total size transfered and time remaining. The second doesn't display the stars, but does provide a percent complete and transfer rate. How can one force a particular style of progress meter? I personally prefer the one which displays the rate of transfer, but I don't know how to get that to display on all my platforms. There appears to be some variation in which platform displays which type of meter. Advice? -- Ron Watkins 602.743.5272 From peter at stuge.se Tue Dec 23 12:43:06 2008 From: peter at stuge.se (Peter Stuge) Date: Tue, 23 Dec 2008 02:43:06 +0100 Subject: Using realloc to remove MAX_LISTEN_SOCKS limit on sshd.c In-Reply-To: <494E7E21.7000809@dso.org.sg> <494C1F6A.7010605@aoindustries.com> References: <494C1F6A.7010605@aoindustries.com> <494E7E21.7000809@dso.org.sg> <494C1F6A.7010605@aoindustries.com> Message-ID: <20081223014306.11825.qmail@stuge.se> Hi, Dan Armstrong wrote: > I made this change on the version of OpenSSH shipped with CentOS > 5.2, version 4.3p2. In the future please make changes against the latest version of the source code which is available via anonymous CVS. Your change is not too big, so hopefully it doesn't require very much work to forward port onto the the latest version. > Please see the attached .c file and .diff file. When sending patches in the future please send only the diff output, and most groups prefer the unified diff format (diff -U) because it is a lot easier to read. > 148,149c148,149 > < #define MAX_LISTEN_SOCKS 16 > < int listen_socks[MAX_LISTEN_SOCKS]; > --- > > int *listen_socks = NULL; > > int listen_socks_len = 0; > 1281,1283d1280 > < if (num_listen_socks >= MAX_LISTEN_SOCKS) > < fatal("Too many listen sockets. " > < "Enlarge MAX_LISTEN_SOCKS"); > 1321a1319,1334 > > /* Create/expand listen_socks as needed */ > > if(num_listen_socks >= listen_socks_len) { > > int *old_listen_socks = listen_socks; > > /* Start at 16 and then double as needed */ > > int new_listen_socks_len = listen_socks_len == 0 ? 16 : (listen_socks_len << 1); > > listen_socks = realloc(listen_socks, new_listen_socks_len * sizeof(int)); > > if(listen_socks == NULL) { > > free(old_listen_socks); > > old_listen_socks = NULL; > > listen_socks_len = 0; > > fatal("realloc listen_socks: %s", strerror(errno)); > > } else { > > listen_socks_len = new_listen_socks_len; > > } > > } I'm not sure.. I would probably just increase MAX_LISTEN_SOCKS. Alternatively perhaps the server you couldn't log in to could set something up with a wildcard listen and a few firewall rules? Peter Teoh wrote: > Sorry if I may ask the risks of this option - will it not lead to > any potential scenario of Denial of Service, if some how the number > of ListenAddress can be arbitrarily increase without limit, and > thus leading to realloc() allocating large amount of memory? It's not a problem. This code runs once at server startup. Whoever is running sshd could use it to allocate large amounts of memory, but they could just as easily build another program which does the same thing. The protection against this situation is to configure limits, maybe using ulimit. //Peter From mouring at eviladmin.org Tue Dec 23 17:30:11 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 23 Dec 2008 00:30:11 -0600 Subject: Using realloc to remove MAX_LISTEN_SOCKS limit on sshd.c In-Reply-To: <494E7E21.7000809@dso.org.sg> References: <494C1F6A.7010605@aoindustries.com> <494E7E21.7000809@dso.org.sg> Message-ID: <095927C2-6EB6-48FD-A54A-82307B5E3223@eviladmin.org> On Dec 21, 2008, at 11:34 AM, Peter Teoh wrote: > Dan Armstrong wrote: >> OpenSSH developers, >> >> I have removed the fixed, arbitrary limit on the number of >> ListenAddress allowed by using realloc to dynamically expand >> listen_socks as needed. This completely removes MAX_LISTEN_SOCKS >> from >> the source. I made this change on the version of OpenSSH shipped >> with >> CentOS 5.2, version 4.3p2. Please see the attached .c file and .diff >> file. Please add these changes to OpenSSH to save people from having >> to predetermine their workload before compilation. It can also save >> some people some grief - I've been unable to login to a server >> because >> of this one. > > Sorry if I may ask the risks of this option - will it not lead to any > potential scenario of Denial of Service, if some how the number of > ListenAddress can be arbitrarily increase without limit, and thus > leading to realloc() allocating large amount of memory? > I can't see how this would be a "DoS", since ListenAddress must be set by the server on launch. One can flood a single port just as easy as they can flood multiple ports. I'm still trying to figure out why one would want OpenSSH listening on more than 15 ports/address combination. Is it really worth the added complexity? - Ben From openssh at roumenpetrov.info Tue Dec 23 20:37:38 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Tue, 23 Dec 2008 11:37:38 +0200 Subject: Patch for OpenSSH for Windows to allow authentication through certificates In-Reply-To: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> References: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> Message-ID: <4950B162.6000107@roumenpetrov.info> Adriana Rodean wrote: > Hi all, > > Does anyone know if it exists a patch for OpenSSH for Windows to allow > authentication through certificates? > Is it possible to make one if it doesn't exists? > Using OpenSSH for Windows 3.8p1-1 20040709 Build. > > I know there is Roumen Petrov patch, but is for unix machines if i'm > not mistaken. > I need a similar one for Windows that work with the Roumen Petrov > patch so i can have authentication through certificates between > Windows machine and Linux machine. > > Any help greatly appreciated, > Adriana Did you try the patch on cygwin platform ? The patch don't use specific to the unix/posix methods(functions). Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From imorgan at nas.nasa.gov Wed Dec 24 03:46:10 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 23 Dec 2008 08:46:10 -0800 Subject: Progress meter In-Reply-To: References: Message-ID: <20081223164610.GA18449@linux55.nas.nasa.gov> On Mon, Dec 22, 2008 at 06:49:15 -0700, Ron Watkins wrote: > There appears to be 2 different styles of progress meter. One style > shows stars with total size transfered and time remaining. The second > doesn't display the stars, but does provide a percent complete and > transfer rate. How can one force a particular style of progress > meter? I personally prefer the one which displays the rate of > transfer, but I don't know how to get that to display on all my > platforms. There appears to be some variation in which platform > displays which type of meter. Advice? > The (stock) progress meter code shows the percentage transferred, the actuall amount transferred, the rate and the ETA. Perhaps an older version of the progress meter code showed the stars; I don't recall. The difference you are seeing may be due to patches that were applied to OpenSSH on one platform but not the other, or might be due to an older version running on one of the platforms. What platforms do you see the 'stars' form and what is the output of ssh -V on those platforms? -- Iain Morgan From dan at aoindustries.com Wed Dec 24 04:59:51 2008 From: dan at aoindustries.com (Dan Armstrong) Date: Tue, 23 Dec 2008 11:59:51 -0600 Subject: Using realloc to remove MAX_LISTEN_SOCKS limit on sshd.c In-Reply-To: <095927C2-6EB6-48FD-A54A-82307B5E3223@eviladmin.org> References: <494C1F6A.7010605@aoindustries.com> <494E7E21.7000809@dso.org.sg> <095927C2-6EB6-48FD-A54A-82307B5E3223@eviladmin.org> Message-ID: <49512717.8050007@aoindustries.com> Ben, I fully agree that there is no DoS aspect to this. As for the patch, it is very simple. It doesn't change the functionality of sshd in any way. It just takes a fixed-size array and replaces it with a dynamically-growable version. The use of predetermined-size arrays, as done in C code everywhere, is sometimes in appropriate and gets in the way of using the software. I have been submitting patches similar to this to various open source projects as they affect me. We have the need for more than 15 binds. In our virtual hosting environment, users can select exactly which services they want enabled on a per-IP basis. Also, we don't bind to 0.0.0.0 because one of our fail-over techniques is to run multiple servers in different chroot environments. Thus, we have different sshd instances running, one per chroot environment, each binding to the specific set of IP addresses associated with the chroot environment. I guess my #1 concern is that once you hit the limit, your sshd is dead. You can't login. You can't get in there to fix the config file to get your sshd back online. If you guys don't like the use of realloc to handle any number of ListenAddress, please at least bind to the first MAX_LISTEN_SOCKS and syslog/stderr warnings about the extras, instead of leaving a dead sshd. I can submit a patch for this behavior, if you like. Please add the patch. It simply allows the software to do what it is told without the risk of a surprise dead sshd. Thank you, Dan Armstrong AO Industries, Inc. dan at aoindustries.com Work: (251) 607-9556 Cell: (205) 454-2556 Ben Lindstrom wrote: > > On Dec 21, 2008, at 11:34 AM, Peter Teoh wrote: > >> Dan Armstrong wrote: >>> OpenSSH developers, >>> >>> I have removed the fixed, arbitrary limit on the number of >>> ListenAddress allowed by using realloc to dynamically expand >>> listen_socks as needed. This completely removes MAX_LISTEN_SOCKS from >>> the source. I made this change on the version of OpenSSH shipped with >>> CentOS 5.2, version 4.3p2. Please see the attached .c file and .diff >>> file. Please add these changes to OpenSSH to save people from having >>> to predetermine their workload before compilation. It can also save >>> some people some grief - I've been unable to login to a server because >>> of this one. >> >> Sorry if I may ask the risks of this option - will it not lead to any >> potential scenario of Denial of Service, if some how the number of >> ListenAddress can be arbitrarily increase without limit, and thus >> leading to realloc() allocating large amount of memory? >> > > I can't see how this would be a "DoS", since ListenAddress must be set > by the server on launch. One can flood a single port just as easy as > they can flood multiple ports. > > I'm still trying to figure out why one would want OpenSSH listening on > more than 15 ports/address combination. Is it really worth the added > complexity? > > - Ben From russ at eatnumber1.com Wed Dec 24 20:38:54 2008 From: russ at eatnumber1.com (Russell Harmon) Date: Wed, 24 Dec 2008 04:38:54 -0500 Subject: Port forwarding using the client of a multiplexed connection. Message-ID: <9c4865a10812240138u25567870yc366b936c7b639c1@mail.gmail.com> I am trying to set up port forwarding using the client of a multiplexed connection, but the client is dying. The connection paramaters I am using are as follows: for the master: /usr/bin/ssh -T -n -N -o ControlMaster=yes -o ControlPath=/var/run/autossh/control-%r@%h-%p.sock -o ConnectionAttempts=3 -o BatchMode=yes -o EscapeChar=none -o ExitOnForwardFailure=yes -o ServerAliveInterval=15 -o ForwardAgent=no -c arcfour -2 -x user at host.com for the client: /usr/bin/ssh -T -n -N -o ControlMaster=no -o ControlPath=/var/run/autossh/control-%r@%h-%p.sock -o ConnectionAttempts=3 -o BatchMode=yes -o EscapeChar=none -o ExitOnForwardFailure=yes -o ServerAliveInterval=15 -o ForwardAgent=no -R 5900:address:5900 -R 5901:address:5901 -c arcfour -2 -x user at host.com The master (this is only the part output when I start the client): debug3: fd 6 is not O_NONBLOCK debug3: ssh_msg_recv entering debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug3: muxserver_accept_control: receiving 0 env vars debug2: muxserver_accept_control: accepted tty 0, subsys 0, cmd debug2: muxserver_accept_control: got fds stdin 7, stdout 8, stderr 9 debug3: ssh_msg_send: type 2 debug2: fd 7 setting O_NONBLOCK debug2: fd 8 setting O_NONBLOCK debug2: fd 9 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: muxserver_accept_control: channel_new: 0 debug2: channel 0: send open debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_confirm: type 99 id 0 debug2: shell request accepted on channel 0 debug2: channel 0: read<=0 rfd 7 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed 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 debug3: channel 0: will not send data after close 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 cfd 6) debug3: channel 0: close_fds r -1 w -1 e 9 c 6 The client: debug1: Reading configuration data /etc/ssh/ssh_config debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug2: Received EOF from master debug2: Received exit status from master 0 Thanks for any help -Russell Harmon From karlis.repsons at gmail.com Wed Dec 24 21:48:18 2008 From: karlis.repsons at gmail.com (=?utf-8?q?K=C4=81rlis_Repsons?=) Date: Wed, 24 Dec 2008 10:48:18 +0000 Subject: process termination after ssh exit Message-ID: <200812241048.18568.Karlis.Repsons@gmail.com> Hello list, I observed a problem with interactive bash script executed by ssh: when I pressed , ssh was killed on client side, but script remained active in remote machine and didn't receive signal INT. Using option -t gives no problem like that, but should it be perceived as a normal behaviour in case without -t? Please send a reply to my address too... From peter at stuge.se Thu Dec 25 02:39:32 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 24 Dec 2008 16:39:32 +0100 Subject: Port forwarding using the client of a multiplexed connection. In-Reply-To: <9c4865a10812240138u25567870yc366b936c7b639c1@mail.gmail.com> References: <9c4865a10812240138u25567870yc366b936c7b639c1@mail.gmail.com> Message-ID: <20081224153932.5541.qmail@stuge.se> Hi Russell, Russell Harmon wrote: > I am trying to set up port forwarding using the client of a > multiplexed connection, but the client is dying. > > The connection paramaters I am using are as follows: > for the master: /usr/bin/ssh -T -n -N .. > for the client: /usr/bin/ssh -T -n -N .. .. > The master (this is only the part output when I start the client): .. > debug2: muxserver_accept_control: got fds stdin 7, stdout 8, stderr 9 .. > debug2: shell request accepted on channel 0 > debug2: channel 0: read<=0 rfd 7 len 0 > debug2: channel 0: read failed > debug2: channel 0: close_read > debug2: channel 0: input open -> drain > debug2: channel 0: ibuf empty > debug2: channel 0: send eof > debug2: channel 0: input drain -> closed .. > The client: .. > debug2: Received EOF from master > debug2: Received exit status from master 0 This is a bit of a wild guess, but does it work if you run the client without -T -N ? It seems the server is trying to read from the client stdin even though -T -N is given, and whey they don't return data the server closes down the client. I'm not sure there should be a shell request when using -T -N.. //Peter From bob at proulx.com Thu Dec 25 15:57:16 2008 From: bob at proulx.com (Bob Proulx) Date: Wed, 24 Dec 2008 21:57:16 -0700 Subject: process termination after ssh exit In-Reply-To: <200812241048.18568.Karlis.Repsons@gmail.com> References: <200812241048.18568.Karlis.Repsons@gmail.com> Message-ID: <20081225045714.GA10293@discord.proulx.com> K?rlis Repsons wrote: > Please send a reply to my address too... > ... > I observed a problem with interactive bash script executed by ssh: when I > pressed , ssh was killed on client side, but script remained active > in remote machine and didn't receive signal INT. > Using option -t gives no problem like that, but should it be perceived as a > normal behaviour in case without -t? The rsh command appeared in 4.2BSD. SSH is a secure replacement for it. The rsh man page includes the following in the bugs section: Stop signals stop the local rsh process only; this is arguably wrong, but currently hard to fix for reasons too complicated to explain here. And therefore we know that this behavior has always been present. Although this functionality would be nice to have the implementation isn't completey straight-forward. There is an open bug tracking this behavior request and a patch in the tracker exists about it. https://bugzilla.mindrot.org/show_bug.cgi?id=396 Bob From russ at eatnumber1.com Sun Dec 28 10:56:09 2008 From: russ at eatnumber1.com (Russell Harmon) Date: Sat, 27 Dec 2008 18:56:09 -0500 Subject: Port forwarding using the client of a multiplexed connection. In-Reply-To: <20081224153932.5541.qmail@stuge.se> References: <9c4865a10812240138u25567870yc366b936c7b639c1@mail.gmail.com> <20081224153932.5541.qmail@stuge.se> Message-ID: <9c4865a10812271556r74778806j1da754cdc31ae4fe@mail.gmail.com> Looking at the code in mux.c, you handle the stdin_null_flag at line 552 by opening /dev/null, but at line 695, you wait until the "controlee closes the client_fd", then clean up, and terminate. Is this correct? On Wed, Dec 24, 2008 at 10:39, Peter Stuge wrote: > Hi Russell, > > Russell Harmon wrote: > > I am trying to set up port forwarding using the client of a > > multiplexed connection, but the client is dying. > > > > The connection paramaters I am using are as follows: > > for the master: /usr/bin/ssh -T -n -N .. > > for the client: /usr/bin/ssh -T -n -N .. > .. > > > The master (this is only the part output when I start the client): > .. > > debug2: muxserver_accept_control: got fds stdin 7, stdout 8, stderr 9 > .. > > debug2: shell request accepted on channel 0 > > debug2: channel 0: read<=0 rfd 7 len 0 > > debug2: channel 0: read failed > > debug2: channel 0: close_read > > debug2: channel 0: input open -> drain > > debug2: channel 0: ibuf empty > > debug2: channel 0: send eof > > debug2: channel 0: input drain -> closed > .. > > > The client: > .. > > debug2: Received EOF from master > > debug2: Received exit status from master 0 > > This is a bit of a wild guess, but does it work if you run the client > without -T -N ? > > It seems the server is trying to read from the client stdin even > though -T -N is given, and whey they don't return data the server > closes down the client. > > I'm not sure there should be a shell request when using -T -N.. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From russ at eatnumber1.com Sun Dec 28 10:37:04 2008 From: russ at eatnumber1.com (Russell Harmon) Date: Sat, 27 Dec 2008 18:37:04 -0500 Subject: Port forwarding using the client of a multiplexed connection. In-Reply-To: <20081224153932.5541.qmail@stuge.se> References: <9c4865a10812240138u25567870yc366b936c7b639c1@mail.gmail.com> <20081224153932.5541.qmail@stuge.se> Message-ID: <9c4865a10812271537m2bddf4d0s67da5d4fc65f9c03@mail.gmail.com> Actually, it seems to be caused by the -n. When devnull is not set to stdin, it works fine... On Wed, Dec 24, 2008 at 10:39, Peter Stuge wrote: > Hi Russell, > > Russell Harmon wrote: > > I am trying to set up port forwarding using the client of a > > multiplexed connection, but the client is dying. > > > > The connection paramaters I am using are as follows: > > for the master: /usr/bin/ssh -T -n -N .. > > for the client: /usr/bin/ssh -T -n -N .. > .. > > > The master (this is only the part output when I start the client): > .. > > debug2: muxserver_accept_control: got fds stdin 7, stdout 8, stderr 9 > .. > > debug2: shell request accepted on channel 0 > > debug2: channel 0: read<=0 rfd 7 len 0 > > debug2: channel 0: read failed > > debug2: channel 0: close_read > > debug2: channel 0: input open -> drain > > debug2: channel 0: ibuf empty > > debug2: channel 0: send eof > > debug2: channel 0: input drain -> closed > .. > > > The client: > .. > > debug2: Received EOF from master > > debug2: Received exit status from master 0 > > This is a bit of a wild guess, but does it work if you run the client > without -T -N ? > > It seems the server is trying to read from the client stdin even > though -T -N is given, and whey they don't return data the server > closes down the client. > > I'm not sure there should be a shell request when using -T -N.. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From frederic.perrin at resel.fr Mon Dec 29 03:52:03 2008 From: frederic.perrin at resel.fr (=?utf-8?Q?Fr=C3=A9d=C3=A9ric_Perrin?=) Date: Sun, 28 Dec 2008 17:52:03 +0100 Subject: [Patch] Adding port support to ssh-keyscan Message-ID: <864p0outsc.fsf@chameau.maisel.enst-bretagne.fr> A non-text attachment was scrubbed... Name: ports.patch Type: text/x-diff Size: 6972 bytes Desc: Add support for the [host]:port syntax to ssh-keyscan Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20081228/51000c08/attachment-0001.bin From stevesk at pobox.com Mon Dec 29 12:20:05 2008 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 28 Dec 2008 17:20:05 -0800 Subject: [Patch] Adding port support to ssh-keyscan In-Reply-To: <864p0outsc.fsf@chameau.maisel.enst-bretagne.fr> References: <864p0outsc.fsf@chameau.maisel.enst-bretagne.fr> Message-ID: <20081229012005.GA23760@steam> On Sun, Dec 28, 2008 at 05:52:03PM +0100, Fr?d?ric Perrin wrote: : I also updated the manpage (and fixed a small mistake : it specified : in the EXAMPLES section that 'ssh-keyscan host' would retrieve the rsa1 : key, and not the rsa2). : .Pa /etc/ssh/ssh_known_hosts : .Sh EXAMPLES : Print the : -.Pa rsa1 : +.Pa rsa2 : host key for machine : .Pa hostname : : .Bd -literal thanks, I committed that fix to openbsd (key type is rsa, not rsa2 though). From samydelux at gmail.com Mon Dec 29 12:00:11 2008 From: samydelux at gmail.com (Samuel Vogel) Date: Mon, 29 Dec 2008 02:00:11 +0100 Subject: Proposal: Different handling of ChrootDirectory Message-ID: <4958211B.8040602@gmail.com> Hey guys, I have read all the messages regarding this issue on the mailing list and I did notice that quite a few people are not exactly happy with the new easiness of the chroot support introduced to openssh. I'm one of them and I think to support my special configuration, the implementation would need to be changed. I'm right now setting up a small web hosting company an every webspace can of course have multiple (S)FTP accounts. The main account of course have access to the "root-dir" of the webspace. This would be "/www/123456" for example. I do understand, that by introducing a subdirectory ("/www/123456/subdir" and chroot to "/www/123456/"), this directory structure could be made to work with the chroot implementation of openssh. But now lets say the user wants to create an account which can only access the wordpress subdirectory of his webspace. This would be "/www/123456/subdir/wordpress". If I chroot the new user into the mentioned directory, he can not create new files. Chrooting him to "/www/123456/subdir" is also not an option, because there could be other subdirectories than only "wordpress". And introducing another subfolder, would totaly mess up the directory structure of the webspace, since the user might only decide later on to add a new (S)FTP Account. So I would have to move around his directories. As I see it, in my case the only option would be to let the user write in his ChrootDirectory. I did read that this has some security implications, but maybe there is a way to work them out or somebody has a different proposal for my problem. I hope I didn't express myself to complicated. If so, feel free to ask for clarification! Any pointers are appreciated! Regards, Samy From dtucker at zip.com.au Tue Dec 30 12:18:46 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 30 Dec 2008 12:18:46 +1100 Subject: installing openssh5.1p In-Reply-To: <389331.19055.qm@web94407.mail.in2.yahoo.com> References: <389331.19055.qm@web94407.mail.in2.yahoo.com> Message-ID: <20081230011845.GA25191@gate.dtucker.net> On Tue, Dec 23, 2008 at 09:14:30AM +0530, Dhanya M.B wrote: > Hi, > > I was trying to install openssh 5.1p from openssh-5.1p1.tar.gz downloaded from www.openssh.com > My system OS is RedHatEnterpriseLinux5.0 Desktop (RHEL5.0) (64 bit). > We have zlib-1.2.3-3 and openssl-0.9.8b-8.3.el5 installed > in the syatem. > > I untarred openssh-5.1p1.tar.gz to > /usr/local/openssh/openssh-5.1p1/. > > When i gave the command ./configure , an error was seen at the end > which is : > configure: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) *** > > I have attached the config.log for reference. The error is: /usr/bin/ld: cannot find -lcrypto This means that it can't link the OpenSSL crutpo library. This can be a couple of things: a) openssl isn't installed (unlikely). It that's the case, install openssl and openssl-devel rpms. b) You have a 64-bit OpenSSL and you're trying to build a 32-bit binary, or vice versa. Either install the libraries for the binary type you're trying to build, or force the binary type ("CFLAGS-"-m32" ./configure" or "CFLAGS=-m64 ./configure". -- 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 karlis.repsons at gmail.com Wed Dec 31 08:24:41 2008 From: karlis.repsons at gmail.com (=?utf-8?q?K=C4=81rlis_Repsons?=) Date: Tue, 30 Dec 2008 21:24:41 +0000 Subject: Set connection timeouts? Message-ID: <200812302124.41888.Karlis.Repsons@gmail.com> Hello, Perhaps you could give some information here or redirect me, because it was not clear while reading manuals: how can connection timeout be set for sshd? Problem is, when some system is hibernated and it resumes, connections are dead. Mostly I made a successful workaround, but would be nice to know... Also, which version of ssh(d) support df on sshfs? I hope, is not a problem to enlighten me a little!