From Dave at Yost.com Mon Jun 1 17:01:39 2009 From: Dave at Yost.com (Dave Yost) Date: Mon, 1 Jun 2009 00:01:39 -0700 Subject: ssh as root with and without private key Message-ID: Hi. I have a client machine using ssh as root via key authorization to a server. The client uses rsync to send backup data to the server. I use ForceCommand to allow only this activity when using key authorization. But I also want to be able to ssh as root with a required password to do whatever I like. So I thought that in addition to root, I'd make a rootback account: root:x:0:0:root:/root:/bin/bash rootback:x:0:0:root:/root:/bin/bash (Entries in /etc/shadow are required for both, turns out.) In sshd_conf I have this Match User rootback PermitRootLogin yes ForceCommand /root/bin/dobackup Match User root PermitRootLogin yes Match When I ssh -l rootback host whatever it runs the dobackup script. However, when I run ssh -l root host date it logs me in without asking for a password and runs date. So close. But not right. Is there a way to get what I want? I'm running openssh.x86_64 5.2p1-2.fc11 on Fedora 11 Thanks Dave From dtucker at zip.com.au Mon Jun 1 18:57:28 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 01 Jun 2009 18:57:28 +1000 Subject: ssh as root with and without private key In-Reply-To: References: Message-ID: <4A2397F8.5080801@zip.com.au> Dave Yost wrote: [...] > In sshd_conf I have this > > Match User rootback > PermitRootLogin yes > ForceCommand /root/bin/dobackup > Match User root > PermitRootLogin yes > Match Is there something missing here? > When I > ssh -l rootback host whatever > it runs the dobackup script. > > However, when I run > ssh -l root host date > it logs me in without asking for a password and runs date. > > So close. But not right. > > Is there a way to get what I want? You want to disallow public-key authentications for root but not rootback? Does adding "PubkeyAuthentication no" to the "Match User root" section do it? (You'd probably want to add the other passwordless authmethods to the list to, eg rsa (protocol 1) gssapi hostbased rhostsrsa and so forth). -- 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 andyb1 at andy-t.org Tue Jun 2 00:19:19 2009 From: andyb1 at andy-t.org (Andy Tsouladze) Date: Mon, 1 Jun 2009 09:19:19 -0500 (CDT) Subject: ssh as root with and without private key In-Reply-To: <4A2397F8.5080801@zip.com.au> References: <4A2397F8.5080801@zip.com.au> Message-ID: On Mon, 1 Jun 2009, Darren Tucker wrote: > Dave Yost wrote: > [...] >> In sshd_conf I have this >> >> Match User rootback >> PermitRootLogin yes I am not sure this can worl. Root login for a non-root user? Even though its UID is 0, for login purposes it is a different user. >> ForceCommand /root/bin/dobackup >> Match User root >> PermitRootLogin yes >> Match > > Is there something missing here? > >> When I >> ssh -l rootback host whatever >> it runs the dobackup script. >> >> However, when I run >> ssh -l root host date >> it logs me in without asking for a password and runs date. >> >> So close. But not right. >> >> Is there a way to get what I want? I would say the easiest way to accomplish what you want it to use different home directories (and thus, different .ssh directories and ssh keys) for root and rootback. Does this work for you? > You want to disallow public-key authentications for root but not rootback? > > Does adding "PubkeyAuthentication no" to the "Match User root" section do it? > (You'd probably want to add the other passwordless authmethods to the list > to, eg rsa (protocol 1) gssapi hostbased rhostsrsa and so forth). > > -- Regards, Andy Dr Andy Tsouladze Sr Unix/Storage SysAdmin From bbelnap at gmail.com Tue Jun 2 00:55:14 2009 From: bbelnap at gmail.com (Bob Belnap) Date: Mon, 1 Jun 2009 08:55:14 -0600 Subject: ssh as root with and without private key In-Reply-To: References: Message-ID: <3be13d470906010755g2ad029ccq2cbf339d77193d8d@mail.gmail.com> Dave, Maybe I'm missing something here... but why don't you just use the "command=" option in authorized_keys? Then just force the backup key to only run /root/bin/dobackup, but add your own key without that restriction? --Bob On Mon, Jun 1, 2009 at 1:01 AM, Dave Yost wrote: > Hi. > > I have a client machine using ssh as root via key authorization to a > server. The client uses rsync to send backup data to the server. I use > ForceCommand to allow only this activity when using key authorization. > > But I also want to be able to ssh as root with a required password to do > whatever I like. > > So I thought that in addition to root, I'd make a rootback account: > > root:x:0:0:root:/root:/bin/bash > rootback:x:0:0:root:/root:/bin/bash > > (Entries in /etc/shadow are required for both, turns out.) > > In sshd_conf I have this > > Match User rootback > PermitRootLogin yes > ForceCommand /root/bin/dobackup > Match User root > PermitRootLogin yes > Match > > When I > ssh -l rootback host whatever > it runs the dobackup script. > > However, when I run > ssh -l root host date > it logs me in without asking for a password and runs date. > > So close. But not right. > > Is there a way to get what I want? > > I'm running > openssh.x86_64 5.2p1-2.fc11 > on Fedora 11 > > Thanks > > Dave > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From 8vinoth at sg.ibm.com Mon Jun 1 21:08:20 2009 From: 8vinoth at sg.ibm.com (I. Vinoth) Date: Mon, 1 Jun 2009 19:08:20 +0800 Subject: ssh option "-C" generates an error Message-ID: Hi Team, While doing ssh with compression option "-C" does not work anymore and produces following error buffer_get_ret: trying to get more bytes 1 than in buffer 0 buffer_get_char_ret: buffer_get_ret failed buffer_get_char: buffer error Environment :- oslevel - AIX 5300-08-04 ssh version --- OpenSSH_4.7p1, OpenSSL 0.9.8f 11 Oct 2007 Please Help me to fix this problem. Many Thanks Vinoth Server Management - Distributed (Unix) Server Systems Operations Services Delivery IBM Global Technology Services : : 8vinoth at sg.ibm.com , M : 65-98072060 From petesea at bigfoot.com Thu Jun 4 05:04:16 2009 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Wed, 03 Jun 2009 12:04:16 -0700 (PDT) Subject: Debug server prints debug messages on client Message-ID: If a server is started in debug mode (-ddd), it triggers a few debug messages to appear on the client. Shouldn't debug messages appear on the client only if the client uses the -v option? The problem is, it's often useful to start a debug server to help track down problems without interfering with the client... and those extra client-side debug messages can sometimes cause issues for things that indirectly run ssh (like cvs and svn) if they aren't expecting the output. Is this a bug or is there a particular reason enabling debugging on the server is supposed to trigger debug messages on the client? Here's an example connection to a 5.2p1 server started with "sshd -e -D -p4242": $ ssh -p4242 127.0.0.1 'date' Wed Jun 3 11:47:05 PDT 2009 And to a 5.2p1 server started with "sshd -e -ddd -p4242": $ ssh -p4242 127.0.0.1 'date' Environment: USER=... LOGNAME=... HOME=... PATH=... MAIL=... SHELL=... SSH_CLIENT=... SSH_CONNECTION=... debug3: channel 0: close_fds r -1 w -1 e -1 c -1 Wed Jun 3 11:47:25 PDT 2009 From lrajendr at Brocade.COM Thu Jun 4 16:02:52 2009 From: lrajendr at Brocade.COM (Lalith Rajendran (CW)) Date: Thu, 4 Jun 2009 00:02:52 -0600 Subject: PasswordAuthentication fails in openssh3.7.1p1 as it does not use PAM Message-ID: All, I am an engineer working with Brocade. We recently upgraded one of our products to openssh3.7.1p1. Once we did this, the password authentication always failed while connecting through ssh. The authentication succeeds if attempted through keyboard-interactive authentication. On debugging this we found that Password authentication is not working because it doesn't Use PAM in openssh 3.7.1p1. Version UsePAM PasswordAuthentication ChallengeResponseAuthentication <=3.6.1p2 Not applicable Uses PAM Uses PAM if PAMAuthenticationViaKbdInt is enabled 3.7p1 - 3.7.1p1 Defaults to yes Does not use PAM Uses PAM if UsePAM is enabled 3.7.1p2 - 3.8.1p1 Defaults to no Does not use PAM [1] Uses PAM if UsePAM is enabled 3.9p1 Defaults to no Uses PAM if UsePAM is enabled Uses PAM if UsePAM is enabled Why was Password Authentication using PAM removed in 3.7.1p1? We need this to be supported in 3.7.1p1. Please let us know what could be done to enable this in 3.7.1p1. Thanks, Lalith From peter at stuge.se Thu Jun 4 21:58:25 2009 From: peter at stuge.se (Peter Stuge) Date: Thu, 4 Jun 2009 13:58:25 +0200 Subject: PasswordAuthentication fails in openssh3.7.1p1 as it does not use PAM In-Reply-To: References: Message-ID: <20090604115825.27149.qmail@stuge.se> Hello Lalith, Lalith Rajendran (CW) wrote: > We recently upgraded one of our products to openssh3.7.1p1. That is REALLY old software. > We need this to be supported in 3.7.1p1. I guess you have some work to do in the code then. > Please let us know what could be done to enable this in 3.7.1p1. I would suggest that you use a 5.x version of OpenSSH.. //Peter From lrajendr at Brocade.COM Thu Jun 4 23:54:22 2009 From: lrajendr at Brocade.COM (Lalith Rajendran (CW)) Date: Thu, 4 Jun 2009 07:54:22 -0600 Subject: PasswordAuthentication fails in openssh3.7.1p1 as it does notuse PAM In-Reply-To: <20090604115825.27149.qmail@stuge.se> References: <20090604115825.27149.qmail@stuge.se> Message-ID: Thanks for the information Peter. I fixed this by back porting the PAM support implementation for password-authentication from openssh 3.9 to openssh 3.7.1p1. (Bug 874 - (Re)Add PAM PasswordAuthentication support ). I am also seeing another issue after I upgraded to 3.7.1p1. If I try logging in through putty (keyboard interactive authentication), it is not prompting for password the first time. It is prompting for password only on the second attempt and only then I am able to login. ///////////////////////////////////// login as: Administrator Login: Administrator Password: ///////////////////////////////////// I searched for information regarding this problem but could not find any. Is this a known issue in openssh 3.7.1p1? Thanks, Lalith -----Original Message----- From: Peter Stuge [mailto:peter at stuge.se] Sent: Thursday, June 04, 2009 5:28 PM To: Lalith Rajendran (CW) Cc: openssh-unix-dev at mindrot.org; Gayathri Ramakrishnan (CW) Subject: Re: PasswordAuthentication fails in openssh3.7.1p1 as it does notuse PAM Hello Lalith, Lalith Rajendran (CW) wrote: > We recently upgraded one of our products to openssh3.7.1p1. That is REALLY old software. > We need this to be supported in 3.7.1p1. I guess you have some work to do in the code then. > Please let us know what could be done to enable this in 3.7.1p1. I would suggest that you use a 5.x version of OpenSSH.. //Peter From martin at oneiros.de Fri Jun 5 01:37:52 2009 From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=) Date: Thu, 4 Jun 2009 17:37:52 +0200 Subject: PasswordAuthentication fails in openssh3.7.1p1 as it does notuse PAM In-Reply-To: References: <20090604115825.27149.qmail@stuge.se> Message-ID: <68c491a60906040837j2fc549c1pe68d27a0a0b171ce@mail.gmail.com> 2009/6/4, Lalith Rajendran (CW) : > Is this a known issue in openssh 3.7.1p1? Why do you insist on using sofware that is nearly six years old and security critical? Best Martin From Dave at Yost.com Fri Jun 5 16:04:37 2009 From: Dave at Yost.com (Dave Yost) Date: Thu, 4 Jun 2009 23:04:37 -0700 Subject: ssh trouble checklist Message-ID: Hi. There should be a checklist of everything that can go wrong with making an ssh connection. Here's one entry for the list, which I didn't know before, and * I couldn't see the problem from the -ddd and -vvv output, and * there were no /var/log/* file entries to give hints. Here's what I did sudo kill /usr/sbin/sshd No good. Usually I did kill -HUP, but once I just killed sshd outright. Gotta start sshd this way: /etc/init.d/sshd start At least on Fedora 11. Below are the observed symptoms. Client side Wed 13:42:40 ip2 yost /Users/yost 254 203 Z% ssh -vvv 192.168.1.33 OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009 debug1: Reading configuration data /opt/local/etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.1.33 port 22. debug1: Connection established. debug1: identity file /Users/yost/.ssh/identity type -1 debug1: identity file /Users/yost/.ssh/id_rsa type -1 debug3: Not a RSA1 key file /Users/yost/.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 /Users/yost/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2 debug1: match: OpenSSH_5.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,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-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr 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: 120/256 debug2: bits set: 538/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/yost/.ssh/known_hosts debug3: check_host_in_hostfile: match line 38 debug3: check_host_in_hostfile: filename /Users/yost/.ssh/known_hosts debug3: check_host_in_hostfile: match line 39 debug1: Host '192.168.1.33' is known and matches the RSA host key. debug1: Found key in /Users/yost/.ssh/known_hosts:38 debug2: bits set: 502/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: /Users/yost/.ssh/identity (0x0) debug2: key: /Users/yost/.ssh/id_rsa (0x0) debug2: key: /Users/yost/.ssh/id_dsa (0x0) debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-with-mic,password 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: /Users/yost/.ssh/identity debug3: no such identity: /Users/yost/.ssh/identity debug1: Trying private key: /Users/yost/.ssh/id_rsa debug3: no such identity: /Users/yost/.ssh/id_rsa debug1: Trying private key: /Users/yost/.ssh/id_dsa debug1: read PEM private key done: type DSA debug3: sign_and_send_pubkey 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 yost at 192.168.1.33's password: debug3: packet_send2: adding 64 (len 60 padlen 4 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug2: channel 0: request shell confirm 1 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow at openssh.com reply 0 debug2: channel 0: rcvd eow debug2: channel 0: close_read debug2: channel 0: input open -> closed debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug3: PAM session not opened, exiting Last login: Wed Jun 3 13:42:40 2009 from 192.168.1.1 debug3: channel 0: will not send data after close debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 7 c -1 Connection to 192.168.1.33 closed. Transferred: sent 2208, received 2184 bytes, in 0.1 seconds Bytes per second: sent 29902.9, received 29577.9 debug1: Exit status 254 Wed 13:43:17 ip2 yost /Users/yost 254 204 Z% Server side Wed 13:42:40 192.168.1.33 root /etc 0 45 Z# /usr/sbin/sshd -ddd debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 728 debug2: parse_server_config: config /etc/ssh/sshd_config len 728 debug3: /etc/ssh/sshd_config:21 setting Protocol 2 debug3: /etc/ssh/sshd_config:36 setting SyslogFacility AUTHPRIV debug3: /etc/ssh/sshd_config:49 setting PubkeyAuthentication yes debug3: /etc/ssh/sshd_config:50 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /etc/ssh/sshd_config:65 setting PasswordAuthentication yes debug3: /etc/ssh/sshd_config:69 setting ChallengeResponseAuthentication no debug3: /etc/ssh/sshd_config:79 setting GSSAPIAuthentication yes debug3: /etc/ssh/sshd_config:81 setting GSSAPICleanupCredentials yes debug3: /etc/ssh/sshd_config:93 setting UsePAM yes debug3: /etc/ssh/sshd_config:96 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES debug3: /etc/ssh/sshd_config:97 setting AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT debug3: /etc/ssh/sshd_config:98 setting AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE debug3: /etc/ssh/sshd_config:104 setting X11Forwarding yes debug3: /etc/ssh/sshd_config:127 setting Subsystem sftp /usr/libexec/openssh/sftp-server debug3: checking syntax for 'Match User rootback' debug3: checking syntax for 'Match User root' debug3: checking syntax for 'Match (null)' debug1: sshd version OpenSSH_5.2p1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 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: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on ::. Server listening on :: port 22. debug3: fd 5 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 728 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.1.1 port 47433 debug1: Client protocol version 2.0; client software version OpenSSH_5.2 debug1: match: OpenSSH_5.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug2: fd 3 setting O_NONBLOCK debug3: privsep user:group 74:74 debug1: permanently_set_uid: 74/74 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com 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-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,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_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: Network child is on pid 430 debug3: preauth child monitor started debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 1024 8192 debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: dh_gen_key: priv key bits set: 123/256 debug2: bits set: 502/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug2: bits set: 538/1024 debug3: mm_key_sign entering debug3: mm_request_send entering: type 5 debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 6 debug3: mm_request_receive entering debug3: monitor_read: checking request 5 debug3: mm_answer_sign debug3: mm_answer_sign: signature 0x7f2a2800e7e0(271) debug3: mm_request_send entering: type 6 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: monitor_read: 5 used once, disabling now debug3: mm_request_receive entering debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user yost service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 7 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 8 debug3: mm_request_receive entering debug3: monitor_read: checking request 7 debug3: mm_answer_pwnamallow debug3: Trying to reverse map address 192.168.1.1. debug2: parse_server_config: config reprocess config len 728 debug3: checking match for 'User rootback' user yost host 192.168.1.1 addr 192.168.1.1 debug3: match not found debug3: checking match for 'User root' user yost host 192.168.1.1 addr 192.168.1.1 debug3: match not found debug3: checking match for '(null)' user yost host 192.168.1.1 addr 192.168.1.1 debug3: match found debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 8 debug2: input_userauth_request: setting up authctxt for yost debug3: mm_start_pam entering debug3: mm_request_send entering: type 46 debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug3: mm_inform_authrole entering debug3: mm_request_send entering: type 4 debug2: input_userauth_request: try method none debug2: monitor_read: 7 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 46 debug1: PAM: initializing for "yost" debug1: PAM: setting PAM_RHOST to "192.168.1.1" debug1: PAM: setting PAM_TTY to "ssh" debug2: monitor_read: 46 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 4 debug3: mm_answer_authrole: role= debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug1: userauth-request for user yost service ssh-connection method publickey debug1: attempt 1 failures 0 debug2: input_userauth_request: try method publickey debug3: mm_key_allowed entering debug3: mm_request_send entering: type 21 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 22 debug3: mm_request_receive entering debug3: monitor_read: checking request 21 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x7f2a28021f10 debug1: temporarily_use_uid: 1008/999 (e=0/0) debug1: trying public key file /home/yost/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1008/999 (e=0/0) debug1: trying public key file /home/yost/.ssh/authorized_keys debug1: restore_uid: 0/0 Failed publickey for yost from 192.168.1.1 port 47433 ssh2 debug3: mm_answer_keyallowed: key 0x7f2a28021f10 is not allowed debug3: mm_request_send entering: type 22 debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss debug3: mm_request_receive entering debug1: userauth-request for user yost service ssh-connection method password debug1: attempt 2 failures 1 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 11 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 12 debug3: mm_request_receive entering debug3: monitor_read: checking request 11 debug3: PAM: sshpam_passwd_conv called with 1 messages debug1: PAM: password authentication accepted for yost debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 12 debug3: mm_auth_password: user authenticated debug3: mm_do_pam_account entering debug3: mm_request_send entering: type 47 debug3: mm_request_receive_expect entering: type 48 debug3: mm_request_receive entering debug3: mm_request_receive_expect entering: type 47 debug3: mm_request_receive entering debug1: do_pam_account: called debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success) debug3: mm_request_send entering: type 48 debug3: mm_do_pam_account returning 1 debug3: mm_send_keystate: Sending new keys: 0x7f2a280171d0 0x7f2a2800f540 debug3: mm_newkeys_to_blob: converting 0x7f2a280171d0 debug3: mm_newkeys_to_blob: converting 0x7f2a2800f540 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 25 debug3: mm_send_keystate: Finished sending state Accepted password for yost from 192.168.1.1 port 47433 ssh2 debug1: monitor_child_preauth: yost has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 25 debug3: mm_request_receive entering debug3: mm_newkeys_from_blob: 0x7f2a280233f0(122) debug2: mac_setup: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x7f2a280233f0(122) debug2: mac_setup: found hmac-md5 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug1: temporarily_use_uid: 1008/999 (e=0/0) debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism debug1: restore_uid: 0/0 debug1: SELinux support enabled debug3: ssh_selinux_setup_pam_variables: setting execution context debug1: PAM: establishing credentials debug3: PAM: opening session debug3: PAM: sshpam_store_conv called with 1 messages PAM: pam_open_session(): Authentication failure debug1: PAM: establishing credentials debug1: permanently_set_uid: 1008/999 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 6 setting O_NONBLOCK debug2: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 User child is on pid 433 debug3: mm_request_receive entering debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug3: mm_request_send entering: type 26 debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY debug3: mm_request_receive_expect entering: type 27 debug3: mm_request_receive entering debug3: monitor_read: checking request 26 debug3: mm_answer_pty entering debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug3: ssh_selinux_setup_pty: setting TTY context on /dev/pts/2 ssh_selinux_setup_pty: security_compute_relabel: Invalid argument debug3: ssh_selinux_setup_pty: done debug3: mm_request_send entering: type 27 debug1: session_pty_req: session 0 alloc /dev/pts/2 debug1: Ignoring unsupported tty mode opcode 11 (0xb) debug1: Ignoring unsupported tty mode opcode 17 (0x11) debug1: server_input_channel_req: channel 0 request shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: Setting controlling tty using TIOCSCTTY. debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 5 debug3: mm_request_receive entering debug2: fd 3 setting TCP_NODELAY debug2: channel 0: rfd 10 isatty debug2: fd 10 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug2: notify_done: reading debug1: Received SIGCHLD. debug1: session_by_pid: pid 434 debug1: session_exit_message: session 0 channel 0 pid 434 debug2: channel 0: request exit-status confirm 0 debug1: session_exit_message: release channel 0 debug2: channel 0: write failed debug2: channel 0: close_write debug2: channel 0: send eow debug2: channel 0: output open -> closed debug3: mm_request_send entering: type 28 debug3: monitor_read: checking request 28 debug3: mm_answer_pty_cleanup entering debug1: session_by_tty: session 0 tty /dev/pts/2 debug3: mm_session_close: session 0 pid 433 debug3: mm_session_close: tty /dev/pts/2 ptyfd 5 debug1: session_pty_cleanup: session 0 release /dev/pts/2 debug3: session_unused: session id 0 unused debug3: mm_request_receive entering debug2: channel 0: read<=0 rfd 10 len -1 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 debug2: channel 0: send close debug3: channel 0: will not send data after close debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: is dead debug2: channel 0: gc: notify user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug3: session_unused: session id 0 unused debug2: channel 0: gc: user detached debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: server-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e -1 c -1 Connection closed by 192.168.1.1 debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering Transferred: sent 2184, received 2208 bytes Closing connection to 192.168.1.1 port 47433 debug3: mm_request_send entering: type 59 debug3: monitor_read: checking request 59 debug3: mm_answer_term: tearing down sessions debug1: PAM: cleanup debug1: PAM: deleting credentials Wed 13:43:17 192.168.1.33 root /etc 0 46 Z# From Dave at Yost.com Fri Jun 5 16:04:27 2009 From: Dave at Yost.com (Dave Yost) Date: Thu, 4 Jun 2009 23:04:27 -0700 Subject: ssh trouble checklist Message-ID: Hi. There should be a checklist of everything that can go wrong with making an ssh connection. Here's one entry for the list, which I didn't know before, and * I couldn't see the problem from the -ddd and -vvv output, and * there were no /var/log/* file entries to give hints. Here's what I did sudo kill /usr/sbin/sshd No good. Usually I did kill -HUP, but once I just killed sshd outright. Gotta start sshd this way: /etc/init.d/sshd start At least on Fedora 11. Below are the observed symptoms. Client side Wed 13:42:40 ip2 yost /Users/yost 254 203 Z% ssh -vvv 192.168.1.33 OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009 debug1: Reading configuration data /opt/local/etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.1.33 port 22. debug1: Connection established. debug1: identity file /Users/yost/.ssh/identity type -1 debug1: identity file /Users/yost/.ssh/id_rsa type -1 debug3: Not a RSA1 key file /Users/yost/.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 /Users/yost/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2 debug1: match: OpenSSH_5.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,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-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr 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: 120/256 debug2: bits set: 538/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/yost/.ssh/known_hosts debug3: check_host_in_hostfile: match line 38 debug3: check_host_in_hostfile: filename /Users/yost/.ssh/known_hosts debug3: check_host_in_hostfile: match line 39 debug1: Host '192.168.1.33' is known and matches the RSA host key. debug1: Found key in /Users/yost/.ssh/known_hosts:38 debug2: bits set: 502/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: /Users/yost/.ssh/identity (0x0) debug2: key: /Users/yost/.ssh/id_rsa (0x0) debug2: key: /Users/yost/.ssh/id_dsa (0x0) debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-with-mic,password 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: /Users/yost/.ssh/identity debug3: no such identity: /Users/yost/.ssh/identity debug1: Trying private key: /Users/yost/.ssh/id_rsa debug3: no such identity: /Users/yost/.ssh/id_rsa debug1: Trying private key: /Users/yost/.ssh/id_dsa debug1: read PEM private key done: type DSA debug3: sign_and_send_pubkey 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 yost at 192.168.1.33's password: debug3: packet_send2: adding 64 (len 60 padlen 4 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug2: channel 0: request shell confirm 1 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow at openssh.com reply 0 debug2: channel 0: rcvd eow debug2: channel 0: close_read debug2: channel 0: input open -> closed debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug3: PAM session not opened, exiting Last login: Wed Jun 3 13:42:40 2009 from 192.168.1.1 debug3: channel 0: will not send data after close debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 7 c -1 Connection to 192.168.1.33 closed. Transferred: sent 2208, received 2184 bytes, in 0.1 seconds Bytes per second: sent 29902.9, received 29577.9 debug1: Exit status 254 Wed 13:43:17 ip2 yost /Users/yost 254 204 Z% Server side Wed 13:42:40 192.168.1.33 root /etc 0 45 Z# /usr/sbin/sshd -ddd debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 728 debug2: parse_server_config: config /etc/ssh/sshd_config len 728 debug3: /etc/ssh/sshd_config:21 setting Protocol 2 debug3: /etc/ssh/sshd_config:36 setting SyslogFacility AUTHPRIV debug3: /etc/ssh/sshd_config:49 setting PubkeyAuthentication yes debug3: /etc/ssh/sshd_config:50 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /etc/ssh/sshd_config:65 setting PasswordAuthentication yes debug3: /etc/ssh/sshd_config:69 setting ChallengeResponseAuthentication no debug3: /etc/ssh/sshd_config:79 setting GSSAPIAuthentication yes debug3: /etc/ssh/sshd_config:81 setting GSSAPICleanupCredentials yes debug3: /etc/ssh/sshd_config:93 setting UsePAM yes debug3: /etc/ssh/sshd_config:96 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES debug3: /etc/ssh/sshd_config:97 setting AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT debug3: /etc/ssh/sshd_config:98 setting AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE debug3: /etc/ssh/sshd_config:104 setting X11Forwarding yes debug3: /etc/ssh/sshd_config:127 setting Subsystem sftp /usr/libexec/openssh/sftp-server debug3: checking syntax for 'Match User rootback' debug3: checking syntax for 'Match User root' debug3: checking syntax for 'Match (null)' debug1: sshd version OpenSSH_5.2p1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 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: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on ::. Server listening on :: port 22. debug3: fd 5 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 728 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.1.1 port 47433 debug1: Client protocol version 2.0; client software version OpenSSH_5.2 debug1: match: OpenSSH_5.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug2: fd 3 setting O_NONBLOCK debug3: privsep user:group 74:74 debug1: permanently_set_uid: 74/74 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com 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-sha256,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,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_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: Network child is on pid 430 debug3: preauth child monitor started debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 1024 8192 debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: dh_gen_key: priv key bits set: 123/256 debug2: bits set: 502/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug2: bits set: 538/1024 debug3: mm_key_sign entering debug3: mm_request_send entering: type 5 debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 6 debug3: mm_request_receive entering debug3: monitor_read: checking request 5 debug3: mm_answer_sign debug3: mm_answer_sign: signature 0x7f2a2800e7e0(271) debug3: mm_request_send entering: type 6 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: monitor_read: 5 used once, disabling now debug3: mm_request_receive entering debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user yost service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 7 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 8 debug3: mm_request_receive entering debug3: monitor_read: checking request 7 debug3: mm_answer_pwnamallow debug3: Trying to reverse map address 192.168.1.1. debug2: parse_server_config: config reprocess config len 728 debug3: checking match for 'User rootback' user yost host 192.168.1.1 addr 192.168.1.1 debug3: match not found debug3: checking match for 'User root' user yost host 192.168.1.1 addr 192.168.1.1 debug3: match not found debug3: checking match for '(null)' user yost host 192.168.1.1 addr 192.168.1.1 debug3: match found debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 8 debug2: input_userauth_request: setting up authctxt for yost debug3: mm_start_pam entering debug3: mm_request_send entering: type 46 debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug3: mm_inform_authrole entering debug3: mm_request_send entering: type 4 debug2: input_userauth_request: try method none debug2: monitor_read: 7 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 46 debug1: PAM: initializing for "yost" debug1: PAM: setting PAM_RHOST to "192.168.1.1" debug1: PAM: setting PAM_TTY to "ssh" debug2: monitor_read: 46 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 4 debug3: mm_answer_authrole: role= debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug1: userauth-request for user yost service ssh-connection method publickey debug1: attempt 1 failures 0 debug2: input_userauth_request: try method publickey debug3: mm_key_allowed entering debug3: mm_request_send entering: type 21 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 22 debug3: mm_request_receive entering debug3: monitor_read: checking request 21 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x7f2a28021f10 debug1: temporarily_use_uid: 1008/999 (e=0/0) debug1: trying public key file /home/yost/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1008/999 (e=0/0) debug1: trying public key file /home/yost/.ssh/authorized_keys debug1: restore_uid: 0/0 Failed publickey for yost from 192.168.1.1 port 47433 ssh2 debug3: mm_answer_keyallowed: key 0x7f2a28021f10 is not allowed debug3: mm_request_send entering: type 22 debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss debug3: mm_request_receive entering debug1: userauth-request for user yost service ssh-connection method password debug1: attempt 2 failures 1 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 11 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 12 debug3: mm_request_receive entering debug3: monitor_read: checking request 11 debug3: PAM: sshpam_passwd_conv called with 1 messages debug1: PAM: password authentication accepted for yost debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 12 debug3: mm_auth_password: user authenticated debug3: mm_do_pam_account entering debug3: mm_request_send entering: type 47 debug3: mm_request_receive_expect entering: type 48 debug3: mm_request_receive entering debug3: mm_request_receive_expect entering: type 47 debug3: mm_request_receive entering debug1: do_pam_account: called debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success) debug3: mm_request_send entering: type 48 debug3: mm_do_pam_account returning 1 debug3: mm_send_keystate: Sending new keys: 0x7f2a280171d0 0x7f2a2800f540 debug3: mm_newkeys_to_blob: converting 0x7f2a280171d0 debug3: mm_newkeys_to_blob: converting 0x7f2a2800f540 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 25 debug3: mm_send_keystate: Finished sending state Accepted password for yost from 192.168.1.1 port 47433 ssh2 debug1: monitor_child_preauth: yost has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 25 debug3: mm_request_receive entering debug3: mm_newkeys_from_blob: 0x7f2a280233f0(122) debug2: mac_setup: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x7f2a280233f0(122) debug2: mac_setup: found hmac-md5 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug1: temporarily_use_uid: 1008/999 (e=0/0) debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism debug1: restore_uid: 0/0 debug1: SELinux support enabled debug3: ssh_selinux_setup_pam_variables: setting execution context debug1: PAM: establishing credentials debug3: PAM: opening session debug3: PAM: sshpam_store_conv called with 1 messages PAM: pam_open_session(): Authentication failure debug1: PAM: establishing credentials debug1: permanently_set_uid: 1008/999 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 6 setting O_NONBLOCK debug2: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 User child is on pid 433 debug3: mm_request_receive entering debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug3: mm_request_send entering: type 26 debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY debug3: mm_request_receive_expect entering: type 27 debug3: mm_request_receive entering debug3: monitor_read: checking request 26 debug3: mm_answer_pty entering debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug3: ssh_selinux_setup_pty: setting TTY context on /dev/pts/2 ssh_selinux_setup_pty: security_compute_relabel: Invalid argument debug3: ssh_selinux_setup_pty: done debug3: mm_request_send entering: type 27 debug1: session_pty_req: session 0 alloc /dev/pts/2 debug1: Ignoring unsupported tty mode opcode 11 (0xb) debug1: Ignoring unsupported tty mode opcode 17 (0x11) debug1: server_input_channel_req: channel 0 request shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: Setting controlling tty using TIOCSCTTY. debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 5 debug3: mm_request_receive entering debug2: fd 3 setting TCP_NODELAY debug2: channel 0: rfd 10 isatty debug2: fd 10 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug2: notify_done: reading debug1: Received SIGCHLD. debug1: session_by_pid: pid 434 debug1: session_exit_message: session 0 channel 0 pid 434 debug2: channel 0: request exit-status confirm 0 debug1: session_exit_message: release channel 0 debug2: channel 0: write failed debug2: channel 0: close_write debug2: channel 0: send eow debug2: channel 0: output open -> closed debug3: mm_request_send entering: type 28 debug3: monitor_read: checking request 28 debug3: mm_answer_pty_cleanup entering debug1: session_by_tty: session 0 tty /dev/pts/2 debug3: mm_session_close: session 0 pid 433 debug3: mm_session_close: tty /dev/pts/2 ptyfd 5 debug1: session_pty_cleanup: session 0 release /dev/pts/2 debug3: session_unused: session id 0 unused debug3: mm_request_receive entering debug2: channel 0: read<=0 rfd 10 len -1 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 debug2: channel 0: send close debug3: channel 0: will not send data after close debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: is dead debug2: channel 0: gc: notify user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug3: session_unused: session id 0 unused debug2: channel 0: gc: user detached debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: server-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e -1 c -1 Connection closed by 192.168.1.1 debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering Transferred: sent 2184, received 2208 bytes Closing connection to 192.168.1.1 port 47433 debug3: mm_request_send entering: type 59 debug3: monitor_read: checking request 59 debug3: mm_answer_term: tearing down sessions debug1: PAM: cleanup debug1: PAM: deleting credentials Wed 13:43:17 192.168.1.33 root /etc 0 46 Z# From jmknoble at pobox.com Sat Jun 6 09:24:30 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 5 Jun 2009 19:24:30 -0400 Subject: ssh trouble checklist In-Reply-To: References: Message-ID: <20090605232430.GB8048@crawfish.ais.com> On 2009-06-05 02:04, Dave Yost wrote: : There should be a checklist of everything that can go wrong with : making an ssh connection. : : Here's one entry for the list, which I didn't know before, and : * I couldn't see the problem from the -ddd and -vvv output, and : * there were no /var/log/* file entries to give hints. : : Here's what I did : sudo kill : /usr/sbin/sshd Surely that should at least be 'sudo /usr/sbin/sshd', so that sshd has privileges to listen on low-numbered ports and change UID, but see below. : No good. : : Usually I did kill -HUP, but once I just killed sshd outright. : : Gotta start sshd this way: : /etc/init.d/sshd start : : At least on Fedora 11. [...] Recent Fedoras, as well as RHEL v5 and CentOS v5, often have SELinux enabled, which requires that security contexts are set up properly. The initscript will do that, but merely running sshd from the command won't. Also, Fedora/RedHat and cousins have /sbin/service which does a little bit more to set up an environment for daemons to run in (e.g., 'cd /' and clearing some environment). Best is (as root): /sbin/service sshd start on those platforms. -- 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) From Dave at Yost.com Sat Jun 6 10:03:25 2009 From: Dave at Yost.com (Dave Yost) Date: Fri, 5 Jun 2009 17:03:25 -0700 Subject: ssh trouble checklist In-Reply-To: <20090605232430.GB8048@crawfish.ais.com> References: <20090605232430.GB8048@crawfish.ais.com> Message-ID: At 7:24 PM -0400 2009-06-05, Jim Knoble wrote: >On 2009-06-05 02:04, Dave Yost wrote: > >: There should be a checklist of everything that can go wrong with >: making an ssh connection. >: >: Here's one entry for the list, which I didn't know before, and >: * I couldn't see the problem from the -ddd and -vvv output, and >: * there were no /var/log/* file entries to give hints. >: >: Here's what I did >: sudo kill >: /usr/sbin/sshd > >Surely that should at least be 'sudo /usr/sbin/sshd', that's what I meant >so that sshd has >privileges to listen on low-numbered ports and change UID, but see >below. > >: No good. >: >: Usually I did kill -HUP, but once I just killed sshd outright. >: >: Gotta start sshd this way: >: /etc/init.d/sshd start >: >: At least on Fedora 11. > [...] > >Recent Fedoras, as well as RHEL v5 and CentOS v5, often have SELinux >enabled, which requires that security contexts are set up properly. The >initscript will do that, but merely running sshd from the command won't. what I figured. >Also, Fedora/RedHat and cousins have /sbin/service which does a little >bit more to set up an environment for daemons to run in (e.g., 'cd /' >and clearing some environment). Best is (as root): > > /sbin/service sshd start > >on those platforms. Thanks! Hope to see all this wisdom on the openssh web site someday. > >-- >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) From jmknoble at pobox.com Sun Jun 7 08:37:45 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Sat, 6 Jun 2009 18:37:45 -0400 Subject: ssh trouble checklist In-Reply-To: References: <20090605232430.GB8048@crawfish.ais.com> Message-ID: <20090606223745.GC8048@crawfish.ais.com> On 2009-06-05 20:03, Dave Yost wrote: : At 7:24 PM -0400 2009-06-05, Jim Knoble wrote: : >Recent Fedoras, as well as RHEL v5 and CentOS v5, often have SELinux : >enabled, which requires that security contexts are set up properly. The : >initscript will do that, but merely running sshd from the command won't. [...] : >Also, Fedora/RedHat and cousins have /sbin/service which does a little : >bit more to set up an environment for daemons to run in (e.g., 'cd /' : >and clearing some environment). Best is (as root): : > : > /sbin/service sshd start : : Thanks! Hope to see all this wisdom on the openssh web site someday. The wisdom really should be in the Fedora/RHEL/CentOS documentation, rather than on the OpenSSH website. The OpenSSH maintainers can't possibly investigate and keep up with all the customizations and constraints that operating system developers put in their custom-built OpenSSH packages. Both RHEL and CentOS have excellent documentation, and Fedora is doing a good job of putting theirs together. Other Linux distros have comparable documentation. Note that this problem is not unique to those Linux distros either, or even to Linux. Pretty much every OS has its own "service framework", and someone starting services with admin privileges really should consult OS documentation (or, where necessary and available, source code) if they're unfamiliar with the idiosyncrasies of the system, in my opinion. Best, jim -- 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) From kunwins at uplooking.com Sun Jun 7 18:16:34 2009 From: kunwins at uplooking.com (Terry Tsang) Date: Sun, 7 Jun 2009 16:16:34 +0800 Subject: Fw: howto use chroot + sshd Message-ID: <003601c9e748$45a320b0$0901010a@laptop> Hi everybody. I got a problem here. I want to use chroot + sshd service. env: RHEL 5.2 tail -1 /etc/pam.d/sshd session required pam_chroot.so debug tail /etc/security/chroot.conf terry /users ssh terry at 192.168.20.11 faile tail /var/log/secure Jun 7 05:05:40 node1 sshd[5397]: pam_chroot(sshd:session): chroot(/users) succeeded <- chroot /users succeeded Jun 6 21:05:40 node1 sshd[5397]: pam_unix(sshd:session): session closed for user terry Jun 6 21:05:40 node1 sshd[5399]: pam_env(sshd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory Jun 6 21:05:40 node1 sshd[5397]: syslogin_perform_logout: logout() returned an error Jun 6 21:05:40 node1 sshd[5397]: fatal: openpty returns device for which ttyname fails. <- but why can not get one tty shell ? Jun 6 21:05:40 node1 sshd[5397]: error: chown 0 0 failed: No such file or directory Jun 6 21:05:40 node1 sshd[5397]: error: chmod 0666 failed: No such file or directory ls -l /users/dev/ total 0 srw-rw-rw- 1 terry root 0 Jun 7 04:56 log crw-rw-rw- 1 terry root 1, 3 Jun 7 04:04 null crw-rw-rw- 1 terry root 5, 2 Jun 7 04:58 ptmx drwxrwxrwx 2 terry terry 0 Jun 7 04:55 pts crw-rw-rw- 1 terry root 5, 0 Jun 7 04:31 tty crw-r--r-- 1 terry root 1, 9 Jun 7 04:31 urandom crw-rw-rw- 1 terry root 1, 12 Jun 7 04:31 zero ls -l /user/dev/pts <- empty mount devpts on /users/dev/pts type devpts (rw,uid=500,gid=5,mode=666) but use command " ssh terry at 192.168.20.11 bash -i " I can log into system . .but something wrong , scp command means unknow user 500. please give me advances. thank you very much. Best Regards Terry Tsang. From djm at mindrot.org Mon Jun 8 18:57:17 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 8 Jun 2009 18:57:17 +1000 (EST) Subject: Fw: howto use chroot + sshd In-Reply-To: <003601c9e748$45a320b0$0901010a@laptop> References: <003601c9e748$45a320b0$0901010a@laptop> Message-ID: On Sun, 7 Jun 2009, Terry Tsang wrote: > > > Hi everybody. > I got a problem here. > > I want to use chroot + sshd service. > env: > RHEL 5.2 > > tail -1 /etc/pam.d/sshd > session required pam_chroot.so debug OpenSSH doesn't support pam_chroot. Use the sshd_config ChrootDirectory option instead (requires a recent OpenSSH). -d From isono at cray.com Tue Jun 9 16:55:23 2009 From: isono at cray.com (Satoshi Isono) Date: Tue, 9 Jun 2009 01:55:23 -0500 Subject: How to keep gid status Message-ID: <925346A443D4E340BEB20248BAFCDBDF0B4A5F49@CFEVS1-IP.americas.cray.com> Dear all, I would like to know how to keep primary gid status when using ssh command. We know that, with sg command in ssh command line, it is successful in this case. If there is the setting on sshd, I want to know the way. Can you please advise me. I show a example as below. $ id uid=1002(taro) gid=1002(suzuki) groups=10(wheel),1002(suzuki),8001(tanaka) $ newgrp tanaka $ id uid=1002(taro) gid=8001(tanaka) groups=10(wheel),1002(suzuki),8001(tanaka) $ ssh remote-host id uid=1002(taro) gid=1002(suzuki) groups=10(wheel),1002(suzuki),8001(tanaka) $ ssh remote-host "sg tanaka id" uid=1002(taro) gid=8001(tanaka) groups=10(wheel),1002(suzuki),8001(tanaka) Regards, Satoshi Isono From martin at schimandl.at Tue Jun 9 21:08:35 2009 From: martin at schimandl.at (Martin Schimandl) Date: Tue, 09 Jun 2009 13:08:35 +0200 Subject: Match Statement in sshd_config Message-ID: <4A2E42B3.8090207@schimandl.at> Hello Portable OpenSSH Team! I recently read the man-page of sshd and found: The Match-Statement. Which maybe could solve the problem i have. (Get freeNX running on my UbuntuBox and connect to it with the Windows-Client just using PublicKey Authentication ) But unfortunately the documentation of the Match-Statement refers to the PATTERN section, which is non existent :-( After a little bit of research on the internet i found this: http://securepoint.com/lists/html/OpenSSH/2006-11/msg00076.html So when could we expect this feature to be implemented in OpenSSH or an updated man-page? :-) Greetings from Vienna in Austria, Martin Schimandl From dkg at fifthhorseman.net Tue Jun 9 23:26:59 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 09 Jun 2009 09:26:59 -0400 Subject: Match Statement in sshd_config In-Reply-To: <4A2E42B3.8090207@schimandl.at> References: <4A2E42B3.8090207@schimandl.at> Message-ID: <4A2E6323.4040804@fifthhorseman.net> On 06/09/2009 07:08 AM, Martin Schimandl wrote: > But unfortunately the documentation of the Match-Statement refers to the > PATTERN section, which is non existent :-( I think it refers to PATTERNS (not PATTERN), and it seems to refer to ssh_config(5), not sshd_config(5). What version of openSSH are you using? With OpenSSH 5.1p1 (from debian testing), it looks like the section is available in the referenced man page: >> 0 dkg at pip:~$ man sshd_config | grep -C2 criteria >> hmac-ripemd160,hmac-sha1-96,hmac-md5-96 >> >> Match Introduces a conditional block. If all of the criteria on the >> Match line are satisfied, the keywords on the following lines >> override those set in the global section of the config file, >> until either another Match line or the end of the file. >> >> The arguments to Match are one or more criteria-pattern pairs. >> The available criteria are User, Group, Host, and Address. The >> match patterns may consist of single entries or comma-separated >> lists and may use the wildcard and negation operators described >> in the PATTERNS section of ssh_config(5). >> >> The patterns in an Address criteria may additionally contain >> addresses to match in CIDR address/masklen format, e.g. >> ?192.0.2.0/24? or ?3ffe:ffff::/32?. Note that the mask length >> 0 dkg at pip:~$ man ssh_config | grep -A3 ^PATTERNS >> PATTERNS >> A pattern consists of zero or more non-whitespace characters, ?*? (a >> wildcard that matches zero or more characters), or ??? (a wildcard that >> matches exactly one character). For example, to specify a set of decla? >> 0 dkg at pip:~$ Have you tried looking in ssh_config(5) instead of sshd_config(5) ? hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From adrya1984 at gmail.com Fri Jun 12 16:32:25 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Fri, 12 Jun 2009 09:32:25 +0300 Subject: Restrict port forwarding on server Message-ID: <496c8fcc0906112332u654d4fa2ie97b2c251664766e@mail.gmail.com> Hi, Is there a way to restrict port forwarding on the server? I want only port 8080 on the server to be available to clients. Example when i give this command clients should be able to connect: ssh -L 30300:localhost:8080 .... When i give this for example clients should not be able to connect: ssh -L 30300:localhost:4040 .... I tried this option in config file of server: PermitOpen localhost:8080 but even with it i could still connect to 4040 for example Thanks, Adriana From dtucker at zip.com.au Fri Jun 12 17:17:06 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 12 Jun 2009 17:17:06 +1000 Subject: Restrict port forwarding on server In-Reply-To: <496c8fcc0906112332u654d4fa2ie97b2c251664766e@mail.gmail.com> References: <496c8fcc0906112332u654d4fa2ie97b2c251664766e@mail.gmail.com> Message-ID: <4A3200F2.3050801@zip.com.au> Adriana Rodean wrote: > Hi, > > Is there a way to restrict port forwarding on the server? > I want only port 8080 on the server to be available to clients. > > Example when i give this command clients should be able to connect: > ssh -L 30300:localhost:8080 .... > When i give this for example clients should not be able to connect: > ssh -L 30300:localhost:4040 .... > > I tried this option in config file of server: > PermitOpen localhost:8080 > but even with it i could still connect to 4040 for example That should work. Which config file did you change? It should go in sshd_config and you need to restart sshd when you change that file. -- 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 Sat Jun 13 00:34:48 2009 From: karlis.repsons at gmail.com (=?utf-8?q?K=C4=81rlis_Repsons?=) Date: Fri, 12 Jun 2009 14:34:48 +0000 Subject: can you stop the trouble with file masks and default permissions? Message-ID: <200906121434.48149.Karlis.Repsons@gmail.com> Hello! Please take a look at this problem: 1. at sshd_config: Subsystem sftp internal-sftp Match group sftponly ? ? ? ? ?ChrootDirectory /public ? ? ? ? ?X11Forwarding no ? ? ? ? ?AllowTcpForwarding no ? ? ? ? ?ForceCommand internal-sftp 2. at client's bash: sshfs server:/ /home/kr/krpub-mount -o uid=$(id -u kr) -o gid=$(id -g kr) -o allow_other -o default_permissions -o reconnect -o no_check_root -o umask=0002 touch /home/kr/krpub-mount/writeable_dir/1 ls -la /home/kr/krpub-mount/writeable_dir/1 -rwxrwxr-x 1 kr kr 0 2009-06-12 08:51 krpub-mount/writeable_dir/1 3. at server: ls -la /public/writeable_dir/1 -rw------- 1 kr kr 0 2009-06-12 08:51 1 Removing " -o umask=0002" just shows the actual, too strict permissions. Its ok with the umask at client. And here is the trouble. How can those permissions be controlled on server, if internal-sftp is used with ChrootDirectory? If there was a way to set minimum permissions in sshd_config for newly created files, it would solve a problem with konqueror, which is eating up the group write bit and causes much of pain. Any ideas? Regards, K?rlis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From saify37 at hotmail.com Sat Jun 13 14:37:08 2009 From: saify37 at hotmail.com (Tauseef Afzal) Date: Sat, 13 Jun 2009 10:37:08 +0600 Subject: Restrict port forwarding on server In-Reply-To: <4A3200F2.3050801@zip.com.au> References: <496c8fcc0906112332u654d4fa2ie97b2c251664766e@mail.gmail.com> <4A3200F2.3050801@zip.com.au> Message-ID: hey Adriana, you can also restrict port forwarding by using iptables, as when iptables service is started it blocks all ports except the ones which are defined in its configuration file which is located at /etc/sysconfig/iptables in Red Hat/Centos systems, to open a specific port through iptables firewall, you have to add a line which looks like -A RH-Firewall-1-INPUT -m state --state NEW -p tcp -m tcp --dport 8080 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -p udp -m udp --dport 8080 -j ACCEPT you have to make configuration of your own for this, the above two lines will open the port 8080 for tcp and udp traffic, figure out the ports which you want to be opened and define them in the iptables file, if you want to read more about this, follow the link http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables ------------------------------------------------------------------------------------ > Date: Fri, 12 Jun 2009 17:17:06 +1000 > From: dtucker at zip.com.au > To: adrya1984 at gmail.com > CC: openssh-unix-dev at mindrot.org; secureshell at securityfocus.com > Subject: Re: Restrict port forwarding on server > > Adriana Rodean wrote: > > Hi, > > > > Is there a way to restrict port forwarding on the server? > > I want only port 8080 on the server to be available to clients. > > > > Example when i give this command clients should be able to connect: > > ssh -L 30300:localhost:8080 .... > > When i give this for example clients should not be able to connect: > > ssh -L 30300:localhost:4040 .... > > > > I tried this option in config file of server: > > PermitOpen localhost:8080 > > but even with it i could still connect to 4040 for example > > That should work. > > Which config file did you change? It should go in sshd_config and you > need to restart sshd when you change that file. > > -- > 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. _________________________________________________________________ Windows Live?: Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From armin at xos.net Sun Jun 14 05:18:59 2009 From: armin at xos.net (Armin Obersteiner) Date: Sat, 13 Jun 2009 21:18:59 +0200 Subject: openssh sftp chroot /bin/false Message-ID: <20090613191859.GA5983@elch.elche> hi! i need ssh users and sftp users on my server. they don't mix so sftp users have a /bin/false as their shell. however when i try a ssh connect to such a user. he does not get disconnected but hangs forever. can it be that sshd searches foer /bin/false in the chroot environment? but i tried to place it there including ldd requirements. no success. i just want sftp users to get no shell and also no hanging connections... sftp works right now. thanks! --------------------------------------- Protocol 2 PermitRootLogin without-password ChallengeResponseAuthentication=no UsePAM yes X11Forwarding yes PrintMotd no PrintLastLog no Subsystem sftp internal-sftp Match Group sftponly ChrootDirectory %h ForceCommand internal-sftp X11Forwarding no AllowTcpForwarding no --------------------------------------- using OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009 example user: test:x:1012:1009::/home/test:/bin/false maybe a new option: DisconnectOnShell yes would help. Ciao, Armin -- armin at xos.net pgp public key on request CU From jonhson.ian at gmail.com Tue Jun 16 17:13:44 2009 From: jonhson.ian at gmail.com (Ian jonhson) Date: Tue, 16 Jun 2009 15:13:44 +0800 Subject: support of openSSH + Certificates In-Reply-To: <34BAE4FA891DCA498C6D46840F4F896F0E8ADB@BLR-SJP-MBX01.wipro.com> References: <34BAE4FA891DCA498C6D46840F4F896F0E8ADB@BLR-SJP-MBX01.wipro.com> Message-ID: <8f34198c0906160013l4fe3bc72gfdbf511677cdf657@mail.gmail.com> > We want to use openSSH for one of our project. But we need certificate exchange support. I have gone through the documentation. It says openSSH support key management but no mention of certificates. I have seen some people outside openSSH giving patches for supporting X.509 but not sure how stable are those patches. > > Is there a way that openSSH support certificates? Your guidance will help a lot. > The OpenSSH in XtreemOS project (www.xtreemos.org) has been extended to support X509 certificates (also including the SSO via extended ForwardAgent mechanism). In its functionalities, certificate verification is first step to do authentication, and traditional authentication mechanisms are following. XtreemOS is open source, you can download what you need. Best Regards, Ian From Dave at Yost.com Wed Jun 17 08:32:59 2009 From: Dave at Yost.com (Dave Yost) Date: Tue, 16 Jun 2009 15:32:59 -0700 Subject: there should be an authorized_keys(5) man page Message-ID: Hi. On http://openssh.org/manual.html I think there should be authorized_keys(5) known_hosts(5) Can an authorized_keys entry say something like from=192.168.1.32,192.168.1.33 command=/bin/foo ... or do I need to make a separate entry for each IP address? Thanks Dave From imorgan at nas.nasa.gov Thu Jun 18 06:38:12 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 17 Jun 2009 13:38:12 -0700 Subject: there should be an authorized_keys(5) man page In-Reply-To: References: Message-ID: <20090617203812.GA29390@linux55.nas.nasa.gov> On Tue, Jun 16, 2009 at 17:32:59 -0500, Dave Yost wrote: > Hi. > > On > http://openssh.org/manual.html > I think there should be > authorized_keys(5) > known_hosts(5) I agree that an authorized_keys(5) man page would be nice. I was going to file it as an enhancement request and then got distracted. > > Can an authorized_keys entry say something like > > from=192.168.1.32,192.168.1.33 command=/bin/foo ... Your almost have the right syntax: from="192.168.1.32,192.168.1.33",command="/bin/foo" ... > > or do I need to make a separate entry for each IP address? > > Thanks > > Dave -- Iain Morgan From adrya1984 at gmail.com Thu Jun 18 18:29:29 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Thu, 18 Jun 2009 11:29:29 +0300 Subject: Convert pem key to ssh-rsa format Message-ID: <496c8fcc0906180129n6e2042d7p2cef1dbdf3e7fddb@mail.gmail.com> Hi I have a certificate in der format, from it with this command i generate a public key: openssl x509 -inform der -in ejbcacert.cer -noout -pubkey > pub1key.pub result is this: -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7vbqajDw4o6gJy8UtmIbkcpnk O3Kwc4qsEnSZp/TR+fQi62F79RHWmwKOtFmwteURgLbj7D/WGuNLGOfa/2vse3G2 eHnHl5CB8ruRX9fBl/KgwCVr2JaEuUm66bBQeP5XeBotdR4cvX38uPYivCDdPjJ1 QWPdspTBKcxeFbccDwIDAQAB -----END PUBLIC KEY----- How can i obtain a public key like this? Either from certificate or from this public key? ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC7vbqajDw4o6gJy8UtmIbkcpnkO3Kwc4qsEnSZp/TR+fQi62F79RHWmwKOtFmwteURgLbj7D/WGuNLGOfa/2vse3G2eHnHl5CB8ruRX9fBl/KgwCVr2JaEuUm66bBQeP5XeBotdR4cvX38uPYivCDdPjJ1QWPdspTBKcxeFbccDw== This was obtained with this command: ssh-keygen -y -f private_key1.pem > public_key1.pub Need some help please... Thanks, Adriana From djm at mindrot.org Fri Jun 19 19:52:32 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 19 Jun 2009 19:52:32 +1000 (EST) Subject: Convert pem key to ssh-rsa format In-Reply-To: <496c8fcc0906180129n6e2042d7p2cef1dbdf3e7fddb@mail.gmail.com> References: <496c8fcc0906180129n6e2042d7p2cef1dbdf3e7fddb@mail.gmail.com> Message-ID: On Thu, 18 Jun 2009, Adriana Rodean wrote: > Hi > > I have a certificate in der format, from it with this command i > generate a public key: > > openssl x509 -inform der -in ejbcacert.cer -noout -pubkey > pub1key.pub > > result is this: > > -----BEGIN PUBLIC KEY----- > MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7vbqajDw4o6gJy8UtmIbkcpnk > O3Kwc4qsEnSZp/TR+fQi62F79RHWmwKOtFmwteURgLbj7D/WGuNLGOfa/2vse3G2 > eHnHl5CB8ruRX9fBl/KgwCVr2JaEuUm66bBQeP5XeBotdR4cvX38uPYivCDdPjJ1 > QWPdspTBKcxeFbccDwIDAQAB > -----END PUBLIC KEY----- > > How can i obtain a public key like this? Either from certificate or > from this public key? I'm not sure of what you are after: an OpenSSH public key, a PEM public key or something else? You can extract a PEM public key from an OpenSSH private key using: openssl rsa -pubout -in .ssh/id_rsa But OpenSSH has no tools to convert from or too PEM public keys (note: PEM private keys are OpenSSH's native format for protocol 2 keys). -d From adrya1984 at gmail.com Sat Jun 20 00:23:15 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Fri, 19 Jun 2009 17:23:15 +0300 Subject: Convert pem key to ssh-rsa format In-Reply-To: <496c8fcc0906190425u11ddf890icb9d5eea4b49cc4b@mail.gmail.com> References: <496c8fcc0906180129n6e2042d7p2cef1dbdf3e7fddb@mail.gmail.com> <496c8fcc0906190425u11ddf890icb9d5eea4b49cc4b@mail.gmail.com> Message-ID: <496c8fcc0906190723u73cf42c6id65899c91be9a621@mail.gmail.com> Hi, I want from a .cer certificate or pem certificate that contains a public key, to obtain a openssh public key. Like this: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC7vbqajDw4o6gJy8UtmIbkcpnkO3Kwc4qsEnSZp/TR+fQi62F79RHWmwKOtFmwteURgLbj7D/WGuNLGOfa/2vse3G2eHnHl5CB8ruRX9fBl/KgwCVr2JaEuUm66bBQeP5XeBotdR4cvX38uPYivCDdPjJ1QWPdspTBKcxeFbccDw== I don't want to extract it from private key... From info at silkwise.com Sat Jun 20 06:21:58 2009 From: info at silkwise.com (info at silkwise.com) Date: Fri, 19 Jun 2009 13:21:58 -0700 (MST) Subject: What is Round Robin DNS? Message-ID: <8180602.495.1245442918666.JavaMail.root@mail.silkwise.com> Dear Sir/Madam, SilkWise.com is a popular question answer website. Some of our users asked the above question, and we think you are the domain expert who can provide a great answer to it. Can you help to answer the question or improve the current answer at the following link? http://www.silkwise.com/content/viewthread_thread,7949 Everyone has unique expertise. SilkWise is the place to share your wisdom, build your networks, and market yourself! SilkWise Team To stop future messages from me, visit http://silkwise.com/content/viewthread_thread,6667 contact PO BOX 36092 Milpitas,CA From bob at proulx.com Mon Jun 22 10:24:01 2009 From: bob at proulx.com (Bob Proulx) Date: Sun, 21 Jun 2009 18:24:01 -0600 Subject: What is Round Robin DNS? In-Reply-To: <8180602.495.1245442918666.JavaMail.root@mail.silkwise.com> References: <8180602.495.1245442918666.JavaMail.root@mail.silkwise.com> Message-ID: <20090622002401.GB8859@dementia.proulx.com> info at silkwise.com wrote: > SilkWise.com is a popular question answer website. Some of our users > asked the above question, and we think you are the domain expert who > can provide a great answer to it. Can you help to answer the > question or improve the current answer at the following link? > > http://www.silkwise.com/content/viewthread_thread,7949 The OpenSSH mailing list is meant for discussion of OpenSSH. Your question seems not to have anything to do with OpenSSH but instead is simply a general networking question. This is not the appropriate mailing list for general networking questions. However your question has already been answered. The description on the link you include has a description already. You seem not to need more at this time. Also your question has already been answered at Wikipedia, a popular online Encyclopedia. Please see Wikipedia for more information. http://en.wikipedia.org/wiki/Round-robin http://en.wikipedia.org/wiki/Round_robin_DNS Bob From scott_n at xypro.com Tue Jun 23 01:55:56 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 22 Jun 2009 08:55:56 -0700 Subject: What is Round Robin DNS? In-Reply-To: <20090622002401.GB8859@dementia.proulx.com> References: <8180602.495.1245442918666.JavaMail.root@mail.silkwise.com> <20090622002401.GB8859@dementia.proulx.com> Message-ID: <78DD71C304F38B41885A242996B96F7301DBA256@xyservd.XYPRO-23.LOCAL> > Bob Proulx replied > > [redacted] wrote: > > [apparent spam redacted] Bob, that looks like a spammer's attempt to increase his hit count. From bob at proulx.com Tue Jun 23 12:49:51 2009 From: bob at proulx.com (Bob Proulx) Date: Mon, 22 Jun 2009 20:49:51 -0600 Subject: What is Round Robin DNS? In-Reply-To: <78DD71C304F38B41885A242996B96F7301DBA256@xyservd.XYPRO-23.LOCAL> References: <8180602.495.1245442918666.JavaMail.root@mail.silkwise.com> <20090622002401.GB8859@dementia.proulx.com> <78DD71C304F38B41885A242996B96F7301DBA256@xyservd.XYPRO-23.LOCAL> Message-ID: <20090623024951.GA16444@dementia.proulx.com> Scott Neugroschl wrote: > > Bob Proulx replied > > [redacted] wrote: > > > [apparent spam redacted] > > Bob, that looks like a spammer's attempt to increase his hit count. Hmm... Unfortunately that thought hadn't occurred to me, agree that you are likely correct, how naive of me, and I was made an unwitting accomplice. :-( Bob From Clayton at Shepard.me Sun Jun 28 01:10:06 2009 From: Clayton at Shepard.me (Clayton Shepard) Date: Sat, 27 Jun 2009 10:10:06 -0500 Subject: scp Output Feature Message-ID: <429e89250906270810l3da4a498p5fe153c5a5c3e93a@mail.gmail.com> I propose a new feature that enables scp to print its status on newlines as well as output to file descriptors that are not terminals. This will allow for more robust logging as well as enable progress parsing for programs such as zenity. The only workaround that I found that does not involve modifying the scp source uses pseudo terminals: http://cwshep.blogspot.com/2009/06/showing-scp-progress-using-zenity.html The patch is fairly trivial and was tested on release 5.2p1 and modifies scp.c, progressmeter.h, and progressmeter.c. The feature is enabled via a '-n' switch. Thank You, Clayton Shepard -------------- next part -------------- A non-text attachment was scrubbed... Name: scp.patch Type: text/x-patch Size: 3987 bytes Desc: not available URL: From list+opensshdev at hauke-lampe.de Mon Jun 29 14:55:42 2009 From: list+opensshdev at hauke-lampe.de (Hauke Lampe) Date: Mon, 29 Jun 2009 06:55:42 +0200 Subject: openbsd-compat/getrrsetbyname.c: answer buffer size too large for EDNS0 and glibc Message-ID: <4A48494E.20901@hauke-lampe.de> Hello. I have an issue with SSHFP lookups using "VerifyHostKeyDNS=yes" and "options edns0" in /etc/resolv.conf (glib >= 2.6). getrrsetbyname() calls res_query() with a maximum buffer size of 65536. The glibc resolver truncates this value to 16 bits, reducing the query's advertised buffer size to 0. BIND appears to ignore it while Unbound returns a server failure. glibc's source suggests that it should retry the query without EDNS0 but it does not. Maybe a timeout triggers earlier. OpenSSH then logs "DNS lookup error: general failure" and continues. I propose reducing ANSWER_BUFFER_SIZE to 65535. Of course, the stub-resolver should probably catch this kind of problem, too. openbsd-compat/getrrsetbyname.c: [...] #define ANSWER_BUFFER_SIZE 1024*64 [...] getrrsetbyname() [...] u_char answer[ANSWER_BUFFER_SIZE]; [...] length = res_query(hostname, (signed int) rdclass, (signed int) rdtype, answer, sizeof(answer)); [...] In the glibc stub-resolver, "sizeof(answer)" is eventually passed on as "anslen" to __res_nopt() in resolv/res_mkquery.c: [...] NS_PUT16(anslen & 0xffff, cp); /* CLASS = UDP payload size */ and sent out to the recursor: | IP 127.0.0.1.44138 > 127.0.0.1.53: 31454+ [1au] SSHFP? orbit.attraktor.org. ar: . OPT UDPsize=0 (48) | IP 127.0.0.1.53 > 127.0.0.1.44138: 31454 ServFail-| [0q] 0/0/0 (12) Hauke. -------------- next part -------------- A non-text attachment was scrubbed... Name: getrrsetbyname-anslen.patch Type: text/x-patch Size: 346 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dtucker at zip.com.au Tue Jun 30 10:57:05 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 30 Jun 2009 10:57:05 +1000 Subject: openbsd-compat/getrrsetbyname.c: answer buffer size too large for EDNS0 and glibc In-Reply-To: <4A48494E.20901@hauke-lampe.de> References: <4A48494E.20901@hauke-lampe.de> Message-ID: <4A4962E1.40705@zip.com.au> Hauke Lampe wrote: > Hello. > > I have an issue with SSHFP lookups using "VerifyHostKeyDNS=yes" and > "options edns0" in /etc/resolv.conf (glib >= 2.6). > > > getrrsetbyname() calls res_query() with a maximum buffer size of 65536. > The glibc resolver truncates this value to 16 bits, reducing the query's > advertised buffer size to 0. > > BIND appears to ignore it while Unbound returns a server failure. > > glibc's source suggests that it should retry the query without EDNS0 but > it does not. Maybe a timeout triggers earlier. > > OpenSSH then logs "DNS lookup error: general failure" and continues. > > I propose reducing ANSWER_BUFFER_SIZE to 65535. Of course, the > stub-resolver should probably catch this kind of problem, too. Sounds reasonable to me. Any objections? -- 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.