From vinschen at redhat.com Tue Apr 1 02:32:43 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 31 Mar 2014 17:32:43 +0200 Subject: SSH_PRIVSEP_USER configurable at runtime? Message-ID: <20140331153243.GD2508@calimero.vinschen.de> Hi, Right now, the unprivileged account for privilege separation is only configurable at compile time (SSH_PRIVSEP_USER). I'd like to ask if it would be acceptable to have the account runtime configurable by adding something like PrivilegeSeparationAccount foo to sshd_config. The reason I'm asking is this. I'm working on a long overdue change to Cygwin which is supposed to get rid of the /etc/passwd and /etc/group files. Rather, the Windows account databases (SAM and AD)are asked directly for account information, and UID/GID values as well as usernames are dynamic. For instance, assuming you have a domain member machine MACH103, which is member of the domain DOM1. Assuming the machine as well as DOM1 and another dmain, DOM2, all have a user called "sshd", the automatically generated Cygwin usernames will be MACH103+sshd for the local account sshd for the account in domain DOM1 DOM2+sshd for the account in domain DOM2. Additionally, the admin can decide if the domain name gets prepended every time, which results in "DOM1+sshd" as username in DOM1, and the domain separator character can be chosen freely as well, for instance a backslash (MACH103\sshd). With domainnames being part of the username, this allows for so many variations of the actual username, that a fixed name "sshd" or just a compile time option will become a problem. Any chance to get such a sshd_config option? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From no_spam_98 at yahoo.com Tue Apr 1 02:40:26 2014 From: no_spam_98 at yahoo.com (no_spam_98 at yahoo.com) Date: Mon, 31 Mar 2014 08:40:26 -0700 (PDT) Subject: CTR mode Message-ID: <1396280426.48328.YahooMailNeo@web140602.mail.bf1.yahoo.com> OpenSSH uses its own CTR mode implementation, correct? ?I seem to recall some discussion about why it hasn't/won't switch over to using OpenSSL's implementation, but I can't find the thread anymore. So... why doesn't OpenSSH use OpenSSL's CTR mode implementation? Thanks. From tomas.kuthan at oracle.com Tue Apr 1 02:54:03 2014 From: tomas.kuthan at oracle.com (Tomas Kuthan) Date: Mon, 31 Mar 2014 17:54:03 +0200 Subject: CTR mode In-Reply-To: <1396280426.48328.YahooMailNeo@web140602.mail.bf1.yahoo.com> References: <1396280426.48328.YahooMailNeo@web140602.mail.bf1.yahoo.com> Message-ID: <53398F9B.6070609@oracle.com> On 03/31/14 05:40 PM, no_spam_98 at yahoo.com wrote: > OpenSSH uses its own CTR mode implementation, correct? I seem to recall some discussion about why it hasn't/won't switch over to using OpenSSL's implementation, but I can't find the thread anymore. > > So... why doesn't OpenSSH use OpenSSL's CTR mode implementation? If you are speaking of CTR mode to AES, it does use OpenSSL for that. For some time it didn't, because OpenSSL's envelope API didn't provide it, but when OpenSSL introduced it, OpenSSH's own implementation was ditched [1]. Tomas [1] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cipher.c#rev1.84 From t.charles at infass.com Tue Apr 1 02:59:22 2014 From: t.charles at infass.com (Thierry CHARLES) Date: Mon, 31 Mar 2014 17:59:22 +0200 Subject: AIX SFTP with chroot : conection closed without error message In-Reply-To: <533458A2.2070907@infass.com> References: <533458A2.2070907@infass.com> Message-ID: <533990DA.2070300@infass.com> Hi, I could not find any other ideas to understand what is happening. Is there a way to display the reason of the disconnection ? Thanks Le 27/03/2014 17:58, Thierry CHARLES a ?crit : > Hello, > > I'm trying to setup a chroot for one user on my AIX 5.2 system > > I have tried with openssh 5.0 (don't know where it comes from) and as > it didn't work, I have downloaded and compiled the current version > (6.6p1) > > When I connect, password is checked, chroot is done, sftp subsystem is > accepted, but I get disconnected without any error > > > Below is all can say about my config (after hours of googling) ... > > Thanks you for any hint that will help making it operational ! > Thierry > > > > > ====================== > $ ls -l /usr/local/ssh/etc/sshd_config > -rw-r--r-- 1 root system 3864 Mar 27 15:55 > /usr/local/ssh/etc/sshd_config > > ====================== > $ cat /usr/local/ssh/etc/sshd_config | sed "s/#.*//g" | egrep -v "^$" > AuthorizedKeysFile .ssh/authorized_keys > UsePrivilegeSeparation sandbox > Subsystem sftp /usr/local/ssh/libexec/sftp-server > Match User cpdp > ChrootDirectory /cpdp > ForceCommand internal-sftp > > ==> I have also tried to set sftp subsystem to "internal-sftp" but it > doesn't work better > > ====================== > $ ls -ld /cpdp > drwxr-xr-x 4 root system 512 Mar 27 14:41 /cpdp > ==> the chroot path is root owned and only root-writable > > ====================== > $ find /cpdp > /cpdp > /cpdp/home > /cpdp/home/cpdp > ==> I have re-created the home directory for the cpdp user but it > isn't better > > ====================== > SERVER LOG > ====================== > $ /usr/local/ssh/sbin/sshd -ddddd -p2222 > debug2: load_server_config: filename /usr/local/ssh/etc/sshd_config > debug2: load_server_config: done config len = 324 > debug2: parse_server_config: config /usr/local/ssh/etc/sshd_config len > 324 > debug3: /usr/local/ssh/etc/sshd_config:54 setting AuthorizedKeysFile > .ssh/authorized_keys > debug3: /usr/local/ssh/etc/sshd_config:110 setting > UsePrivilegeSeparation sandbox > debug3: /usr/local/ssh/etc/sshd_config:126 setting Subsystem > sftp /usr/local/ssh/libexec/sftp-server > debug3: checking syntax for 'Match User cpdp' > debug1: sshd version OpenSSH_6.6, OpenSSL 0.9.8h 28 May 2008 > debug3: Incorrect RSA1 identifier > debug1: key_parse_private2: missing begin marker > debug1: read PEM private key done: type RSA > debug3: Incorrect RSA1 identifier > debug3: Could not load "/usr/local/ssh/etc/ssh_host_rsa_key" as a RSA1 > public key > debug1: private host key: #0 type 1 RSA > debug3: Incorrect RSA1 identifier > debug1: key_parse_private2: missing begin marker > debug1: read PEM private key done: type DSA > debug3: Incorrect RSA1 identifier > debug3: Could not load "/usr/local/ssh/etc/ssh_host_dsa_key" as a RSA1 > public key > debug1: private host key: #1 type 2 DSA > debug3: Incorrect RSA1 identifier > debug3: Incorrect RSA1 identifier > debug3: Could not load "/usr/local/ssh/etc/ssh_host_ed25519_key" as a > RSA1 public key > debug1: private host key: #2 type 4 ED25519 > debug1: rexec_argv[0]='/usr/local/ssh/sbin/sshd' > debug1: rexec_argv[1]='-ddddd' > debug1: rexec_argv[2]='-p2222' > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 2222 on 0.0.0.0. > Server listening on 0.0.0.0 port 2222. > debug2: fd 4 setting O_NONBLOCK > debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY > debug1: Bind to port 2222 on ::. > Bind to port 2222 on :: failed: Address already in use. > debug1: fd 4 clearing O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 7 config len 324 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 > debug1: inetd sockets after dupping: 3, 3 > Connection from 10.1.0.161 port 54046 on 10.1.0.1 port 2222 > debug1: Client protocol version 2.0; client software version > OpenSSH_6.5p1 Debian-6 > debug1: match: OpenSSH_6.5p1 Debian-6 pat OpenSSH* compat 0x04000000 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.6 > debug2: fd 3 setting O_NONBLOCK > debug3: ssh_sandbox_init: preparing rlimit sandbox > debug2: Network child is on pid 89674 > debug3: preauth child monitor started > debug3: privsep user:group 210:202 [preauth] > debug1: permanently_set_uid: 210/202 [preauth] > debug1: list_hostkey_types: ssh-rsa,ssh-dss,ssh-ed25519 [preauth] > debug1: SSH2_MSG_KEXINIT sent [preauth] > debug1: SSH2_MSG_KEXINIT received [preauth] > debug2: kex_parse_kexinit: > curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > [preauth] > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ssh-ed25519 [preauth] > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [preauth] > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [preauth] > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > [preauth] > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > [preauth] > debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] > debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] > debug2: kex_parse_kexinit: [preauth] > debug2: kex_parse_kexinit: [preauth] > debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] > debug2: kex_parse_kexinit: reserved 0 [preauth] > debug2: kex_parse_kexinit: > curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > [preauth] > debug2: kex_parse_kexinit: > ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss > [preauth] > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [preauth] > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [preauth] > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > [preauth] > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > [preauth] > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib [preauth] > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib [preauth] > debug2: kex_parse_kexinit: [preauth] > debug2: kex_parse_kexinit: [preauth] > debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] > debug2: kex_parse_kexinit: reserved 0 [preauth] > debug2: mac_setup: setup hmac-md5-etm at openssh.com [preauth] > debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none > [preauth] > debug2: mac_setup: setup hmac-md5-etm at openssh.com [preauth] > debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none > [preauth] > debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] > debug3: mm_key_sign entering [preauth] > debug3: mm_request_send entering: type 6 [preauth] > debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] > debug3: mm_request_receive_expect entering: type 7 [preauth] > debug3: mm_request_receive entering [preauth] > debug3: mm_request_receive entering > debug3: monitor_read: checking request 6 > debug3: mm_answer_sign > debug3: mm_answer_sign: signature 2004af48(83) > debug3: mm_request_send entering: type 7 > debug2: monitor_read: 6 used once, disabling now > debug2: kex_derive_keys [preauth] > debug2: set_newkeys: mode 1 [preauth] > debug1: SSH2_MSG_NEWKEYS sent [preauth] > debug1: expecting SSH2_MSG_NEWKEYS [preauth] > debug2: set_newkeys: mode 0 [preauth] > debug1: SSH2_MSG_NEWKEYS received [preauth] > debug1: KEX done [preauth] > debug1: userauth-request for user cpdp service ssh-connection method > none [preauth] > debug1: attempt 0 failures 0 [preauth] > debug3: mm_getpwnamallow entering [preauth] > debug3: mm_request_send entering: type 8 [preauth] > debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] > debug3: mm_request_receive_expect entering: type 9 [preauth] > debug3: mm_request_receive entering [preauth] > debug3: mm_request_receive entering > debug3: monitor_read: checking request 8 > debug3: mm_answer_pwnamallow > debug3: Trying to reverse map address 10.1.0.161. > debug2: parse_server_config: config reprocess config len 324 > debug3: checking match for 'User cpdp' user cpdp host pctotc addr > 10.1.0.161 laddr 10.1.0.1 lport 2222 > debug1: user cpdp matched 'User cpdp' at line 136 > debug3: match found > debug3: reprocess config:137 setting ChrootDirectory /cpdp > debug3: reprocess config:138 setting ForceCommand internal-sftp > debug3: AIX/setauthdb set registry 'files' > debug3: aix_restoreauthdb: restoring old registry '' > debug3: AIX/loginrestrictions returned 0 msg (none) > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 > debug3: mm_request_send entering: type 9 > debug2: monitor_read: 8 used once, disabling now > debug2: input_userauth_request: setting up authctxt for cpdp [preauth] > debug3: mm_inform_authserv entering [preauth] > debug3: mm_request_send entering: type 4 [preauth] > debug2: input_userauth_request: try method none [preauth] > debug3: userauth_finish: failure partial=0 next > methods="publickey,password,keyboard-interactive" [preauth] > debug3: mm_request_receive entering > debug3: monitor_read: checking request 4 > debug3: mm_answer_authserv: service=ssh-connection, style= > debug2: monitor_read: 4 used once, disabling now > debug1: userauth-request for user cpdp service ssh-connection method > publickey [preauth] > debug1: attempt 1 failures 0 [preauth] > debug2: input_userauth_request: try method publickey [preauth] > debug1: test whether pkalg/pkblob are acceptable [preauth] > debug3: mm_key_allowed entering [preauth] > debug3: mm_request_send entering: type 22 [preauth] > debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] > debug3: mm_request_receive_expect entering: type 23 [preauth] > debug3: mm_request_receive entering [preauth] > debug3: mm_request_receive entering > debug3: monitor_read: checking request 22 > debug3: mm_answer_keyallowed entering > debug3: mm_answer_keyallowed: key_from_blob: 2004b1d8 > debug1: temporarily_use_uid: 212/1 (e=0/0) > debug1: trying public key file /home/cpdp/.ssh/authorized_keys > debug1: Could not open authorized keys > '/home/cpdp/.ssh/authorized_keys': No such file or directory > debug1: restore_uid: 0/0 > Failed publickey for cpdp from 10.1.0.161 port 54046 ssh2: DSA > 6f:bf:40:de:ee:5c:1c:9f:70:71:68:cf:41:de:f0:5f > debug3: mm_answer_keyallowed: key 2004b1d8 is not allowed > debug3: mm_request_send entering: type 23 > debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss [preauth] > debug3: userauth_finish: failure partial=0 next > methods="publickey,password,keyboard-interactive" [preauth] > debug1: userauth-request for user cpdp service ssh-connection method > keyboard-interactive [preauth] > debug1: attempt 2 failures 1 [preauth] > debug2: input_userauth_request: try method keyboard-interactive [preauth] > debug1: keyboard-interactive devs [preauth] > debug1: auth2_challenge: user=cpdp devs= [preauth] > debug1: kbdint_alloc: devices '' [preauth] > debug2: auth2_challenge_start: devices [preauth] > debug3: userauth_finish: failure partial=0 next > methods="publickey,password,keyboard-interactive" [preauth] > debug1: userauth-request for user cpdp service ssh-connection method > password [preauth] > debug1: attempt 3 failures 2 [preauth] > debug2: input_userauth_request: try method password [preauth] > debug3: mm_auth_password entering [preauth] > debug3: mm_request_send entering: type 12 [preauth] > debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD [preauth] > debug3: mm_request_receive_expect entering: type 13 [preauth] > debug3: mm_request_receive entering [preauth] > debug3: mm_request_receive entering > debug3: monitor_read: checking request 12 > debug3: AIX/authenticate result 0, authmsg > debug3: AIX SYSTEM attribute compat > debug3: AIX/setauthdb set registry 'files' > debug3: AIX/passwdexpired returned 1 msg You are required to change > your password. Please choose a new one. > debug3: aix_restoreauthdb: restoring old registry '' > debug3: mm_answer_authpassword: sending result 1 > debug3: mm_request_send entering: type 13 > Accepted password for cpdp from 10.1.0.161 port 54046 ssh2 > debug3: AIX/setauthdb set registry 'files' > debug1: AIX/loginsuccess: msg Last login: Thu Mar 27 16:00:44 2014 on > ssh from pctotc > > debug3: aix_restoreauthdb: restoring old registry '' > debug1: monitor_child_preauth: cpdp has been authenticated by > privileged process > debug3: mm_get_keystate: Waiting for new keys > debug3: mm_request_receive_expect entering: type 26 > debug3: mm_request_receive entering > debug3: mm_newkeys_from_blob: 2006a398(134) > debug2: mac_setup: setup hmac-md5-etm at openssh.com > debug3: mm_get_keystate: Waiting for second key > debug3: mm_newkeys_from_blob: 2006a398(134) > debug2: mac_setup: setup hmac-md5-etm at openssh.com > debug3: mm_get_keystate: Getting compression state > debug3: mm_get_keystate: Getting Network I/O buffers > debug3: mm_auth_password: user authenticated [preauth] > debug3: mm_send_keystate: Sending new keys: 200516c8 2004ab58 [preauth] > debug3: mm_newkeys_to_blob: converting 200516c8 [preauth] > debug3: mm_newkeys_to_blob: converting 2004ab58 [preauth] > debug3: mm_send_keystate: New keys have been sent [preauth] > debug3: mm_send_keystate: Sending compression state [preauth] > debug3: mm_request_send entering: type 26 [preauth] > debug3: mm_send_keystate: Finished sending state [preauth] > debug1: monitor_read_log: child log fd closed > debug3: mm_share_sync: Share sync > debug3: mm_share_sync: Share sync end > debug3: ssh_sandbox_parent_finish: finished > debug3: AIX/UsrInfo: set len 23 > debug3: safely_chroot: checking '/' > debug3: safely_chroot: checking '/cpdp' > Changed root directory to "/cpdp" > debug1: permanently_set_uid: 212/1 > debug2: set_newkeys: mode 0 > debug2: set_newkeys: mode 1 > debug1: Entering interactive session for SSH2. > debug2: fd 5 setting O_NONBLOCK > debug2: fd 6 setting O_NONBLOCK > debug1: server_init_dispatch_20 > debug1: server_input_channel_open: ctype session rchan 0 win 2097152 > max 32768 > 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 89676 > debug1: server_input_channel_req: channel 0 request env reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req env > debug2: Ignoring env request LANG: disallowed name > debug1: server_input_channel_req: channel 0 request subsystem reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req subsystem > debug2: subsystem request for sftp by user cpdp > debug1: subsystem: cannot stat /usr/local/ssh/libexec/sftp-server: No > such file or directory > debug1: subsystem: exec() /usr/local/ssh/libexec/sftp-server > Starting session: forced-command (config) 'internal-sftp' for cpdp > from 10.1.0.161 port 54046 > debug2: fd 3 setting TCP_NODELAY > debug3: packet_set_tos: set IP_TOS 0x08 > debug2: fd 9 setting O_NONBLOCK > debug2: fd 8 setting O_NONBLOCK > debug2: fd 11 setting O_NONBLOCK > debug2: channel 0: read 83 from efd 11 > debug3: channel 0: discard efd > debug1: Received SIGCHLD. > debug1: session_by_pid: pid 71070 > debug1: session_exit_message: session 0 channel 0 pid 71070 > 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 > debug2: channel 0: read<=0 rfd 9 len 0 > debug2: channel 0: read failed > debug2: channel 0: close_read > debug2: channel 0: input open -> drain > debug2: channel 0: read 0 from efd 11 > debug2: channel 0: closing read-efd 11 > debug2: channel 0: ibuf empty > debug2: channel 0: send eof > debug2: channel 0: input drain -> closed > debug2: channel 0: send close > debug2: notify_done: reading > debug3: channel 0: will not send data after close > debug2: channel 0: rcvd close > Received disconnect from 10.1.0.161: 11: disconnected by user > debug1: do_cleanup > debug3: mm_request_receive entering > debug1: do_cleanup > > > ====================== > CLIENT LOG > ====================== > $ sftp -P 2222 -vvv cpdp at 10.1.0.1 > OpenSSH_6.5, OpenSSL 1.0.1f 6 Jan 2014 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 10.1.0.1 [10.1.0.1] port 2222. > debug1: Connection established. > debug1: identity file /home/tc/.ssh/id_rsa type -1 > debug1: identity file /home/tc/.ssh/id_rsa-cert type -1 > debug3: Incorrect RSA1 identifier > debug3: Could not load "/home/tc/.ssh/id_dsa" as a RSA1 public key > debug1: identity file /home/tc/.ssh/id_dsa type 2 > debug1: identity file /home/tc/.ssh/id_dsa-cert type -1 > debug1: identity file /home/tc/.ssh/id_ecdsa type -1 > debug1: identity file /home/tc/.ssh/id_ecdsa-cert type -1 > debug1: identity file /home/tc/.ssh/id_ed25519 type -1 > debug1: identity file /home/tc/.ssh/id_ed25519-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.5p1 Debian-6 > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6 > debug1: match: OpenSSH_6.6 pat OpenSSH* compat 0x04000000 > debug2: fd 3 setting O_NONBLOCK > debug3: put_host_port: [10.1.0.1]:2222 > debug3: load_hostkeys: loading entries for host "[10.1.0.1]:2222" from > file "/home/tc/.ssh/known_hosts" > debug3: load_hostkeys: found key type ED25519 in file > /home/tc/.ssh/known_hosts:177 > debug3: load_hostkeys: loaded 1 keys > debug3: order_hostkeyalgs: prefer hostkeyalgs: > ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: > curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: > ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,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-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,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-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,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: > curve25519-sha256 at libssh.org,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,ssh-ed25519 > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,chacha20-poly1305 at openssh.com,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,chacha20-poly1305 at openssh.com,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-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,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-etm at openssh.com > debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none > debug2: mac_setup: found hmac-md5-etm at openssh.com > debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug1: Server host key: ED25519 > 51:c3:32:61:dd:77:32:87:14:2d:78:21:17:53:bb:8d > debug3: put_host_port: [10.1.0.1]:2222 > debug3: put_host_port: [10.1.0.1]:2222 > debug3: load_hostkeys: loading entries for host "[10.1.0.1]:2222" from > file "/home/tc/.ssh/known_hosts" > debug3: load_hostkeys: found key type ED25519 in file > /home/tc/.ssh/known_hosts:177 > debug3: load_hostkeys: loaded 1 keys > debug3: load_hostkeys: loading entries for host "[10.1.0.1]:2222" from > file "/home/tc/.ssh/known_hosts" > debug3: load_hostkeys: found key type ED25519 in file > /home/tc/.ssh/known_hosts:177 > debug3: load_hostkeys: loaded 1 keys > debug1: Host '[10.1.0.1]:2222' is known and matches the ED25519 host key. > debug1: Found key in /home/tc/.ssh/known_hosts:177 > debug1: ssh_ed25519_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: Roaming not allowed by server > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /home/tc/.ssh/id_rsa ((nil)), > debug2: key: /home/tc/.ssh/id_dsa (0x7fe98cc92070), > debug2: key: /home/tc/.ssh/id_ecdsa ((nil)), > debug2: key: /home/tc/.ssh/id_ed25519 ((nil)), > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug3: start over, passed a different list > publickey,password,keyboard-interactive > debug3: preferred publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Trying private key: /home/tc/.ssh/id_rsa > debug3: no such identity: /home/tc/.ssh/id_rsa: No such file or directory > debug1: Offering DSA public key: /home/tc/.ssh/id_dsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug1: Trying private key: /home/tc/.ssh/id_ecdsa > debug3: no such identity: /home/tc/.ssh/id_ecdsa: No such file or > directory > debug1: Trying private key: /home/tc/.ssh/id_ed25519 > debug3: no such identity: /home/tc/.ssh/id_ed25519: No such file or > directory > debug2: we did not send a packet, disable method > debug3: authmethod_lookup keyboard-interactive > debug3: remaining preferred: password > debug3: authmethod_is_enabled keyboard-interactive > debug1: Next authentication method: keyboard-interactive > debug2: userauth_kbdint > debug2: we sent a keyboard-interactive packet, wait for reply > debug1: Authentications that can continue: > publickey,password,keyboard-interactive > debug3: userauth_kbdint: disable: no info_req_seen > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: > debug3: authmethod_is_enabled password > debug1: Next authentication method: password > cpdp at 10.1.0.1's password: > debug3: packet_send2: adding 64 (len 49 padlen 15 extra_pad 64) > debug2: we sent a password packet, wait for reply > debug1: Authentication succeeded (password). > Authenticated to 10.1.0.1 ([10.1.0.1]:2222). > debug2: fd 4 setting O_NONBLOCK > debug3: fd 5 is O_NONBLOCK > 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: fd 3 setting TCP_NODELAY > debug3: packet_set_tos: set IP_TOS 0x08 > debug2: client_session2_setup: id 0 > debug1: Sending environment. > debug3: Ignored env SSH_AGENT_PID > debug3: Ignored env KDE_MULTIHEAD > debug3: Ignored env DM_CONTROL > debug3: Ignored env SHELL > debug3: Ignored env TERM > debug3: Ignored env XDG_SESSION_COOKIE > debug3: Ignored env XDM_MANAGED > debug3: Ignored env GTK2_RC_FILES > debug3: Ignored env KONSOLE_DBUS_SERVICE > debug3: Ignored env KONSOLE_PROFILE_NAME > debug3: Ignored env GS_LIB > debug3: Ignored env GTK_RC_FILES > debug3: Ignored env WINDOWID > debug3: Ignored env SHELL_SESSION_ID > debug3: Ignored env KDE_FULL_SESSION > debug3: Ignored env USER > debug3: Ignored env LS_COLORS > debug3: Ignored env XCURSOR_SIZE > debug3: Ignored env SSH_AUTH_SOCK > debug3: Ignored env SESSION_MANAGER > debug3: Ignored env DESKTOP_SESSION > debug3: Ignored env PATH > debug3: Ignored env PWD > debug3: Ignored env KONSOLE_DBUS_WINDOW > debug3: Ignored env KDE_SESSION_UID > debug1: Sending env LANG = fr_FR.UTF-8 > debug2: channel 0: request env confirm 0 > debug3: Ignored env KONSOLE_DBUS_SESSION > debug3: Ignored env HOME > debug3: Ignored env COLORFGBG > debug3: Ignored env SHLVL > debug3: Ignored env KDE_SESSION_VERSION > debug3: Ignored env LANGUAGE > debug3: Ignored env XCURSOR_THEME > debug3: Ignored env LOGNAME > debug3: Ignored env XDG_DATA_DIRS > debug3: Ignored env DBUS_SESSION_BUS_ADDRESS > debug3: Ignored env WINDOWPATH > debug3: Ignored env PROFILEHOME > debug3: Ignored env DISPLAY > debug3: Ignored env QT_PLUGIN_PATH > debug3: Ignored env XDG_CURRENT_DESKTOP > debug3: Ignored env _ > debug1: Sending subsystem: sftp > debug2: channel 0: request subsystem confirm 1 > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 2097152 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: subsystem 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: obuf empty > debug2: channel 0: close_write > debug2: channel 0: output drain -> closed > debug2: channel 0: rcvd close > debug3: channel 0: will not send data after close > debug2: channel 0: 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 cc -1) > > debug1: fd 0 clearing O_NONBLOCK > debug3: fd 1 is not O_NONBLOCK > Transferred: sent 3104, received 2136 bytes, in 0.0 seconds > Bytes per second: sent 234989.4, received 161706.6 > debug1: Exit status 1 > Connection closed -------------- next part -------------- A non-text attachment was scrubbed... Name: t_charles.vcf Type: text/x-vcard Size: 285 bytes Desc: not available URL: From mancha1 at zoho.com Tue Apr 1 03:11:19 2014 From: mancha1 at zoho.com (mancha) Date: Mon, 31 Mar 2014 16:11:19 +0000 Subject: CTR mode In-Reply-To: <1396280426.48328.YahooMailNeo@web140602.mail.bf1.yahoo.com> References: <1396280426.48328.YahooMailNeo@web140602.mail.bf1.yahoo.com> Message-ID: <20140331161119.GA25480@zoho.com> On Mon, Mar 31, 2014 at 08:40:26AM -0700, no_spam_98 at yahoo.com wrote: > OpenSSH uses its own CTR mode implementation, correct? ?I seem to > recall some discussion about why it hasn't/won't switch over to using > OpenSSL's implementation, but I can't find the thread anymore. > > So... why doesn't OpenSSH use OpenSSL's CTR mode implementation? I believe as of 6.2, OpenSSH defaults to using OpenSSL's EVP_aes_*_ctr. I'm unaware of the history (hopefully one of the devs can jump in and help us there). What I do know is OpenSSL introduced AES-CTR support with 0.9.7. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From des at des.no Tue Apr 1 07:56:51 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon, 31 Mar 2014 22:56:51 +0200 Subject: Version string Message-ID: <868urq6q98.fsf@nine.des.no> 6.2p2 prints the same version string in the debugging output as it does when invoked with -V: % ssh -V OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 % ssh -v nonesuch |& head -1 OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 6.3p1 and newer don't - I don't have anything at hand that runs 6.3p1, but here are 6.[456]p1: % ssh -V OpenSSH_6.4p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013 % ssh -v nonesuch |& head -1 OpenSSH_6.4, OpenSSL 1.0.1e-freebsd 11 Feb 2013 % ssh -V OpenSSH_6.5p1, OpenSSL 1.0.1f-freebsd 6 Jan 2014 % ssh -v nonesuch |& head -1 OpenSSH_6.5, OpenSSL 1.0.1f-freebsd 6 Jan 2014 % ssh -V OpenSSH_6.6p1, OpenSSL 1.0.1f-freebsd 6 Jan 2014 % ssh -v nonesuch |& head -1 OpenSSH_6.6, OpenSSL 1.0.1f-freebsd 6 Jan 2014 and my patched version of 6.6p1: % ssh -V OpenSSH_6.6p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013 % ssh -v nonesuch |& head -1 OpenSSH_6.6p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013 Patch: Index: ssh.c =================================================================== RCS file: /cvs/openssh/ssh.c,v retrieving revision 1.398 diff -u -r1.398 ssh.c --- ssh.c 26 Feb 2014 23:17:13 -0000 1.398 +++ ssh.c 31 Mar 2014 20:48:30 -0000 @@ -876,7 +876,7 @@ SYSLOG_FACILITY_USER, !use_syslog); if (debug_flag) - logit("%s, %s", SSH_VERSION, SSLeay_version(SSLEAY_VERSION)); + logit("%s, %s", SSH_RELEASE, SSLeay_version(SSLEAY_VERSION)); /* Parse the configuration files */ process_config_files(pw); DES -- Dag-Erling Sm?rgrav - des at des.no From djm at mindrot.org Tue Apr 1 12:52:20 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Apr 2014 12:52:20 +1100 (EST) Subject: Using -Ocancel on dynamically allocated ports In-Reply-To: References: Message-ID: On Fri, 28 Mar 2014, Sean Patrick Santos wrote: > I'm not sure whether this is a "bug" or not, because I really don't > understand what the intended behavior is. But I think that at least in > the second case, where you know what port is allocated, using -Ocancel > should work to cancel the forwarding request. Right - this is a bug; cancelling the actually allocated port should work. Could you file it at https://bugzilla.mindrot.org/ ? Thanks, Damien From djm at mindrot.org Tue Apr 1 14:43:03 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Apr 2014 14:43:03 +1100 (EST) Subject: Version string In-Reply-To: <868urq6q98.fsf@nine.des.no> References: <868urq6q98.fsf@nine.des.no> Message-ID: On Mon, 31 Mar 2014, Dag-Erling Sm?rgrav wrote: > % ssh -V > OpenSSH_6.6p1, OpenSSL 1.0.1f-freebsd 6 Jan 2014 > % ssh -v nonesuch |& head -1 > OpenSSH_6.6, OpenSSL 1.0.1f-freebsd 6 Jan 2014 > > and my patched version of 6.6p1: > > % ssh -V > OpenSSH_6.6p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013 > % ssh -v nonesuch |& head -1 > OpenSSH_6.6p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013 Applied -d From djm at mindrot.org Tue Apr 1 14:46:29 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Apr 2014 14:46:29 +1100 (EST) Subject: SSH_PRIVSEP_USER configurable at runtime? In-Reply-To: <20140331153243.GD2508@calimero.vinschen.de> References: <20140331153243.GD2508@calimero.vinschen.de> Message-ID: On Mon, 31 Mar 2014, Corinna Vinschen wrote: > For instance, assuming you have a domain member machine MACH103, which > is member of the domain DOM1. Assuming the machine as well as DOM1 > and another dmain, DOM2, all have a user called "sshd", the automatically > generated Cygwin usernames will be > > MACH103+sshd for the local account > sshd for the account in domain DOM1 > DOM2+sshd for the account in domain DOM2. > > Additionally, the admin can decide if the domain name gets prepended > every time, which results in "DOM1+sshd" as username in DOM1, and the > domain separator character can be chosen freely as well, for instance > a backslash (MACH103\sshd). > > With domainnames being part of the username, this allows for so many > variations of the actual username, that a fixed name "sshd" or just > a compile time option will become a problem. > > Any chance to get such a sshd_config option? I'm really loathe to add an option for this. Is there any way that sshd could figure out which account automatically? e.g. by having ssh-host-config ensure that ${machine}/sshd exists and is appropriately configured -d From djm at mindrot.org Tue Apr 1 14:55:10 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Apr 2014 14:55:10 +1100 (EST) Subject: AIX SFTP with chroot : conection closed without error message In-Reply-To: <533990DA.2070300@infass.com> References: <533458A2.2070907@infass.com> <533990DA.2070300@infass.com> Message-ID: On Mon, 31 Mar 2014, Thierry CHARLES wrote: > Hi, > > I could not find any other ideas to understand what is happening. Is there a > way to display the reason of the disconnection ? ... > > debug2: subsystem request for sftp by user cpdp > > debug1: subsystem: cannot stat /usr/local/ssh/libexec/sftp-server: No such > > file or directory > > debug1: subsystem: exec() /usr/local/ssh/libexec/sftp-server > > Starting session: forced-command (config) 'internal-sftp' for cpdp from > > 10.1.0.161 port 54046 ... > > debug1: Received SIGCHLD. > > debug1: session_by_pid: pid 71070 > > debug1: session_exit_message: session 0 channel 0 pid 71070 So, sshd is sucessfully establishing the connection but the internal sftp server is stopping without producing any output. Adding some debug flags to your sshd_config Subsystem declaration might elicit a little more information, e.g. Subsystem sftp internal-sftp -l debug3 You could also try "ssh -p 2222 user at host" and seeing it produces any unexpected output. -d From wkevils at gmail.com Tue Apr 1 18:05:07 2014 From: wkevils at gmail.com (Kevin Wilson) Date: Tue, 1 Apr 2014 10:05:07 +0300 Subject: How can I have the same ssh key for dual boot (ssh-keygen) Message-ID: I use: ssh-keygen -t rsa to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on other machines in order to permit ssh to these machines without being asked for a password. The thing is that I have dual boot on this machine: one for fedora and one for ubuntu. The two key files which were generated on these machine are different. Is there a way so that I will have the same key file for both these fedora and ubuntu ? regards, Kevin From djm at mindrot.org Tue Apr 1 18:08:16 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Apr 2014 18:08:16 +1100 (EST) Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: References: Message-ID: On Tue, 1 Apr 2014, Kevin Wilson wrote: > I use: > ssh-keygen -t rsa > to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on > other machines in order to permit ssh to these machines without being > asked for a password. > > The thing is that I have dual boot on this machine: one for fedora and > one for ubuntu. The two key files which were generated on these machine > are different. > > Is there a way so that I will have the same key file for both these fedora > and > ubuntu ? Copy it from one to the other. From jdehaan at zwartkasteel.nl Tue Apr 1 18:11:35 2014 From: jdehaan at zwartkasteel.nl (Jan de Haan) Date: Tue, 1 Apr 2014 09:11:35 +0200 Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: References: Message-ID: Hi Kevin, 2 possible solutions: 1) put the same private key (id_rsa, not id_rsa.pub) on a shared medium (usb stick comes to mind) and use that, by mounting it on ~/.ssh, or such. 2) copy the same private key to both environments. Sincerely, Jan. On Tue, Apr 1, 2014 at 9:05 AM, Kevin Wilson wrote: > I use: > ssh-keygen -t rsa > to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on > other machines in order to permit ssh to these machines without being > asked for a password. > > The thing is that I have dual boot on this machine: one for fedora and > one for ubuntu. The two key files which were generated on these machine > are different. > > Is there a way so that I will have the same key file for both these fedora > and > ubuntu ? > > regards, > Kevin > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- "Piracy is simply demand where supply does not exist." From hecht at hlrs.de Tue Apr 1 18:34:44 2014 From: hecht at hlrs.de (Martin Hecht) Date: Tue, 01 Apr 2014 09:34:44 +0200 Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: References: Message-ID: <533A6C14.60308@hlrs.de> one thing not yet mentioned by others: You should not only synchronize the keys in ~/.ssh/ but, more important, in order to avoid that all other clients complain about a suspeced man in the middle attack, you should copy the host keys located in /etc/ssh/ (e.g. by temporarily putting them on an usb medium during reboot, or by mounting the root partition of the other linux e.g. somewhere below /mnt - just once for copying the files). Then, clean up the ~/.ssh/known_hosts files on the other machines. On 04/01/2014 09:05 AM, Kevin Wilson wrote: > I use: > ssh-keygen -t rsa > to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on > other machines in order to permit ssh to these machines without being > asked for a password. > > The thing is that I have dual boot on this machine: one for fedora and > one for ubuntu. The two key files which were generated on these machine > are different. > > Is there a way so that I will have the same key file for both these fedora > and > ubuntu ? > > regards, > Kevin > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From t.charles at infass.com Tue Apr 1 18:50:48 2014 From: t.charles at infass.com (Thierry CHARLES) Date: Tue, 01 Apr 2014 09:50:48 +0200 Subject: AIX SFTP with chroot : conection closed without error message In-Reply-To: References: <533458A2.2070907@infass.com> <533990DA.2070300@infass.com> Message-ID: <533A6FD8.30904@infass.com> I didn't know that I can have different logging level in the sftp process. thanks for the tip I have tried and there is some information : sftp cannot allocate a tty ! The logs : Starting session: forced-command (config) 'internal-sftp' on pts/11 for cpdp from 10.1.0.161 port 50336 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: channel 0: rfd 9 isatty debug2: fd 9 setting O_NONBLOCK /dev/pts/11: No such file or directory debug3: fd 7 is O_NONBLOCK open /dev/tty failed - could not set controlling tty: No such file or directory looks like it requires having a duplicate environment inside the chroot :-( Is there a way to avoid /dev duplication ? If not, does anyone know how to do it ? Thanks, Thierry *Thierry CHARLES* Infass Syst?mes Le 01/04/2014 05:55, Damien Miller a ?crit : > Adding some debug flags to your sshd_config Subsystem declaration might > elicit a little more information, e.g. > > Subsystem sftp internal-sftp -l debug3 -------------- next part -------------- A non-text attachment was scrubbed... Name: t_charles.vcf Type: text/x-vcard Size: 273 bytes Desc: not available URL: From t.charles at infass.com Tue Apr 1 19:00:04 2014 From: t.charles at infass.com (Thierry CHARLES) Date: Tue, 01 Apr 2014 10:00:04 +0200 Subject: AIX SFTP with chroot : conection closed without error message In-Reply-To: <533A6FD8.30904@infass.com> References: <533458A2.2070907@infass.com> <533990DA.2070300@infass.com> <533A6FD8.30904@infass.com> Message-ID: <533A7204.4080302@infass.com> Excuse me, I did a "ssh user at host" instead of "sftp user at host". That's why it tried to open a tty. So I tried again with SFTP and I got nothing more :'( debug1: session_input_channel_req: session 0 req subsystem debug2: subsystem request for sftp by user cpdp debug1: subsystem: internal-sftp Starting session: subsystem 'sftp' for cpdp from 10.1.0.161 port 50442 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x08 debug2: fd 9 setting O_NONBLOCK debug2: fd 8 setting O_NONBLOCK debug2: fd 11 setting O_NONBLOCK debug2: channel 0: read<=0 rfd 9 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: read 83 from efd 11 debug3: channel 0: discard efd debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: notify_done: reading debug1: Received SIGCHLD. debug1: session_by_pid: pid 66584 debug1: session_exit_message: session 0 channel 0 pid 66584 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 debug2: channel 0: read 0 from efd 11 debug2: channel 0: closing read-efd 11 debug2: channel 0: send close debug3: channel 0: will not send data after close debug3: channel 0: will not send data after close debug2: channel 0: rcvd close Received disconnect from 10.1.0.161: 11: disconnected by user debug1: do_cleanup debug3: mm_request_receive entering debug1: do_cleanup Thierry Le 01/04/2014 09:50, Thierry CHARLES a ?crit : > I didn't know that I can have different logging level in the sftp > process. thanks for the tip > > I have tried and there is some information : sftp cannot allocate a tty ! > > The logs : > > Starting session: forced-command (config) 'internal-sftp' on pts/11 > for cpdp from 10.1.0.161 port 50336 > debug2: fd 3 setting TCP_NODELAY > debug3: packet_set_tos: set IP_TOS 0x10 > debug2: channel 0: rfd 9 isatty > debug2: fd 9 setting O_NONBLOCK > /dev/pts/11: No such file or directory > debug3: fd 7 is O_NONBLOCK > open /dev/tty failed - could not set controlling tty: No such file or > directory > > > looks like it requires having a duplicate environment inside the > chroot :-( > > Is there a way to avoid /dev duplication ? > If not, does anyone know how to do it ? > > Thanks, > Thierry > > *Thierry CHARLES* > Infass Syst?mes > > Le 01/04/2014 05:55, Damien Miller a ?crit : >> Adding some debug flags to your sshd_config Subsystem declaration might >> elicit a little more information, e.g. >> >> Subsystem sftp internal-sftp -l debug3 > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: t_charles.vcf Type: text/x-vcard Size: 273 bytes Desc: not available URL: From phil at hands.com Tue Apr 1 19:48:02 2014 From: phil at hands.com (Philip Hands) Date: Tue, 01 Apr 2014 09:48:02 +0100 Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: References: Message-ID: <87sipx1lml.fsf@poker.hands.com> Kevin Wilson writes: > I use: > ssh-keygen -t rsa > to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on > other machines in order to permit ssh to these machines without being > asked for a password. > > The thing is that I have dual boot on this machine: one for fedora and > one for ubuntu. The two key files which were generated on these machine > are different. > > Is there a way so that I will have the same key file for both these fedora > and > ubuntu ? As mentioned by others, there is a way to do this, but I'd suggest that you shouldn't want to. What's wrong with having an additional key in the authorized_keys file? If the thing you're trying to avoid is the pain of installing the keys twice, well if you're using ssh-copy-id just add the public key for the other machine into the id_*.pub file on each, then whichever you install From will authorise both. If you've got a more structured way of installing the keys (i.e. chengine, puppet etc. etc.) then just add both keys to your config and you're done. This seems preferable both on the basis that you're not having to fiddle with the host keys in possibly assumption-breaking ways, but also because it may come to pass that one of the keys is somehow compromised while the other remains secure, in which case you'll be able to boot the secure system and fix things. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://ftp.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From vinschen at redhat.com Tue Apr 1 19:55:50 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 1 Apr 2014 10:55:50 +0200 Subject: SSH_PRIVSEP_USER configurable at runtime? In-Reply-To: References: <20140331153243.GD2508@calimero.vinschen.de> Message-ID: <20140401085550.GA13510@calimero.vinschen.de> On Apr 1 14:46, Damien Miller wrote: > On Mon, 31 Mar 2014, Corinna Vinschen wrote: > > > For instance, assuming you have a domain member machine MACH103, which > > is member of the domain DOM1. Assuming the machine as well as DOM1 > > and another dmain, DOM2, all have a user called "sshd", the automatically > > generated Cygwin usernames will be > > > > MACH103+sshd for the local account > > sshd for the account in domain DOM1 > > DOM2+sshd for the account in domain DOM2. > > > > Additionally, the admin can decide if the domain name gets prepended > > every time, which results in "DOM1+sshd" as username in DOM1, and the > > domain separator character can be chosen freely as well, for instance > > a backslash (MACH103\sshd). > > > > With domainnames being part of the username, this allows for so many > > variations of the actual username, that a fixed name "sshd" or just > > a compile time option will become a problem. > > > > Any chance to get such a sshd_config option? > > I'm really loathe to add an option for this. Is there any way that > sshd could figure out which account automatically? e.g. by having > ssh-host-config ensure that ${machine}/sshd exists and is appropriately > configured I'm not sure I can follow. Do you mean we should make sure that a machine account sshd always exists and use that? The problem is, sshd would still call getpwent("sshd"). This would work for machine accounts on non-domain machines and for primary domain accounts on domain member machines, but it would fail for a machine account on a domain member machine when using the default account naming rules. And if the admin changed them to "always prepend domain name", there would not be a "sshd" account at all. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Tue Apr 1 20:10:00 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 1 Apr 2014 11:10:00 +0200 Subject: SSH_PRIVSEP_USER configurable at runtime? In-Reply-To: <20140401085550.GA13510@calimero.vinschen.de> References: <20140331153243.GD2508@calimero.vinschen.de> <20140401085550.GA13510@calimero.vinschen.de> Message-ID: <20140401091000.GA13853@calimero.vinschen.de> On Apr 1 10:55, Corinna Vinschen wrote: > On Apr 1 14:46, Damien Miller wrote: > > On Mon, 31 Mar 2014, Corinna Vinschen wrote: > > > > > For instance, assuming you have a domain member machine MACH103, which > > > is member of the domain DOM1. Assuming the machine as well as DOM1 > > > and another dmain, DOM2, all have a user called "sshd", the automatically > > > generated Cygwin usernames will be > > > > > > MACH103+sshd for the local account > > > sshd for the account in domain DOM1 > > > DOM2+sshd for the account in domain DOM2. > > > > > > Additionally, the admin can decide if the domain name gets prepended > > > every time, which results in "DOM1+sshd" as username in DOM1, and the > > > domain separator character can be chosen freely as well, for instance > > > a backslash (MACH103\sshd). > > > > > > With domainnames being part of the username, this allows for so many > > > variations of the actual username, that a fixed name "sshd" or just > > > a compile time option will become a problem. > > > > > > Any chance to get such a sshd_config option? > > > > I'm really loathe to add an option for this. Is there any way that > > sshd could figure out which account automatically? e.g. by having > > ssh-host-config ensure that ${machine}/sshd exists and is appropriately > > configured > > I'm not sure I can follow. Do you mean we should make sure that a > machine account sshd always exists and use that? > > The problem is, sshd would still call getpwent("sshd"). This would work s/getpwent/getpwnam > for machine accounts on non-domain machines and for primary domain > accounts on domain member machines, but it would fail for a machine > account on a domain member machine when using the default account naming > rules. And if the admin changed them to "always prepend domain name", > there would not be a "sshd" account at all. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From djm at mindrot.org Tue Apr 1 22:39:06 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Apr 2014 22:39:06 +1100 (EST) Subject: AIX SFTP with chroot : conection closed without error message In-Reply-To: <533A7204.4080302@infass.com> References: <533458A2.2070907@infass.com> <533990DA.2070300@infass.com> <533A6FD8.30904@infass.com> <533A7204.4080302@infass.com> Message-ID: On Tue, 1 Apr 2014, Thierry CHARLES wrote: > Excuse me, I did a "ssh user at host" instead of "sftp user at host". That's why it > tried to open a tty. > > So I tried again with SFTP and I got nothing more :'( Unfortunately I don't have an AIX system to help reproduce this. I'd suggest either running sshd under a debugger to see what is going wrong -or- adding some debug() calls to do_child() and sftp_server_main() to see where it is failing. From djm at mindrot.org Tue Apr 1 22:41:59 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Apr 2014 22:41:59 +1100 (EST) Subject: SSH_PRIVSEP_USER configurable at runtime? In-Reply-To: <20140401085550.GA13510@calimero.vinschen.de> References: <20140331153243.GD2508@calimero.vinschen.de> <20140401085550.GA13510@calimero.vinschen.de> Message-ID: On Tue, 1 Apr 2014, Corinna Vinschen wrote: > I'm not sure I can follow. Do you mean we should make sure that a > machine account sshd always exists and use that? > > The problem is, sshd would still call getpwent("sshd"). This would work > for machine accounts on non-domain machines and for primary domain > accounts on domain member machines, but it would fail for a machine > account on a domain member machine when using the default account naming > rules. And if the admin changed them to "always prepend domain name", > there would not be a "sshd" account at all. I'm suggesting changing the account that sshd tries to look up. If it always uses ${machine}\sshd then will it work? (Assuming the host setup script ensures this account exists) -d From erik at fscking.org Tue Apr 1 23:02:54 2014 From: erik at fscking.org (Erik Bernstein) Date: Tue, 01 Apr 2014 14:02:54 +0200 Subject: Forcing of environment variables Message-ID: <533AAAEE.3050800@fscking.org> Hi guys, I'm having a little trouble with the current semantics of the PermitUserEnv directive. I would like to be able to force certain environment variables for some of the ssh keys I'm using. It seems that apart from using the command="..." keyword in authorized_keys, there is also the possibility to specify additional variables using the environment="..." keyword. However, in order to make this work I have to enable PermitUserEnv in the sshd_config (also enabling parsing of ~/.ssh/environment), otherwise the keys are rejected with "Bad options in [...]/authorized_keys file" This seems a bit harsh. Considering, that a) clients can always send arbitrary variables with -o SendEnv and b) accepted variables have to be additionally whitelisted in AcceptEnv anyways, rejecting those keys seems a bit counterintuitive. Maybe it would be more intuitive to accept the keys by ignoring the environment="..." variable and simply throwing a warning? I would also certainly appreciate the possibility to force environment variables for individual keys without having to enable PermitUserEnv globally. cheers, erik From vinschen at redhat.com Tue Apr 1 23:15:29 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 1 Apr 2014 14:15:29 +0200 Subject: SSH_PRIVSEP_USER configurable at runtime? In-Reply-To: References: <20140331153243.GD2508@calimero.vinschen.de> <20140401085550.GA13510@calimero.vinschen.de> Message-ID: <20140401121529.GA16619@calimero.vinschen.de> On Apr 1 22:41, Damien Miller wrote: > On Tue, 1 Apr 2014, Corinna Vinschen wrote: > > > I'm not sure I can follow. Do you mean we should make sure that a > > machine account sshd always exists and use that? > > > > The problem is, sshd would still call getpwent("sshd"). This would work > > for machine accounts on non-domain machines and for primary domain > > accounts on domain member machines, but it would fail for a machine > > account on a domain member machine when using the default account naming > > rules. And if the admin changed them to "always prepend domain name", > > there would not be a "sshd" account at all. > > I'm suggesting changing the account that sshd tries to look up. If it > always uses ${machine}\sshd then will it work? (Assuming the host setup > script ensures this account exists) So you're suggesting to change sshd.c to fetch the name of the machine first, then construct the account name in a local buffer and give that to getpwnam? That won't work either in all cases. On non-domain machines the account name will be "sshd", not "${machine}+sshd". Except if the admin specifies that the domain is always prepended, which makes it "${machine}+sshd" again. And if the admin specifies the separator char to be not '+' but, for instance '#', the account name will be "${machine}#sshd". All that knowledge would have to go into sshd.c. Isn't it much easier and less convoluted to allow specifying the account name in sshd_config? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nkadel at gmail.com Tue Apr 1 23:44:46 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 1 Apr 2014 08:44:46 -0400 Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: <87sipx1lml.fsf@poker.hands.com> References: <87sipx1lml.fsf@poker.hands.com> Message-ID: On Tue, Apr 1, 2014 at 4:48 AM, Philip Hands wrote: > Kevin Wilson writes: > >> I use: >> ssh-keygen -t rsa >> to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on >> other machines in order to permit ssh to these machines without being >> asked for a password. >> >> The thing is that I have dual boot on this machine: one for fedora and >> one for ubuntu. The two key files which were generated on these machine >> are different. >> >> Is there a way so that I will have the same key file for both these fedora >> and >> ubuntu ? > > As mentioned by others, there is a way to do this, but I'd suggest that > you shouldn't want to. > > What's wrong with having an additional key in the authorized_keys file? It's not an "additoinal" key. It's a mismatched key for the same hostname in DNS and the same IP address. This causes every SSH client on the planet to complain about the mismatch, unless you've specifically disabled that check in your client configuration. And there is *no* tool besides a text editor for updating such changed records in the UNIX/Linux client text based client world besides a text editor. This is partly why some folks would like an authentication procedure for host keys, so such changed keys can be signed by a trustworthy upstream source and simply accepted like signed SSL keys. > If the thing you're trying to avoid is the pain of installing the keys > twice, well if you're using ssh-copy-id just add the public key for the > other machine into the id_*.pub file on each, then whichever you install > From will authorise both. If you've got a more structured way of > installing the keys (i.e. chengine, puppet etc. etc.) then just add both > keys to your config and you're done. > > This seems preferable both on the basis that you're not having to fiddle > with the host keys in possibly assumption-breaking ways, but also > because it may come to pass that one of the keys is somehow compromised > while the other remains secure, in which case you'll be able to boot the > secure system and fix things. Accepting this sort of user pain is how IT departments get hated. It might be acceptable for one person who built the system to deal with the yammering about mismatched keys when trying to do work, it would not be acceptable in most development envirornments. And it's an ongoing problem for server rebuilds from PXE or for SSH services behind a load balancer. From djm at mindrot.org Wed Apr 2 09:18:46 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 2 Apr 2014 09:18:46 +1100 (EST) Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: References: <87sipx1lml.fsf@poker.hands.com> Message-ID: On Tue, 1 Apr 2014, Nico Kadel-Garcia wrote: > This is partly why some folks would like an authentication procedure > for host keys, so such changed keys can be signed by a trustworthy > upstream source and simply accepted like signed SSL keys. You mean like the certificate keys we added to OpenSSH four years ago? -d From nkadel at gmail.com Wed Apr 2 15:07:07 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 2 Apr 2014 00:07:07 -0400 Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: References: <87sipx1lml.fsf@poker.hands.com> Message-ID: On Tue, Apr 1, 2014 at 6:18 PM, Damien Miller wrote: > On Tue, 1 Apr 2014, Nico Kadel-Garcia wrote: > >> This is partly why some folks would like an authentication procedure >> for host keys, so such changed keys can be signed by a trustworthy >> upstream source and simply accepted like signed SSL keys. > > You mean like the certificate keys we added to OpenSSH four years ago? Which of the three technologies that no one uses are you referring to? The lack of a consistent specification makes it far more difficult to implement in even a limited way, between RFC 4255 *DNS based signatures which I've not seen anyone use since the RFC was published), RFC 6187 (X.509 based signatures, which are available via patch for OpenSSH but are not in the base source code and thus vulnerable to support problems), and OpenSSH's own special non-RFC published technique described in the PROTOCOLS.certkeys file and which, again, does not work with other clients. So yes, they'd like a working authentication *procedure*. The divergence of the multiple signature technologies actively hinders their use. If you think any of these have gained any significant please any 3 publicly exposed SSH services that use any of these technologies to sign their keys that is not hosted by an active SSH or OpenSSH developer. Nico Kadel-Garcia From phil at hands.com Wed Apr 2 21:20:53 2014 From: phil at hands.com (Philip Hands) Date: Wed, 02 Apr 2014 11:20:53 +0100 Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: References: <87sipx1lml.fsf@poker.hands.com> Message-ID: <878uro118a.fsf@poker.hands.com> Nico Kadel-Garcia writes: > On Tue, Apr 1, 2014 at 4:48 AM, Philip Hands wrote: >> Kevin Wilson writes: >> >>> I use: >>> ssh-keygen -t rsa >>> to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on >>> other machines in order to permit ssh to these machines without being >>> asked for a password. >>> >>> The thing is that I have dual boot on this machine: one for fedora and >>> one for ubuntu. The two key files which were generated on these machine >>> are different. >>> >>> Is there a way so that I will have the same key file for both these fedora >>> and >>> ubuntu ? >> >> As mentioned by others, there is a way to do this, but I'd suggest that >> you shouldn't want to. >> >> What's wrong with having an additional key in the authorized_keys file? > > It's not an "additoinal" key. It's a mismatched key for the same > hostname in DNS and the same IP address. This causes every SSH client > on the planet to complain about the mismatch, unless you've > specifically disabled that check in your client configuration. And > there is *no* tool besides a text editor for updating such changed > records in the UNIX/Linux client text based client world besides a > text editor. The original question was about client authentication keys, not host keys, unless I misunderstood the bit about: I use: ssh-keygen -t rsa to generate a key file (id_rsa.pub) ... Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://ftp.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From nkadel at gmail.com Wed Apr 2 21:53:27 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 2 Apr 2014 06:53:27 -0400 Subject: How can I have the same ssh key for dual boot (ssh-keygen) In-Reply-To: <878uro118a.fsf@poker.hands.com> References: <87sipx1lml.fsf@poker.hands.com> <878uro118a.fsf@poker.hands.com> Message-ID: On Wed, Apr 2, 2014 at 6:20 AM, Philip Hands wrote: > Nico Kadel-Garcia writes: > >> On Tue, Apr 1, 2014 at 4:48 AM, Philip Hands wrote: >>> Kevin Wilson writes: >>> >>>> I use: >>>> ssh-keygen -t rsa >>>> to generate a key file (id_rsa.pub) which I copy into authorized_keys2 on >>>> other machines in order to permit ssh to these machines without being >>>> asked for a password. >>>> >>>> The thing is that I have dual boot on this machine: one for fedora and >>>> one for ubuntu. The two key files which were generated on these machine >>>> are different. >>>> >>>> Is there a way so that I will have the same key file for both these fedora >>>> and >>>> ubuntu ? >>> >>> As mentioned by others, there is a way to do this, but I'd suggest that >>> you shouldn't want to. >>> >>> What's wrong with having an additional key in the authorized_keys file? >> >> It's not an "additoinal" key. It's a mismatched key for the same >> hostname in DNS and the same IP address. This causes every SSH client >> on the planet to complain about the mismatch, unless you've >> specifically disabled that check in your client configuration. And >> there is *no* tool besides a text editor for updating such changed >> records in the UNIX/Linux client text based client world besides a >> text editor. > > The original question was about client authentication keys, not host > keys, unless I misunderstood the bit about: > > I use: > ssh-keygen -t rsa > to generate a key file (id_rsa.pub) ... > > Cheers, Phil. Good point. I was thinking of the inevitable "known_hosts" conflicts when SSH'ing *to each of the dual-boot environments. The use of multiple public keys in authorized_hosts is much less of an issue. But the clients for other environments are still likely to face the mismatched host keys issue, unless the dual boot environment is carefully managed to have distinct IP addresses for each of the dual-boot environments. That sort of fun and games is partly why I've moved away from dual boot, and instead prefer to virtualize development environments on a stable host machine. The Windows box for games, which need performance, runs as a base OS for the play host, and the development work happens in the VM's. From peter at stuge.se Wed Apr 2 22:37:43 2014 From: peter at stuge.se (Peter Stuge) Date: Wed, 2 Apr 2014 13:37:43 +0200 Subject: SSH_PRIVSEP_USER configurable at runtime? In-Reply-To: <20140401121529.GA16619@calimero.vinschen.de> References: <20140331153243.GD2508@calimero.vinschen.de> <20140401085550.GA13510@calimero.vinschen.de> <20140401121529.GA16619@calimero.vinschen.de> Message-ID: <20140402113743.17700.qmail@stuge.se> Corinna Vinschen wrote: > On non-domain machines the account > name will be "sshd", not "${machine}+sshd". Except if the admin > specifies that the domain is always prepended, which makes it > "${machine}+sshd" again. And if the admin specifies the separator char > to be not '+' but, for instance '#', the account name will be > "${machine}#sshd". > > All that knowledge would have to go into sshd.c. FWIW I think this is the right solution. > Isn't it much easier and less convoluted to allow specifying the > account name in sshd_config? But less right, if only because if the admin changes those settings then they need to go touch config files for no real reason. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From singh.ravipratap88 at gmail.com Wed Apr 2 23:30:05 2014 From: singh.ravipratap88 at gmail.com (RAVI PRATAP Singh) Date: Wed, 2 Apr 2014 18:00:05 +0530 Subject: Openssh KDF testing Message-ID: Hello Everyone, I am writing code to test derive_keys functionality. The function signature is: static u_char * derive_key(Kex *kex, int id, u_int need, u_char *hash, u_int hashlen, BIGNUM *shared_secret) Now, the input which is provided to us is K(share_secret) as an array of characters. H(Hash) as an array of characters. Session_id as an array of characters Now, first I converted hash and session_id in binary form using hex2bin function. For shared secret, the bignum structure is like struct bignum_st { BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit chunks. */ int top; /* Index of last used d +1. */ /* The next are internal book keeping for bn_expand. */ int dmax; /* Size of the d array. */ int neg; /* one if the number is negative */ int flags; }; My doubt is how to fill the shared_secret structure ( which is of BIGNUM type) elements ? from the array of characters, K. For H and session_id I converted them to bin. For K what should be done? I need to pass these three values to the derive_key function which will return below six outputs Initial IV (client to server) ......for id = 'A' Initial IV (server to client) ......for id = 'B' Encryption key (client to server).....for id = 'C' Encryption key (server to client) .....for id = 'D' Integrity key (client to server) .....for id = 'E' Integrity key (server to client) .....for id = 'F' Please help me in understanding SSH key derivation. Thanks Ravi Pratap From vinschen at redhat.com Wed Apr 2 23:44:28 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 2 Apr 2014 14:44:28 +0200 Subject: SSH_PRIVSEP_USER configurable at runtime? In-Reply-To: <20140402113743.17700.qmail@stuge.se> References: <20140331153243.GD2508@calimero.vinschen.de> <20140401085550.GA13510@calimero.vinschen.de> <20140401121529.GA16619@calimero.vinschen.de> <20140402113743.17700.qmail@stuge.se> Message-ID: <20140402124428.GT2508@calimero.vinschen.de> On Apr 2 13:37, Peter Stuge wrote: > Corinna Vinschen wrote: > > On non-domain machines the account > > name will be "sshd", not "${machine}+sshd". Except if the admin > > specifies that the domain is always prepended, which makes it > > "${machine}+sshd" again. And if the admin specifies the separator char > > to be not '+' but, for instance '#', the account name will be > > "${machine}#sshd". > > > > All that knowledge would have to go into sshd.c. > > FWIW I think this is the right solution. Hmm. Come to think of it, SSH_PRIVSEP_USER could be defined as a macro calling a function which returns the username. And configure.ac could define SSH_PRIVSEP_USER as, say, cygwin_privsep_user() by default, when built for Cygwin so the ugly details could be hidden in bsd-cygwin_util.c. The Cygwin changes are still in an early stage of testing, but I'll come back to this. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From t.charles at infass.com Thu Apr 3 02:21:46 2014 From: t.charles at infass.com (Thierry CHARLES) Date: Wed, 02 Apr 2014 17:21:46 +0200 Subject: AIX SFTP with chroot : conection closed without error message In-Reply-To: References: <533458A2.2070907@infass.com> <533990DA.2070300@infass.com> <533A6FD8.30904@infass.com> <533A7204.4080302@infass.com> Message-ID: <533C2B0A.9040605@infass.com> I finally found an IBM document listing the whole procedure to make chroot on AIX and ... It works ! :-) (SFTP and SSH too !) https://www-01.ibm.com/support/docview.wss?uid=isg3T1012883 Le 01/04/2014 13:39, Damien Miller a ?crit : > On Tue, 1 Apr 2014, Thierry CHARLES wrote: > >> Excuse me, I did a "ssh user at host" instead of "sftp user at host". That's why it >> tried to open a tty. >> >> So I tried again with SFTP and I got nothing more :'( > Unfortunately I don't have an AIX system to help reproduce this. > I'd suggest either running sshd under a debugger to see what is going > wrong -or- adding some debug() calls to do_child() and > sftp_server_main() to see where it is failing. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: t_charles.vcf Type: text/x-vcard Size: 273 bytes Desc: not available URL: From mancha1 at zoho.com Thu Apr 3 02:38:46 2014 From: mancha1 at zoho.com (mancha) Date: Wed, 2 Apr 2014 15:38:46 +0000 Subject: [RFC] Add hash token to ControlPath In-Reply-To: References: <20140306183721.6EDA920106@smtp.hushmail.com> <20140306191301.GB6663@linux124.nas.nasa.gov> Message-ID: <20140402153819.GA11400@zoho.com> On Fri, Mar 07, 2014 at 04:11:17AM +0000, mancha wrote: > Darren Tucker writes: > > > > On Fri, Mar 7, 2014 at 7:36 AM, mancha wrote: > > [...] > > > 1. Digest is based on lhost(%l) + rhost(%h) + rport(%p) + > > > ruser(%r) 2. Macro is %D > > > > Here's the currently implemented % expansions across all the tools > > (the intention being to prevent any new conflicts or > > inconsistencies). > > > > http://www.dtucker.net/openssh/percent_expand_opts.html > > > > That table was really helpful - thanks. > > I've settled on %m (for "message digest") to avoid any confusion. > > New patch is up: > > http://sf.net/projects/mancha/files/misc/openssh-6.5p1-mux-hash.diff > > --mancha > Hello. I've updated the mux-hash patch for OpenSSH 6.6p1 (attached & posted at http://sf.net/projects/mancha/files/misc/openssh-6.6p1-mux-hash.diff). --mancha -------------- next part -------------- >From 6fdd69b3bfc8dcefccc2d7ca4220b72d2bb8b8d3 Mon Sep 17 00:00:00 2001 From: mancha Date: Wed, 02 Apr 2014 Subject: Add digest of lhost+rhost+rport+ruser for use with ControlPath. When combining %h, %r, and %p (recommended for uniqueness) in ControlPath, long remote usernames and/or hostnames can cause the expansion to bump up against UNIX_PATH_MAX. This patch adds a new percent-token (%m) that expands to the sha1 digest of the concatenation of the local host (%l) + remote host (%h) + remote port (%p) + remote user (%r). This token's expanded length is a fixed 40 characters and, barring digest collision, provides uniqueness. Sample usage: ControlPath ~/.ssh/control-master/%m --- ssh.c | 19 +++++++++++++++++++ ssh_config.5 | 8 +++++--- 2 files changed, 24 insertions(+), 3 deletions(-) --- a/ssh.c +++ b/ssh.c @@ -83,6 +83,7 @@ #include "canohost.h" #include "compat.h" #include "cipher.h" +#include "digest.h" #include "packet.h" #include "buffer.h" #include "channels.h" @@ -190,6 +191,9 @@ static int remote_forward_confirms_recei extern int muxserver_sock; extern u_int muxclient_command; +/* Length of mux hash value (using sha1) */ +#define MUX_DIGEST_LENGTH 20 + /* Prints a help message to the user. This function never returns. */ static void @@ -422,6 +426,9 @@ main(int ac, char **av) extern char *optarg; Forward fwd; struct addrinfo *addrs = NULL; + struct ssh_digest_ctx *md; + unsigned char digest[MUX_DIGEST_LENGTH]; + char mux_hash[MUX_DIGEST_LENGTH*2+1]; /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ sanitise_stdfd(); @@ -982,6 +989,17 @@ main(int ac, char **av) shorthost[strcspn(thishost, ".")] = '\0'; snprintf(portstr, sizeof(portstr), "%d", options.port); + if ((md = ssh_digest_start(SSH_DIGEST_SHA1)) == NULL || + ssh_digest_update(md, thishost, strlen(thishost)) < 0 || + ssh_digest_update(md, host, strlen(host)) < 0 || + ssh_digest_update(md, portstr, strlen(portstr)) < 0 || + ssh_digest_update(md, options.user, strlen(options.user)) < 0 || + ssh_digest_final(md, digest, sizeof(digest)) < 0) + fatal("%s: mux digest failed", __func__); + for(i = 0; i < MUX_DIGEST_LENGTH; i++) + sprintf(&mux_hash[i*2], "%02x", (unsigned int)digest[i]); + ssh_digest_free(md); + if (options.local_command != NULL) { debug3("expanding LocalCommand: %s", options.local_command); cp = options.local_command; @@ -1000,6 +1018,7 @@ main(int ac, char **av) options.control_path = percent_expand(cp, "h", host, "l", thishost, "n", host_arg, "r", options.user, "p", portstr, "u", pw->pw_name, "L", shorthost, + "m", mux_hash, (char *)NULL); free(cp); } --- a/ssh_config.5 +++ b/ssh_config.5 @@ -482,14 +482,16 @@ .Ql %p the destination port, .Ql %r -by the remote login username, and +by the remote login username, .Ql %u by the username of the user running -.Xr ssh 1 . +.Xr ssh 1 , and +.Ql %m +by the SHA1 digest of the concatenation: %l%h%p%r. It is recommended that any .Cm ControlPath used for opportunistic connection sharing include -at least %h, %p, and %r. +at least %h, %p, and %r (or alternatively %m). This ensures that shared connections are uniquely identified. .It Cm ControlPersist When used in conjunction with From djm at mindrot.org Thu Apr 3 07:56:18 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 3 Apr 2014 07:56:18 +1100 (EST) Subject: Openssh KDF testing In-Reply-To: References: Message-ID: On Wed, 2 Apr 2014, RAVI PRATAP Singh wrote: > My doubt is how to fill the shared_secret structure ( which is of BIGNUM > type) elements ? from the array of characters, K. You can use OpenSSL's API for this, e.g. BN_hex2bn() or BN_bin2bn() -d From djm at mindrot.org Thu Apr 3 07:57:32 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 3 Apr 2014 07:57:32 +1100 (EST) Subject: [RFC] Add hash token to ControlPath In-Reply-To: <20140402153819.GA11400@zoho.com> References: <20140306183721.6EDA920106@smtp.hushmail.com> <20140306191301.GB6663@linux124.nas.nasa.gov> <20140402153819.GA11400@zoho.com> Message-ID: On Wed, 2 Apr 2014, mancha wrote: > I've updated the mux-hash patch for OpenSSH 6.6p1 (attached & posted at > http://sf.net/projects/mancha/files/misc/openssh-6.6p1-mux-hash.diff). Could you file a bug for this at bugzilla? That's the best way to make sure it doesn't fall off our radar. -d From singh.ravipratap88 at gmail.com Thu Apr 3 10:17:47 2014 From: singh.ravipratap88 at gmail.com (RAVI PRATAP Singh) Date: Thu, 3 Apr 2014 04:47:47 +0530 Subject: Openssh KDF testing In-Reply-To: References: Message-ID: Thanks Damien. I tried BN_bin2bn() and issue is resolved now. --Ravi On Thu, Apr 3, 2014 at 2:26 AM, Damien Miller wrote: > On Wed, 2 Apr 2014, RAVI PRATAP Singh wrote: > > > My doubt is how to fill the shared_secret structure ( which is of BIGNUM > > type) elements ? from the array of characters, K. > > You can use OpenSSL's API for this, e.g. BN_hex2bn() or BN_bin2bn() > > -d > From aris at 0xbadc0de.be Thu Apr 3 22:00:14 2014 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Thu, 03 Apr 2014 13:00:14 +0200 Subject: CTR mode In-Reply-To: <20140331161119.GA25480@zoho.com> References: <1396280426.48328.YahooMailNeo@web140602.mail.bf1.yahoo.com> <20140331161119.GA25480@zoho.com> Message-ID: <533D3F3E.1000601@0xbadc0de.be> FYI, Openssl 0.9.7<= x <0.9.7c implement is but the implementation was broken. It gave me my share of headaches on a particular version of CentOS/RHEL 4.8 that was using 0.9.7a. More details on https://blog.0xbadc0de.be/archives/15 Aris Le 31/03/14 18:11, mancha a ?crit : > On Mon, Mar 31, 2014 at 08:40:26AM -0700, no_spam_98 at yahoo.com > wrote: >> OpenSSH uses its own CTR mode implementation, correct? I seem >> to recall some discussion about why it hasn't/won't switch over >> to using OpenSSL's implementation, but I can't find the thread >> anymore. >> >> So... why doesn't OpenSSH use OpenSSL's CTR mode implementation? > > I believe as of 6.2, OpenSSH defaults to using OpenSSL's > EVP_aes_*_ctr. > > I'm unaware of the history (hopefully one of the devs can jump in > and help us there). What I do know is OpenSSL introduced AES-CTR > support with 0.9.7. > > --mancha > > > > _______________________________________________ openssh-unix-dev > mailing list openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From mancha1 at zoho.com Fri Apr 4 16:33:03 2014 From: mancha1 at zoho.com (mancha) Date: Fri, 4 Apr 2014 05:33:03 +0000 Subject: [RFC] Add hash token to ControlPath In-Reply-To: References: <20140306183721.6EDA920106@smtp.hushmail.com> <20140306191301.GB6663@linux124.nas.nasa.gov> <20140402153819.GA11400@zoho.com> Message-ID: <20140404053303.GA18324@zoho.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, Apr 03, 2014 at 07:57:32AM +1100, Damien Miller wrote: > On Wed, 2 Apr 2014, mancha wrote: > > > I've updated the mux-hash patch for OpenSSH 6.6p1 (attached & posted at > > http://sf.net/projects/mancha/files/misc/openssh-6.6p1-mux-hash.diff). > > Could you file a bug for this at bugzilla? That's the best way to make > sure it doesn't fall off our radar. Done. https://bugzilla.mindrot.org/show_bug.cgi?id=2220 Thanks for the suggestion. - --mamcha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJTPkQOAAoJEFdS1BJ1Sb0bHu4QAI6Ai3GmuA5nDhvagfvJjD+N 1mnjwIZDQqBWEpIWJAv1ej4iDVy99NcyfRqF67pr6hQYufnrFq9fTicfxp7gzxaj XfNJBWvUv9yRffa8cWNfSqQD6JKsJDk+6r4wINx1qu88uC01G27FJGnO87DstlWM o8uzpz9sFE6jKgXXrt/SpSpOXRJ+4nK8EqgMbOuECXsyuHnv0N/iBKhQkDfx7KXn /tMzj9KMqcQen3QDFPkc3s8luXpkXvbvz9PrjmBbB8iT2lNtBdrDv7ZAriTU7uUS k27aXg3dPiAFRoOuyDzGV8g0AVhJC6ayeIxwGYxn5KcqnXZyhi9sYYVd5aEfcHSY 4roefBzgm9ARdR54xRedw0rw2N9Y42Atj4X7V1KuzRnVmgnxuB1GbJ5gt8BjqPwN uyz1Z6eEC7u95WG4BwZacqstWp9Z2R9eoDZRyCXr0C15lvVh5GPbtqCkEb5zVFcv 6nP+yvPZQp5OMw3GjVSC/BNePawqMzjlFmDDnP0BoiBXkx/V28H/uA74XqA2yEuL M/e0ho6oCpscZMxZNtCpfBmA/UfwO2b5nLvzBH4NSbxvUPuvAZkqPaz6cKxRc8oK L1rOuA6Ocx5oi4XiS8KC0/vEzK1H86nWTFP0+42O3ydOGqh0pnkUWCOyxGNxBxv0 NZhgsGPTVkqkaVghmLg9 =p5ZB -----END PGP SIGNATURE----- From timo.teras at iki.fi Sun Apr 6 05:27:32 2014 From: timo.teras at iki.fi (Timo Teras) Date: Sat, 5 Apr 2014 22:27:32 +0300 Subject: [PATCH] Use EVP_Digest Message-ID: <20140405222732.1f112831@vostro> Hi, It would be preferable to use EVP_Digest for oneshot digest calculation: - one calloc/free less - EVP_Digest properly sets oneshot flag (certain hardware accelerators work only if the flag is set) Please consider applying the following patch: diff -ru openssh-6.6p1.orig/digest-openssl.c openssh-6.6p1/digest-openssl.c --- openssh-6.6p1.orig/digest-openssl.c 2014-02-04 02:25:45.000000000 +0200 +++ openssh-6.6p1/digest-openssl.c 2014-04-04 17:00:29.548457919 +0300 @@ -148,14 +148,11 @@ int ssh_digest_memory(int alg, const void *m, size_t mlen, u_char *d, size_t dlen) { - struct ssh_digest_ctx *ctx = ssh_digest_start(alg); + const struct ssh_digest *digest = ssh_digest_by_alg(alg); - if (ctx == NULL) + if (!EVP_Digest(m, mlen, d, dlen, digest->mdfunc(), NULL)) return -1; - if (ssh_digest_update(ctx, m, mlen) != 0 || - ssh_digest_final(ctx, d, dlen) != 0) - return -1; - ssh_digest_free(ctx); + return 0; } From mancha1 at zoho.com Tue Apr 8 08:44:57 2014 From: mancha1 at zoho.com (mancha) Date: Mon, 7 Apr 2014 22:44:57 +0000 Subject: Ed25519 keys in SSHFP RRs Message-ID: <20140407224457.GC29348@zoho.com> Hello. Subramanian Moonesamy has gotten the ball rolling to include Ed25519 in IANA's registry for SSHFP key types [1]. I've opened a bug report [2] that includes a patch that adds the needed support code and provisionally assigns Ed25519 a value of 4 (values 1,2,3 reserved for RSA, DSA, and ECDA, respectively) [3]. The enhancement request/bug is meant to keep the issue on the radar. --mancha [1] https://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-01 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2223 [3] https://www.iana.org/assignments/dns-sshfp-rr-parameters/dns-sshfp-rr-parameters.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mancha1 at zoho.com Tue Apr 8 09:49:36 2014 From: mancha1 at zoho.com (mancha) Date: Mon, 7 Apr 2014 23:49:36 +0000 Subject: OpenSSL vulnerability Message-ID: <20140407234936.GD29348@zoho.com> Hello. FYI a very serious OpenSSL flaw was made public today. It has implications for existing OpenSSL key material though no direct impact on OpenSSH. For those interested, here's a good description: http://heartbleed.com/ --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From loganaden at gmail.com Tue Apr 8 13:27:47 2014 From: loganaden at gmail.com (Loganaden Velvindron) Date: Tue, 8 Apr 2014 07:27:47 +0400 Subject: Ed25519 keys in SSHFP RRs In-Reply-To: <20140407224457.GC29348@zoho.com> References: <20140407224457.GC29348@zoho.com> Message-ID: On Tue, Apr 8, 2014 at 2:44 AM, mancha wrote: > Hello. > > Subramanian Moonesamy has gotten the ball rolling to include Ed25519 in > IANA's registry for SSHFP key types [1]. > > I've opened a bug report [2] that includes a patch that adds the needed > support code and provisionally assigns Ed25519 a value of 4 (values > 1,2,3 reserved for RSA, DSA, and ECDA, respectively) [3]. Hi. Yeah, SM's proposal is picking up momentum ! I already had opened a bug report for that: https://bugzilla.mindrot.org/show_bug.cgi?id=2197 > > The enhancement request/bug is meant to keep the issue on the radar. Indeed :-) > > --mancha > > [1] https://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-01 > [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2223 > [3] https://www.iana.org/assignments/dns-sshfp-rr-parameters/dns-sshfp-rr-parameters.txt > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From mancha1 at zoho.com Tue Apr 8 13:58:40 2014 From: mancha1 at zoho.com (mancha) Date: Tue, 8 Apr 2014 03:58:40 +0000 Subject: Ed25519 keys in SSHFP RRs In-Reply-To: References: <20140407224457.GC29348@zoho.com> Message-ID: <20140408035840.GA20321@zoho.com> On Tue, Apr 08, 2014 at 07:27:47AM +0400, Loganaden Velvindron wrote: > On Tue, Apr 8, 2014 at 2:44 AM, mancha wrote: > > Hello. > > > > Subramanian Moonesamy has gotten the ball rolling to include Ed25519 in > > IANA's registry for SSHFP key types [1]. > > > > I've opened a bug report [2] that includes a patch that adds the needed > > support code and provisionally assigns Ed25519 a value of 4 (values > > 1,2,3 reserved for RSA, DSA, and ECDA, respectively) [3]. > > Hi. Yeah, SM's proposal is picking up momentum ! > > I already had opened a bug report for that: > https://bugzilla.mindrot.org/show_bug.cgi?id=2197 > > > > > > The enhancement request/bug is meant to keep the issue on the radar. > > Indeed :-) > > > > > --mancha > > > > [1] https://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-01 > > [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2223 > > [3] https://www.iana.org/assignments/dns-sshfp-rr-parameters/dns-sshfp-rr-parameters.txt I should have searched the bugzilla before opening a new report. Your patch made me notice a small bug in mine (updated). 2223 is now marked a duplicate of 2197. Thanks. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gero at likemag.org Tue Apr 8 03:02:43 2014 From: gero at likemag.org (Gero Peters) Date: Mon, 7 Apr 2014 19:02:43 +0200 (CEST) Subject: Source code patch (for 6.6p1) adding support for Brainpool Elliptic Curves Message-ID: <1347250587.203255.1396890163714.open-xchange@email.1und1.de> Dear all, ? maybe it is a little early but the next (stable) version of OpenSSL will support Brainpool Ellptic curves (current beta 1.0.2-beta1 contains support for Brainpool already). Brainpool curves are defined in RFC 5639. ? Please find attached a patch file that adds support for Brainpool Elliptic Curves in OpenSSH. Currently, setting the bit size to 256, 384 or 521 selects one of the matching NIST curves - specification of named curves not supported. I added 512, which selects brainpoolP512r1 (canonically). Furthermore, you can specify the nick name of an Elliptic Curve using the -b switch of ssh-keygen. Supported nick names are: nistp256, nistp384, nistp521 and the Brainpool ones: brainpoolP256r1, brainpoolP256t1 brainpoolP384r1, brainpoolP384t1 brainpoolP512r1, brainpoolP512t1 Would be nice if someone could review (maybe modify if desired?) the patch and if it is eligible, then adding the stuff would make me (and hopefully others) happy. Btw, ECDSA host key not touched, i.e. derived from bit size (i.e. always a NIST-thing). Thx. [Gero at likemag] ? From djm at mindrot.org Tue Apr 8 17:45:13 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 8 Apr 2014 17:45:13 +1000 (EST) Subject: Source code patch (for 6.6p1) adding support for Brainpool Elliptic Curves In-Reply-To: <1347250587.203255.1396890163714.open-xchange@email.1und1.de> References: <1347250587.203255.1396890163714.open-xchange@email.1und1.de> Message-ID: On Mon, 7 Apr 2014, Gero Peters wrote: > Dear all, > > maybe it is a little early but the next (stable) version of OpenSSL > will support Brainpool Ellptic curves (current beta 1.0.2-beta1 > contains support for Brainpool already). Brainpool curves are defined > in RFC 5639. > > Please find attached a patch file that adds support for Brainpool > Elliptic Curves in OpenSSH. Currently, setting the bit size to 256, > 384 or 521 selects one of the matching NIST curves - specification of > named curves not supported. I added 512, which selects brainpoolP512r1 > (canonically). Furthermore, you can specify the nick name of an > Elliptic Curve using the -b switch of ssh-keygen. What are the advantages of these curves over curve25519 and it's longer bit length cousins? -d From jan at mojzis.com Tue Apr 8 22:39:46 2014 From: jan at mojzis.com (Jan =?utf-8?q?Moj=C5=BE=C3=AD=C5=A1?=) Date: Tue, 8 Apr 2014 14:39:46 +0200 Subject: buffer_put_bignum2_from_string question Message-ID: <201404081439.46364.jan@mojzis.com> Hello, I have question about buffer_put_bignum2_from_string function used in kexc25519.c in (OpenSSH >= 6.5) Is it 1:1 replacement for formating bignums from OpenSSL? If yes, then buffer_put_bignum2_from_string has different results for numbers starting with zeros. How to reproduce: shared_key[CURVE25519_SIZE] = "\0\0\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"; buffer_put_bignum2_from_string(out, shared_key, CURVE25519_SIZE); and than same number format into bignum and than into wire format. Best regards, Jan From djm at mindrot.org Wed Apr 9 09:05:41 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 9 Apr 2014 09:05:41 +1000 (EST) Subject: buffer_put_bignum2_from_string question In-Reply-To: <201404081439.46364.jan@mojzis.com> References: <201404081439.46364.jan@mojzis.com> Message-ID: On Tue, 8 Apr 2014, Jan Moj??? wrote: > Hello, > I have question about buffer_put_bignum2_from_string > function used in kexc25519.c in (OpenSSH >= 6.5) > > Is it 1:1 replacement for formating bignums from OpenSSL? It is intended to be. > If yes, then buffer_put_bignum2_from_string > has different results for numbers starting with zeros. Yes, there is a bug. I think this fixes it: Index: bufaux.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/bufaux.c,v retrieving revision 1.56 diff -u -p -r1.56 bufaux.c --- bufaux.c 2 Feb 2014 03:44:31 -0000 1.56 +++ bufaux.c 8 Apr 2014 23:04:11 -0000 @@ -370,6 +370,8 @@ buffer_put_bignum2_from_string(Buffer *b if (l > 8 * 1024) fatal("%s: length %u too long", __func__, l); + for (; l > 0 && *s == 0; l--, s++) + ; p = buf = xmalloc(l + 1); /* * If most significant bit is set then prepend a zero byte to From ecsd at transbay.net Wed Apr 9 10:05:05 2014 From: ecsd at transbay.net (Eric Dynamic) Date: Tue, 08 Apr 2014 17:05:05 -0700 Subject: immediate "gotcha" in compilation!? 6.6p1 versus openssl 1.0.1g Message-ID: <53448EB1.3030100@transbay.net> So they released openssl 101g to patch for a hole. One then wishes to recompile openssh. After ".configure" I get this: synergy[124]# make if test "doc" = "cat"; then manpage=./`echo scp.1.out | sed 's/\.[1-9]\.out$/\.0/'`; else manpage=./`echo scp.1.out | sed 's/\.out$//'`; fi; if test "doc" = "man"; then /usr/bin/sed -e 's|/etc/ssh/ssh_config|/usr/etc/ssh_config|g' -e 's|/etc/ssh/ssh_known_hosts|/usr/etc/ssh_known_hosts|g' -e 's|/etc/ssh/sshd_config|/usr/etc/sshd_config|g' -e 's|/usr/libexec|/usr/libexec|g' -e 's|/etc/shosts.equiv|/usr/etc/shosts.equiv|g' -e 's|/etc/ssh/ssh_host_key|/usr/etc/ssh_host_key|g' -e 's|/etc/ssh/ssh_host_ecdsa_key|/usr/etc/ssh_host_ecdsa_key|g' -e 's|/etc/ssh/ssh_host_dsa_key|/usr/etc/ssh_host_dsa_key|g' -e 's|/etc/ssh/ssh_host_rsa_key|/usr/etc/ssh_host_rsa_key|g' -e 's|/etc/ssh/ssh_host_ed25519_key|/usr/etc/ssh_host_ed25519_key|g' -e 's|/var/run/sshd.pid|/var/run/sshd.pid|g' -e 's|/etc/moduli|/usr/etc/moduli|g' -e 's|/etc/ssh/moduli|/usr/etc/moduli|g' -e 's|/etc/ssh/sshrc|/usr/etc/sshrc|g' -e 's|/usr/X11R6/bin/xauth|undefined|g' -e 's|/var/empty|/var/empty|g' -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g' ${manpage} | /bin/csh ./fixalgorithms /usr/bin/sed | nawk -f ./mdoc2man.awk > scp.1.out; else /usr/bin/sed -e 's|/etc/ssh/ssh_config|/usr/etc/ssh_config|g' -e 's|/etc/ssh/ssh_known_hosts|/usr/etc/ssh_known_hosts|g' -e 's|/etc/ssh/sshd_config|/usr/etc/sshd_config|g' -e 's|/usr/libexec|/usr/libexec|g' -e 's|/etc/shosts.equiv|/usr/etc/shosts.equiv|g' -e 's|/etc/ssh/ssh_host_key|/usr/etc/ssh_host_key|g' -e 's|/etc/ssh/ssh_host_ecdsa_key|/usr/etc/ssh_host_ecdsa_key|g' -e 's|/etc/ssh/ssh_host_dsa_key|/usr/etc/ssh_host_dsa_key|g' -e 's|/etc/ssh/ssh_host_rsa_key|/usr/etc/ssh_host_rsa_key|g' -e 's|/etc/ssh/ssh_host_ed25519_key|/usr/etc/ssh_host_ed25519_key|g' -e 's|/var/run/sshd.pid|/var/run/sshd.pid|g' -e 's|/etc/moduli|/usr/etc/moduli|g' -e 's|/etc/ssh/moduli|/usr/etc/moduli|g' -e 's|/etc/ssh/sshrc|/usr/etc/sshrc|g' -e 's|/usr/X11R6/bin/xauth|undefined|g' -e 's|/var/empty|/var/empty|g' -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g' ${manpage} | /bin/csh ./fixalgorithms /usr/bin/sed > scp.1.out; fi Badly placed ()'s. *** [scp.1.out] Error code 1 Stop in /usr/local/openssh/openssh-6.6p1. there are no parentheses at all in the above, by the way. here was my .configure command: ./configure --prefix=/usr --with-ssl-dir=/usr/local/openssl/openssl-1.0.1g here is the system I'm running on: FreeBSD synergy.transbay.net 9.1-RELEASE FreeBSD 9.1-RELEASE #2: Wed Dec 18 21:17:07 PST 2013 [1]root at synergy.transbay.net:/usr/src/sys/i386/compile/SYNERGY i386 is this something that can be quickly patched up? The prolog above (prior to actual compilations) can be manually performed, but I'd figure this is hitting many people and I'd rather go fresh with a patched version that gets past this (syntax?) issue. References 1. mailto:root at synergy.transbay.net:/usr/src/sys/i386/compile/SYNERGY From dtucker at zip.com.au Wed Apr 9 17:53:05 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 9 Apr 2014 09:53:05 +0200 Subject: immediate "gotcha" in compilation!? 6.6p1 versus openssl 1.0.1g In-Reply-To: <53448EB1.3030100@transbay.net> References: <53448EB1.3030100@transbay.net> Message-ID: On Wed, Apr 9, 2014 at 2:05 AM, Eric Dynamic wrote: [...] > -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g' ${manpage} | /bin/csh > ./fixalgorithms well fixalgorithms is a Bourne shell script, so that's likely the problem. The top of the Makefile has this: # uncomment if you run a non bourne compatable shell. Ie. csh #SHELL = /bin/sh -- 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 logan at elandsys.com Thu Apr 10 02:47:40 2014 From: logan at elandsys.com (Loganaden Velvindron) Date: Wed, 9 Apr 2014 09:47:40 -0700 Subject: ED25519 SSHFP in OpenSSH & IETF Message-ID: <20140409164740.GA16000@mx.elandsys.com> Hi All, I've been working on a diff to get SSHFP support for ed25519 in OpenSSH. SM has been working through the IETF process to obtain the SSHFP RR Type number. Despite getting "rough consensus", we still haven't heard anything from the IETF Security Directors for the draft. SM sent a mail asking why it is taking so long, and it appears that his mail was ignored. Please see: http://www.ietf.org/mail-archive/web/ietf/current/msg87189.html This situation is rather unusual, and that makes me wonder what's exactly going on there, as I believe that we've done our homework correctly. Maybe the OpenSSH community needs to get involved, so that we can get work done :-) ? From simon.perreault at viagenie.ca Thu Apr 10 03:22:06 2014 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Wed, 09 Apr 2014 13:22:06 -0400 Subject: ED25519 SSHFP in OpenSSH & IETF In-Reply-To: <20140409164740.GA16000@mx.elandsys.com> References: <20140409164740.GA16000@mx.elandsys.com> Message-ID: <534581BE.8080802@viagenie.ca> Le 2014-04-09 12:47, Loganaden Velvindron a ?crit : > This situation is rather unusual, and that makes me wonder what's > exactly going on there, as I believe that we've done our homework > correctly. UNUSUAL??? The IETF is notorious for its incredible delays. The situation is typical IMHO. Nobody in IETF is accountable for anything, so you rely on people's good intentions. You need to poke the right people, and poke them again, and poke someone who will know how to poke them, etc. etc. etc. > Maybe the OpenSSH community needs to get involved, so that we can > get work done :-) ? If by "get involved" you mean swamping the IETF powers that be with email, that would the wrong way to do it. SM knows how to navigate the IETF waters. Let him do his job. Simon From deraadt at cvs.openbsd.org Thu Apr 10 03:29:23 2014 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Wed, 09 Apr 2014 11:29:23 -0600 Subject: ED25519 SSHFP in OpenSSH & IETF Message-ID: <201404091729.s39HTNPC005427@cvs.openbsd.org> > Le 2014-04-09 12:47, Loganaden Velvindron a ?crit : > > This situation is rather unusual, and that makes me wonder what's > > exactly going on there, as I believe that we've done our homework > > correctly. > > UNUSUAL??? The IETF is notorious for its incredible delays. The > situation is typical IMHO. > > Nobody in IETF is accountable for anything, so you rely on people's good > intentions. You need to poke the right people, and poke them again, and > poke someone who will know how to poke them, etc. etc. etc. > > > Maybe the OpenSSH community needs to get involved, so that we can > > get work done :-) ? > > If by "get involved" you mean swamping the IETF powers that be with > email, that would the wrong way to do it. > > SM knows how to navigate the IETF waters. Let him do his job. Alternatively, come to a realization that SSH is not controlled by the IETF. From djm at mindrot.org Thu Apr 10 09:32:05 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Apr 2014 09:32:05 +1000 (EST) Subject: ED25519 SSHFP in OpenSSH & IETF In-Reply-To: <20140409164740.GA16000@mx.elandsys.com> References: <20140409164740.GA16000@mx.elandsys.com> Message-ID: On Wed, 9 Apr 2014, Loganaden Velvindron wrote: > Maybe the OpenSSH community needs to get involved, so that we can > get work done :-) ? I think "getting involved" will be a matter of us acting unilaterally and just committing support for the new SSHFP code point. -d From deraadt at cvs.openbsd.org Thu Apr 10 09:35:33 2014 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Wed, 9 Apr 2014 17:35:33 -0600 (MDT) Subject: ED25519 SSHFP in OpenSSH & IETF Message-ID: <201404092335.s39NZXNP009312@cvs.openbsd.org> >> Maybe the OpenSSH community needs to get involved, so that we can >> get work done :-) ? > >I think "getting involved" will be a matter of us acting unilaterally >and just committing support for the new SSHFP code point. If that is what it takes to reserve a number these days... It has been done before. From fedor.brunner at azet.sk Thu Apr 10 22:39:34 2014 From: fedor.brunner at azet.sk (Fedor Brunner) Date: Thu, 10 Apr 2014 14:39:34 +0200 Subject: nistp256 preferred over ed25519 Message-ID: <53469106.8020704@azet.sk> Hello, Maybe I'm asking an already answered question, if yes I'm sorry to bother you. Why in default HostKeyAlgorithms settings is ecdsa-sha2-nistp256-cert-v01 at openssh.com preferred over ssh-ed25519-cert-v01 at openssh.com ? For example in default settings for KexAlgorithms the curve25519-sha256 at libssh.org is preferred over ecdh-sha2-nistp256. Fedor Defaults in openssh-6.6p1 HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com, ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com, ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519,ssh-rsa,ssh-dss KexAlgorithms curve25519-sha256 at libssh.org, ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1 From des at des.no Fri Apr 11 07:12:51 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu, 10 Apr 2014 23:12:51 +0200 Subject: immediate "gotcha" in compilation!? 6.6p1 versus openssl 1.0.1g In-Reply-To: <53448EB1.3030100@transbay.net> (Eric Dynamic's message of "Tue, 08 Apr 2014 17:05:05 -0700") References: <53448EB1.3030100@transbay.net> Message-ID: <86lhvcubvw.fsf@nine.des.no> Eric Dynamic writes: > So they released openssl 101g to patch for a hole. One then wishes to > recompile openssh. That's not necessary. OpenSSH doesn't use that part of OpenSSL. DES -- Dag-Erling Sm?rgrav - des at des.no From loganaden at gmail.com Fri Apr 11 19:58:07 2014 From: loganaden at gmail.com (Loganaden Velvindron) Date: Fri, 11 Apr 2014 13:58:07 +0400 Subject: OpenSSH Match directive Message-ID: In the latest release of OpenSSH, when you use only "Match" in sshd_config, all by itself, it causes sshd to stop. /usr/local/sbin/sshd -d One or more attributes required for Match /usr/local/etc/sshd_config line 134: Bad Match condition This wasn't the case in the older releases, and some Mauritian users are complaining as they preferred the old behaviour, which gave a warning. Feedback welcomed. -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From djm at mindrot.org Fri Apr 11 22:38:50 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 11 Apr 2014 22:38:50 +1000 (EST) Subject: OpenSSH Match directive In-Reply-To: References: Message-ID: On Fri, 11 Apr 2014, Loganaden Velvindron wrote: > In the latest release of OpenSSH, > > when you use only "Match" in sshd_config, all by itself, it causes sshd to stop. > > /usr/local/sbin/sshd -d > One or more attributes required for Match > /usr/local/etc/sshd_config line 134: Bad Match condition > > This wasn't the case in the older releases, and some Mauritian users > are complaining as they preferred the old behaviour, which gave a > warning. "Match" without conditions was never meant to work - what does it mean? Should it match everything or nothing? "Match all" is supported and the right way to do it. -d From yves at zioup.com Tue Apr 15 03:21:19 2014 From: yves at zioup.com (Yves Dorfsman) Date: Mon, 14 Apr 2014 11:21:19 -0600 Subject: AuthorizedKeysCommand size issue? Message-ID: <534C190F.1060202@zioup.com> I'm running into issues with AuthorizedKeysCommand when the sum of the size of the public keys become bigger than ~ 12 KB. I created a bash script that runs #!/bin/bash curl -s --compressed http://someurl.example.com/pubkeys/$1 and am getting "error: returned status 23". CURLE_WRITE_ERROR (23): An error occurred when writing received data to a local file, or an error was returned to libcurl from a write callback. Samething with wget, I get an error 3: "File I/O error". -- Yves. From djm at mindrot.org Tue Apr 15 09:52:28 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 Apr 2014 09:52:28 +1000 (EST) Subject: AuthorizedKeysCommand size issue? In-Reply-To: <534C190F.1060202@zioup.com> References: <534C190F.1060202@zioup.com> Message-ID: On Mon, 14 Apr 2014, Yves Dorfsman wrote: > > I'm running into issues with AuthorizedKeysCommand when the sum of the size of > the public keys become bigger than ~ 12 KB. It's easy to determine whether sshd is at fault here. Just replace curl with 'cat' of a >12KB file. > I created a bash script that runs > > #!/bin/bash > curl -s --compressed http://someurl.example.com/pubkeys/$1 this is terrifying. -d From yves at zioup.com Tue Apr 15 10:17:36 2014 From: yves at zioup.com (Yves Dorfsman) Date: Mon, 14 Apr 2014 18:17:36 -0600 Subject: AuthorizedKeysCommand size issue? In-Reply-To: References: <534C190F.1060202@zioup.com> Message-ID: <534C7AA0.3000604@zioup.com> On 2014-04-14 17:52, Damien Miller wrote: > > It's easy to determine whether sshd is at fault here. Just replace > curl with 'cat' of a >12KB file. > It works when doing a cat from a file, it looks more like an issue with the pipe mechanism. For example, this works, regardless of the size of the file: #!/bin/bash curl -s --compressed http://someurl.example.com/pubkeys/$1 >somefile cat somefile >> I created a bash script that runs >> >> #!/bin/bash >> curl -s --compressed http://someurl.example.com/pubkeys/$1 > > this is terrifying. Why? DNS hijacking, man in the middle attack? Risk when the web server is compromised (we are using S3 here)? -- Yves. From djm at mindrot.org Tue Apr 15 10:28:40 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 Apr 2014 10:28:40 +1000 (EST) Subject: AuthorizedKeysCommand size issue? In-Reply-To: <534C7AA0.3000604@zioup.com> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> Message-ID: On Mon, 14 Apr 2014, Yves Dorfsman wrote: > On 2014-04-14 17:52, Damien Miller wrote: > > > > It's easy to determine whether sshd is at fault here. Just replace > > curl with 'cat' of a >12KB file. > > > > It works when doing a cat from a file, it looks more like an issue with the > pipe mechanism. For example, this works, regardless of the size of the file: > > #!/bin/bash > curl -s --compressed http://someurl.example.com/pubkeys/$1 >somefile > cat somefile So curl/wget aren't coping with stdout being non-blocking. Those are bugs in curl and wget. You've got the right workaround, but just don't use a predictable filename (i.e. use mktemp). > > > I created a bash script that runs > > > > > > #!/bin/bash > > > curl -s --compressed http://someurl.example.com/pubkeys/$1 > > > > this is terrifying. > > Why? DNS hijacking, man in the middle attack? Risk when the web server is > compromised (we are using S3 here)? All of the above and more. You've just taken the very small attack surface of reading keys from an authorized_keys file and massively increased it to include DNS, HTTP and the security of the HTTP server (also the security of the network and every router between the sshd and HTTP server if you aren't using HTTPS). -d From ecsd at transbay.net Tue Apr 15 18:27:14 2014 From: ecsd at transbay.net (Eric Dynamic) Date: Tue, 15 Apr 2014 01:27:14 -0700 Subject: raw 6.6p1 versus "ports" openssl 1.0.1g on FreeBSD In-Reply-To: References: <53448EB1.3030100@transbay.net> Message-ID: <534CED62.5000705@transbay.net> Darren Tucker wrote: #SHELL = /bin/sh Ok, that fixed the syntax error, but now I am getting this failure: This is after I re-downloaded FreeBSD's ports tree to get the latest ports/security/openssl (101g) and did a "make install" there; then in my compilation directory "/usr/local/openssh" I end up getting the below: synergy[378]# make -k host-key (cd openbsd-compat && make) gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -L/usr/local/openssl/openssl-1.0.1g -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-all -lssh -lopenbsd-compat -lcrypto -lutil -lz -lcrypt Generating public/private rsa1 key pair. rsa_generate_private_key: key generation failed. *** [host-key] Error code 255 (continuing) 1 error My command history (to have seen the same error no matter what) was 370 1:06 make install 371 1:12 make -k install 373 1:14 make host-key-force 375 1:17 make -k install-nokeys (no error in this case because no keys attempted generation) 378 1:18 make -k host-key I don't know if the command is timing out or cannot create a valid key. Manual attempts at installing openssl, I could not find a compiler-target label that worked (that did not produce one or more of compiler errors, assembler errors, or linker errors) so I gave up and used whatever the FreeBSD ports people gave me. Presumably the openssh compilation is loading against a fresh and valid openssl 1.0.1g library so I'm not faulting that on the first guess. -ecsd From des at des.no Tue Apr 15 23:47:04 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 15 Apr 2014 15:47:04 +0200 Subject: AuthorizedKeysCommand size issue? In-Reply-To: (Damien Miller's message of "Tue, 15 Apr 2014 10:28:40 +1000 (EST)") References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> Message-ID: <867g6qg0x3.fsf@nine.des.no> Damien Miller writes: > Yves Dorfsman writes: > > #!/bin/bash > > curl -s --compressed http://someurl.example.com/pubkeys/$1 >somefile > > cat somefile > So curl/wget aren't coping with stdout being non-blocking. Those are > bugs in curl and wget. You've got the right workaround, but just > don't use a predictable filename (i.e. use mktemp). Shouldn't 'curl ... | cat' suffice? Or even 'echo "$(curl ...)"' DES -- Dag-Erling Sm?rgrav - des at des.no From des at des.no Tue Apr 15 23:51:12 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 15 Apr 2014 15:51:12 +0200 Subject: raw 6.6p1 versus "ports" openssl 1.0.1g on FreeBSD In-Reply-To: <534CED62.5000705@transbay.net> (Eric Dynamic's message of "Tue, 15 Apr 2014 01:27:14 -0700") References: <53448EB1.3030100@transbay.net> <534CED62.5000705@transbay.net> Message-ID: <8638heg0q7.fsf@nine.des.no> Eric Dynamic writes: > Ok, that fixed the syntax error, but now I am getting this failure: > This is after I re-downloaded FreeBSD's ports tree [...] First of all, as previously mentioned, heartbleed does not affect OpenSSH, so there is no need to recompile. Second, if you're on FreeBSD, why not install OpenSSH from ports? Third, I assume the reason why you're trying to compile OpenSSH 6.6p1 manually is that you're running a FreeBSD version that has an older OpenSSH version. You'll be happy to hear that stable/9, stable/10 and head all have 6.6p1 now. DES -- Dag-Erling Sm?rgrav - des at des.no From yves at zioup.com Wed Apr 16 01:19:18 2014 From: yves at zioup.com (Yves Dorfsman) Date: Tue, 15 Apr 2014 09:19:18 -0600 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <867g6qg0x3.fsf@nine.des.no> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> Message-ID: <534D4DF6.3040709@zioup.com> On 2014-04-15 07:47, Dag-Erling Sm?rgrav wrote: > Damien Miller writes: >> Yves Dorfsman writes: >>> #!/bin/bash >>> curl -s --compressed http://someurl.example.com/pubkeys/$1 >somefile >>> cat somefile >> So curl/wget aren't coping with stdout being non-blocking. Those are >> bugs in curl and wget. You've got the right workaround, but just >> don't use a predictable filename (i.e. use mktemp). > > Shouldn't 'curl ... | cat' suffice? Tried that before, it returns an exit code 141. > Or even 'echo "$(curl ...)"' Can you completely prevent echo from interpreting $ sign? -- Yves. From cristian.ionescu-idbohrn at axis.com Wed Apr 16 02:49:57 2014 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 15 Apr 2014 18:49:57 +0200 (CEST) Subject: AuthorizedKeysCommand size issue? In-Reply-To: <534D4DF6.3040709@zioup.com> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> Message-ID: On Tue, 15 Apr 2014, Yves Dorfsman wrote: > On 2014-04-15 07:47, Dag-Erling Sm?rgrav wrote: > > Damien Miller writes: > >> Yves Dorfsman writes: > >>> #!/bin/bash > >>> curl -s --compressed http://someurl.example.com/pubkeys/$1 >somefile > >>> cat somefile > >> So curl/wget aren't coping with stdout being non-blocking. Those are > >> bugs in curl and wget. You've got the right workaround, but just > >> don't use a predictable filename (i.e. use mktemp). > > > > Shouldn't 'curl ... | cat' suffice? > > Tried that before, it returns an exit code 141. `man 1 curl' --compressed (HTTP) Request a compressed response using one of the algorithms curl supports, and save the uncompressed document. If this option is used and the server sends an unsupported encoding, curl will report an error. > > Or even 'echo "$(curl ...)"' > Can you completely prevent echo from interpreting $ sign? What do you mean? "$(curl ...)" will first get expanded (curl command executed) and stdout from curl will be echoed. Cheers, -- Cristian From des at des.no Wed Apr 16 02:57:00 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 15 Apr 2014 18:57:00 +0200 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <534D4DF6.3040709@zioup.com> (Yves Dorfsman's message of "Tue, 15 Apr 2014 09:19:18 -0600") References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> Message-ID: <8661ma7cpv.fsf@nine.des.no> Yves Dorfsman writes: > Dag-Erling Sm?rgrav writes: > > Shouldn't 'curl ... | cat' suffice? > Tried that before, it returns an exit code 141. What returns exit code 141? If the curl command line you're using normally prints the file to stdout, then curl | cat will do exactly the same, cat will buffer it. However, the command line you're using will _not_ print the file to stdout. It will save it in the current working directory, which is most likely /var/empty, which is not writable. You need to add -o- to your curl command line to have it print the file to stdout: curl -s -o- --compressed http://someurl.example.com/pubkeys/$1 > > Or even 'echo "$(curl ...)"' > Can you completely prevent echo from interpreting $ sign? Uh, echo does not interpret the $ sign. The shell does, and you want it to. $() is equivalent to ``, so entire construct is replaced with whatever curl outputs. Note that the double quotes ensure that the entire output is passed to echo as a single argument, rather than split into words, thus preserving whitespace. DES -- Dag-Erling Sm?rgrav - des at des.no From yves at zioup.com Wed Apr 16 02:59:31 2014 From: yves at zioup.com (Yves Dorfsman) Date: Tue, 15 Apr 2014 10:59:31 -0600 Subject: AuthorizedKeysCommand size issue? In-Reply-To: References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> Message-ID: <534D6573.2020809@zioup.com> On 2014-04-15 10:49, Cristian Ionescu-Idbohrn wrote: > > `man 1 curl' > > --compressed > (HTTP) Request a compressed response using one of the algorithms > curl supports, and save the uncompressed document. If this > option is used and the server sends an unsupported encoding, > curl will report an error. > Same error without the --compressed. I originally was compressing the pub keys and was using the apropriate Content-Encoding, which by the way is working with shorter list of keys, but quickly dropped that in order to debug. >>> Or even 'echo "$(curl ...)"' >> Can you completely prevent echo from interpreting $ sign? > > What do you mean? "$(curl ...)" will first get expanded (curl command > executed) and stdout from curl will be echoed. I cannot guarantee that the keys don't include something that looks like an environment variable which echo will expand. -- Yves. From yves at zioup.com Wed Apr 16 03:05:27 2014 From: yves at zioup.com (Yves Dorfsman) Date: Tue, 15 Apr 2014 11:05:27 -0600 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <8661ma7cpv.fsf@nine.des.no> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> <8661ma7cpv.fsf@nine.des.no> Message-ID: <534D66D7.7090803@zioup.com> On 2014-04-15 10:57, Dag-Erling Sm?rgrav wrote: > Yves Dorfsman writes: >> Dag-Erling Sm?rgrav writes: >>> Shouldn't 'curl ... | cat' suffice? >> Tried that before, it returns an exit code 141. > > What returns exit code 141? I suspect bash is returning the exit code from cat. > If the curl command line you're using normally prints the file to > stdout, then curl | cat will do exactly the same, cat will buffer it. I agree, and that's why I tried it early on, I'm not sure where the problem is there. > However, the command line you're using will _not_ print the file to > stdout. No, curl output to stdout by default. > Uh, echo does not interpret the $ sign. The shell does, and you want it > to. Darn, decades of UNIX and I still run into this! I feel terrible... $() is equivalent to ``, so entire construct is replaced with > whatever curl outputs. Note that the double quotes ensure that the > entire output is passed to echo as a single argument, rather than split > into words, thus preserving whitespace. Yes, adding the double quotes around it worked. Thanks. This actually is a very elegant work around, both in terms of speed and security. -- Yves. From cristian.ionescu-idbohrn at axis.com Wed Apr 16 03:13:22 2014 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 15 Apr 2014 19:13:22 +0200 (CEST) Subject: AuthorizedKeysCommand size issue? In-Reply-To: <534D6573.2020809@zioup.com> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> <534D6573.2020809@zioup.com> Message-ID: On Tue, 15 Apr 2014, Yves Dorfsman wrote: > On 2014-04-15 10:49, Cristian Ionescu-Idbohrn wrote: > > > > `man 1 curl' > > > > --compressed > > (HTTP) Request a compressed response using one of the algorithms > > curl supports, and save the uncompressed document. If this > > option is used and the server sends an unsupported encoding, > > curl will report an error. > > > > Same error without the --compressed. I originally was compressing > the pub keys and was using the apropriate Content-Encoding, which by > the way is working with shorter list of keys, but quickly dropped > that in order to debug. What does $1 in: curl -s --compressed http://someurl.example.com/pubkeys/$1 expand to? You may also want to do test a command line where you drop the '-s' option and add '-v -i' instead, to get a hint on what's going on. Also, follow Dag-Erling's recommendation to use the '-o-'. > >>> Or even 'echo "$(curl ...)"' > >> Can you completely prevent echo from interpreting $ sign? > > > > What do you mean? "$(curl ...)" will first get expanded (curl > > command executed) and stdout from curl will be echoed. > > I cannot guarantee that the keys don't include something that looks > like an environment variable which echo will expand. No worries. "$(curl ...)" is expanded just once. Cheers, -- Cristian From des at des.no Wed Apr 16 03:56:00 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 15 Apr 2014 19:56:00 +0200 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <534D66D7.7090803@zioup.com> (Yves Dorfsman's message of "Tue, 15 Apr 2014 11:05:27 -0600") References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> <8661ma7cpv.fsf@nine.des.no> <534D66D7.7090803@zioup.com> Message-ID: <861twy79zj.fsf@nine.des.no> Yves Dorfsman writes: > Dag-Erling Sm?rgrav writes: > > What returns exit code 141? > I suspect bash is returning the exit code from cat. What OS are you on? It is impossible for cat(1) on either Linux (GNU coreutils) or BSD to return anything other than 0 or 1. DES -- Dag-Erling Sm?rgrav - des at des.no From dkg at fifthhorseman.net Wed Apr 16 04:31:42 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 15 Apr 2014 14:31:42 -0400 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <867g6qg0x3.fsf@nine.des.no> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> Message-ID: <534D7B0E.2040908@fifthhorseman.net> On 04/15/2014 09:47 AM, Dag-Erling Sm?rgrav wrote: > Or even 'echo "$(curl ...)"' This is potentially dangerous if curl produces a string that starts with a hyphen ("-"); in this case, echo will interpret the string as a set of option flags instead of as an argument to be repeated. You might prefer: printf "%s "$(curl ...)" But i do also share damien's general automatic aversion to using curl in this context, *especially* over cleartext HTTP. yikes! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From des at des.no Wed Apr 16 04:39:05 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 15 Apr 2014 20:39:05 +0200 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <534D7B0E.2040908@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 15 Apr 2014 14:31:42 -0400") References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D7B0E.2040908@fifthhorseman.net> Message-ID: <86wqeq5tfa.fsf@nine.des.no> Daniel Kahn Gillmor writes: > Dag-Erling Sm?rgrav writes: > > Or even 'echo "$(curl ...)"' > This is potentially dangerous if curl produces a string that starts with > a hyphen ("-"); in this case, echo will interpret the string as a set of > option flags instead of as an argument to be repeated. Technically, you're right. In practice, it doesn't matter. The worst that will happen is that echo will print something other than the contents of the file, and even that can only happen if the file contains only "-n" or "-e", neither of which is a valid authorized_keys file. DES -- Dag-Erling Sm?rgrav - des at des.no From lists at eitanadler.com Wed Apr 16 06:10:42 2014 From: lists at eitanadler.com (Eitan Adler) Date: Tue, 15 Apr 2014 13:10:42 -0700 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <861twy79zj.fsf@nine.des.no> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> <8661ma7cpv.fsf@nine.des.no> <534D66D7.7090803@zioup.com> <861twy79zj.fsf@nine.des.no> Message-ID: On 15 April 2014 10:56, Dag-Erling Sm?rgrav wrote: > Yves Dorfsman writes: >> Dag-Erling Sm?rgrav writes: >> > What returns exit code 141? >> I suspect bash is returning the exit code from cat. > > What OS are you on? It is impossible for cat(1) on either Linux (GNU > coreutils) or BSD to return anything other than 0 or 1. It can when killed by a signal: On FreeBSD: [10004 eitan at gravity (100%) ~ ]%cat /dev/zero [1] 29728 terminated cat /dev/zero [10005 eitan at gravity (100%) ~ !143!]%echo $? 143 > > DES > -- > Dag-Erling Sm?rgrav - des at des.no > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Eitan Adler From des at des.no Wed Apr 16 20:23:32 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed, 16 Apr 2014 12:23:32 +0200 Subject: AuthorizedKeysCommand size issue? In-Reply-To: (Eitan Adler's message of "Tue, 15 Apr 2014 13:10:42 -0700") References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> <8661ma7cpv.fsf@nine.des.no> <534D66D7.7090803@zioup.com> <861twy79zj.fsf@nine.des.no> Message-ID: <86sipd609n.fsf@nine.des.no> Eitan Adler writes: > Dag-Erling Sm?rgrav writes: > > What OS are you on? It is impossible for cat(1) on either Linux > > (GNU coreutils) or BSD to return anything other than 0 or 1. > It can when killed by a signal: Does the shell report signal + 128 when a process is killed by a signal? That's unfortunate, as 141 is a perfectly valid exit code (0 - 255). But if that is the case, 141 is SIGPIPE. DES -- Dag-Erling Sm?rgrav - des at des.no From naddy at mips.inka.de Thu Apr 17 00:54:19 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Wed, 16 Apr 2014 14:54:19 +0000 (UTC) Subject: AuthorizedKeysCommand size issue? References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> <8661ma7cpv.fsf@nine.des.no> <534D66D7.7090803@zioup.com> <861twy79zj.fsf@nine.des.no> <86sipd609n.fsf@nine.des.no> Message-ID: On 2014-04-16, Dag-Erling Sm?rgrav wrote: > Does the shell report signal + 128 when a process is killed by a signal? Of course it does. It's been like this since (at least) the V7 Bourne shell. > That's unfortunate, as 141 is a perfectly valid exit code (0 - 255). Don't use exit codes >127. -- Christian "naddy" Weisgerber naddy at mips.inka.de From scott_n at xypro.com Thu Apr 17 01:22:10 2014 From: scott_n at xypro.com (Scott Neugroschl) Date: Wed, 16 Apr 2014 15:22:10 +0000 Subject: AuthorizedKeysCommand size issue? In-Reply-To: References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> <8661ma7cpv.fsf@nine.des.no> <534D66D7.7090803@zioup.com> <861twy79zj.fsf@nine.des.no> <86sipd609n.fsf@nine.des.no> Message-ID: I'm assuming 141 is SIGPIPE (128 indicating signal + SIGPIPE). I'm guessing cat dies because nonblack on the pipe? And once cat dies, curl dies with SIGPIPE. -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Christian Weisgerber Sent: Wednesday, April 16, 2014 7:54 AM To: openssh-unix-dev at mindrot.org Subject: Re: AuthorizedKeysCommand size issue? On 2014-04-16, Dag-Erling Sm?rgrav wrote: > Does the shell report signal + 128 when a process is killed by a signal? Of course it does. It's been like this since (at least) the V7 Bourne shell. > That's unfortunate, as 141 is a perfectly valid exit code (0 - 255). Don't use exit codes >127. -- Christian "naddy" Weisgerber naddy at mips.inka.de _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From yves at zioup.com Thu Apr 17 01:38:19 2014 From: yves at zioup.com (Yves Dorfsman) Date: Wed, 16 Apr 2014 09:38:19 -0600 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <534D7B0E.2040908@fifthhorseman.net> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D7B0E.2040908@fifthhorseman.net> Message-ID: <534EA3EB.9050205@zioup.com> On 2014-04-15 12:31, Daniel Kahn Gillmor wrote: > On 04/15/2014 09:47 AM, Dag-Erling Sm?rgrav wrote: >> Or even 'echo "$(curl ...)"' > > This is potentially dangerous if curl produces a string that starts with > a hyphen ("-"); in this case, echo will interpret the string as a set of > option flags instead of as an argument to be repeated. > > You might prefer: > > printf "%s "$(curl ...)" > > But i do also share damien's general automatic aversion to using curl in > this context, *especially* over cleartext HTTP. yikes! > I appreciate the concern, but: - this is using S3, so https, - the only access anybody but Amazon has to S3 is upload/download content to it. If somebody get hold of our keys to access S3, they can actually shutdown our instances (VMs) anyway. I'm sure the S3 servers have potential vulnerabilities, but this is way less likely than with an average web server with ssh access exposed to the net. - this would be strictly from AWS instances using DNS from Amazon (who owns S3), and DNS is done over AWS private network, which means it is very unlikely that somebody will hijack DNS -- Yves. From parke.nexus at gmail.com Thu Apr 17 08:57:41 2014 From: parke.nexus at gmail.com (Parke) Date: Wed, 16 Apr 2014 15:57:41 -0700 Subject: Undocumented sftp put -r quirk: Couldn't canonicalize: No such file or directory Message-ID: Hi, As of OpenSSH 6.5 on Ubuntu 14.04 (package version 1:6.5p1-6), there appears to be an undocumented requirement for the sftp "put -r" command. In order to "put -r foo", a remote directory named "foo" must already exist. If a remote directory named foo does not exist, the following (confusing) error message is displayed: sftp> put -r foo Uploading foo/ to /home/user/test/foo Couldn't canonicalize: No such file or directory Unable to canonicalize path "/home/parke/test/foo" I recommend that this requirement be documented in the sftp manpage. I can draft language, if needed. The error message could also be more helpful. For example: "Required remote directory "foo" does not exist." There is related discussion on stack exchange: http://unix.stackexchange.com/questions/7004/uploading-directories-with-sftp http://stackoverflow.com/questions/17477226/what-cause-the-error-couldnt-canonicalise-no-such-file-or-directory-in-sftp Thanks! -Parke From mangoo at wpkg.org Thu Apr 17 11:20:28 2014 From: mangoo at wpkg.org (Tomasz Chmielewski) Date: Thu, 17 Apr 2014 02:20:28 +0100 Subject: ssh tunnel - can I set remote bind address? Message-ID: <20140417022028.65d1dde0@s9> With ssh tunnel (-L option), is it possible to set _remote_ bind address? Say, I have a remote SSH server with two IP addresses, 1.1.1.1 and 2.2.2.2. I would like to make sure that any outgoing connections to 3.3.3.3 will be made from 2.2.2.2: ssh client ---> 1.1.1.1 ssh server 2.2.2.2 >--- 3.3.3.3 Pseudo "--remote-bind" command here to illustrate what I mean: ssh -N -L 4444:3.3.3.3:4444 --remote-bind 2.2.2.2 1.1.1.1 If not possible, are there any workarounds? -- Tomasz Chmielewski http://wpkg.org From kop at meme.com Thu Apr 17 12:11:01 2014 From: kop at meme.com (Karl O. Pinc) Date: Wed, 16 Apr 2014 21:11:01 -0500 Subject: ssh tunnel - can I set remote bind address? In-Reply-To: <20140417022028.65d1dde0@s9> (from mangoo@wpkg.org on Wed Apr 16 20:20:28 2014) References: <20140417022028.65d1dde0@s9> Message-ID: <1397700661.9934.6@slate> On 04/16/2014 08:20:28 PM, Tomasz Chmielewski wrote: > With ssh tunnel (-L option), is it possible to set _remote_ bind > address? Have you looked at -R? Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein From peter at stuge.se Thu Apr 17 12:53:54 2014 From: peter at stuge.se (Peter Stuge) Date: Thu, 17 Apr 2014 04:53:54 +0200 Subject: ssh tunnel - can I set remote bind address? In-Reply-To: <20140417022028.65d1dde0@s9> References: <20140417022028.65d1dde0@s9> Message-ID: <20140417025354.1475.qmail@stuge.se> Tomasz Chmielewski wrote: > With ssh tunnel (-L option), is it possible to set _remote_ bind > address? No. > If not possible, are there any workarounds? Routing table on the server. //Peter From djm at mindrot.org Thu Apr 17 13:44:58 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 17 Apr 2014 13:44:58 +1000 (EST) Subject: ssh tunnel - can I set remote bind address? In-Reply-To: <20140417022028.65d1dde0@s9> References: <20140417022028.65d1dde0@s9> Message-ID: On Thu, 17 Apr 2014, Tomasz Chmielewski wrote: > With ssh tunnel (-L option), is it possible to set _remote_ bind > address? Unfortunately the SSH protocol doesn't have any way to express a request to bind an outgoing forwarded TCP connection to a particular host/port. -d From djm at mindrot.org Thu Apr 17 13:45:48 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 17 Apr 2014 13:45:48 +1000 (EST) Subject: Undocumented sftp put -r quirk: Couldn't canonicalize: No such file or directory In-Reply-To: References: Message-ID: On Wed, 16 Apr 2014, Parke wrote: > Hi, > > As of OpenSSH 6.5 on Ubuntu 14.04 (package version 1:6.5p1-6), there > appears to be an undocumented requirement for the sftp "put -r" > command. In order to "put -r foo", a remote directory named "foo" > must already exist. Could you file a bug for this at https://bugzilla.mindrot.org/ ? IMO the directory should be created if it doesn't exist, just like "cp -r" does. -d From parke.nexus at gmail.com Thu Apr 17 16:59:36 2014 From: parke.nexus at gmail.com (Parke) Date: Wed, 16 Apr 2014 23:59:36 -0700 Subject: Undocumented sftp put -r quirk: Couldn't canonicalize: No such file or directory In-Reply-To: References: Message-ID: On Wed, Apr 16, 2014 at 8:45 PM, Damien Miller wrote: > Could you file a bug for this at https://bugzilla.mindrot.org/ ? Done. https://bugzilla.mindrot.org/show_bug.cgi?id=2230 -Parke From christian.kandeler at digia.com Thu Apr 17 17:08:35 2014 From: christian.kandeler at digia.com (Christian Kandeler) Date: Thu, 17 Apr 2014 09:08:35 +0200 Subject: AuthorizedKeysCommand size issue? In-Reply-To: <86sipd609n.fsf@nine.des.no> References: <534C190F.1060202@zioup.com> <534C7AA0.3000604@zioup.com> <867g6qg0x3.fsf@nine.des.no> <534D4DF6.3040709@zioup.com> <8661ma7cpv.fsf@nine.des.no> <534D66D7.7090803@zioup.com> <861twy79zj.fsf@nine.des.no> <86sipd609n.fsf@nine.des.no> Message-ID: <534F7DF3.6040609@digia.com> On 04/16/2014 12:23 PM, Dag-Erling Sm?rgrav wrote: > Eitan Adler writes: >> Dag-Erling Sm?rgrav writes: >>> What OS are you on? It is impossible for cat(1) on either Linux >>> (GNU coreutils) or BSD to return anything other than 0 or 1. >> It can when killed by a signal: > > Does the shell report signal + 128 when a process is killed by a signal? > That's unfortunate, as 141 is a perfectly valid exit code (0 - 255). > But if that is the case, 141 is SIGPIPE. Isn't that behavior pretty much required by POSIX? "The exit status of a command that terminated because it received a signal shall be reported as greater than 128." Christian From phil.pennock at globnix.org Thu Apr 17 17:15:57 2014 From: phil.pennock at globnix.org (Phil Pennock) Date: Thu, 17 Apr 2014 03:15:57 -0400 Subject: OpenSSH 6.4, "ssh-add -l", output to non-tty Message-ID: <20140417071557.GA63713@redoubt.spodhuis.org> This one has me perplexed. OpenSSH6.4p1 on a FreeBSD 7 box (I know it's old; it's being replaced this month). I can't spot anything changed in OpenSSH commit logs or git blame of the current file. I ssh into the box from a system with OpenSSH6.6p1 and three keys loaded, RSA, ECDSA and ED25519. As expected, key_from_blob and key_fingerprint complain about the ED25519 key in the agent, because they can't handle it. Not a problem. However, in this scenario, "ssh-add -l" will only produce output to stdout if stdout is a tty. "ssh-add -L" reliably produces output to stdout. "ssh-add -l" reliably produces output to stdout _unless_ it can't parse one of the blobs from the agent. ktrace outputs of the working and non-working scenarios below. As you can see, in the broken scenario there's no I/O to stdout. Can anyone explain what's going on, please? -Phil % ktrace ssh-add -l 2>/dev/null 3072 8b:c1:ae:d1:48:5d:a1:c6:1b:3d:50:e1:6b:cd:65:32 /home/pdp/.ssh/id_rsa (RSA) 521 ee:2e:72:bc:53:6d:c2:57:42:2a:3d:e3:67:85:27:a6 /home/pdp/.ssh/id_ecdsa (ECDSA) % kdump |less ----------------------------8< cut here >8------------------------------ 63697 ssh-add CALL socket(PF_LOCAL,SOCK_STREAM,0) 63697 ssh-add RET socket 3 63697 ssh-add CALL fcntl(0x3,F_SETFD,FD_CLOEXEC) 63697 ssh-add RET fcntl 0 63697 ssh-add CALL connect(0x3,0x7fffffffdd80,0x6a) 63697 ssh-add NAMI "/tmp/ssh-fEfqnn0cp4/agent.63353" 63697 ssh-add RET connect 0 63697 ssh-add CALL write(0x3,0x7fffffffd930,0x4) [... ssh-agent communications, reads back keys, etc ] 63697 ssh-add CALL read(0x3,0x7fffffffd930,0x2d8) 63697 ssh-add GIO fd 3 read 728 bytes [...] 63697 ssh-add RET read 728/0x2d8 63697 ssh-add CALL fstat(0x1,0x7fffffffd420) 63697 ssh-add RET fstat 0 63697 ssh-add CALL ioctl(0x1,TIOCGETA,0x7fffffffd480) 63697 ssh-add RET ioctl 0 63697 ssh-add CALL write(0x1,0x80202c000,0x51) 63697 ssh-add GIO fd 1 wrote 81 bytes "3072 8b:c1:ae:d1:48:5d:a1:c6:1b:3d:50:e1:6b:cd:65:32 /home/pdp/.ssh/id_rsa (RSA) " 63697 ssh-add RET write 81/0x51 63697 ssh-add CALL write(0x1,0x80202c000,0x54) 63697 ssh-add GIO fd 1 wrote 84 bytes "521 ee:2e:72:bc:53:6d:c2:57:42:2a:3d:e3:67:85:27:a6 /home/pdp/.ssh/id_ecdsa (ECDSA) " 63697 ssh-add RET write 84/0x54 63697 ssh-add CALL write(0x2,0x7fffffffd7f0,0x2f) 63697 ssh-add GIO fd 2 wrote 47 bytes "key_from_blob: remaining bytes in key blob 36\r " 63697 ssh-add RET write 47/0x2f 63697 ssh-add CALL write(0x2,0x7fffffffd880,0x32) 63697 ssh-add GIO fd 2 wrote 50 bytes "key_fingerprint: null from key_fingerprint_raw()\r " 63697 ssh-add RET write 50/0x32 63697 ssh-add CALL exit(0xff) ----------------------------8< cut here >8------------------------------ % ktrace ssh-add -l 2>/dev/null | cat ----------------------------8< cut here >8------------------------------ 64004 ssh-add CALL socket(PF_LOCAL,SOCK_STREAM,0) 64004 ssh-add RET socket 3 64004 ssh-add CALL fcntl(0x3,F_SETFD,FD_CLOEXEC) 64004 ssh-add RET fcntl 0 64004 ssh-add CALL connect(0x3,0x7fffffffdd90,0x6a) 64004 ssh-add NAMI "/tmp/ssh-74wsYwRh3v/agent.62945" 64004 ssh-add RET connect 0 64004 ssh-add CALL write(0x3,0x7fffffffd940,0x4) [... ssh-agent communications, reads back keys, etc ] 64004 ssh-add CALL read(0x3,0x7fffffffd940,0x2d8) 64004 ssh-add GIO fd 3 read 728 bytes [...] 64004 ssh-add RET read 728/0x2d8 64004 ssh-add CALL fstat(0x1,0x7fffffffd430) 64004 ssh-add RET fstat 0 64004 ssh-add CALL write(0x2,0x7fffffffd800,0x2f) 64004 ssh-add GIO fd 2 wrote 47 bytes "key_from_blob: remaining bytes in key blob 36\r " 64004 ssh-add RET write 47/0x2f 64004 ssh-add CALL write(0x2,0x7fffffffd890,0x32) 64004 ssh-add GIO fd 2 wrote 50 bytes "key_fingerprint: null from key_fingerprint_raw()\r " 64004 ssh-add RET write 50/0x32 64004 ssh-add CALL exit(0xff) ----------------------------8< cut here >8------------------------------ From mangoo at wpkg.org Thu Apr 17 18:35:47 2014 From: mangoo at wpkg.org (Tomasz Chmielewski) Date: Thu, 17 Apr 2014 09:35:47 +0100 Subject: ssh tunnel - can I set remote bind address? In-Reply-To: <20140417025354.1475.qmail@stuge.se> References: <20140417022028.65d1dde0@s9> <20140417025354.1475.qmail@stuge.se> Message-ID: <20140417093547.1f4a946b@s9> On Thu, 17 Apr 2014 04:53:54 +0200 Peter Stuge wrote: > Tomasz Chmielewski wrote: > > With ssh tunnel (-L option), is it possible to set _remote_ bind > > address? > > No. > > > If not possible, are there any workarounds? > > Routing table on the server. OK, thanks. In case someone was looking for a similar issue, I've used this on the server (Linux): iptables -t nat -I POSTROUTING -o eth0 -d 3.3.3.3 -j SNAT --to 2.2.2.2 -- Tomasz Chmielewski http://wpkg.org From phil.pennock at globnix.org Thu Apr 17 19:06:19 2014 From: phil.pennock at globnix.org (Phil Pennock) Date: Thu, 17 Apr 2014 05:06:19 -0400 Subject: OpenSSH 6.4, "ssh-add -l", output to non-tty In-Reply-To: <20140417071557.GA63713@redoubt.spodhuis.org> References: <20140417071557.GA63713@redoubt.spodhuis.org> Message-ID: <20140417090619.GA66055@redoubt.spodhuis.org> On 2014-04-17 at 03:15 -0400, Phil Pennock wrote: > However, in this scenario, "ssh-add -l" will only produce output to > stdout if stdout is a tty. Brain engaged. stdio buffering, not in line-buffering mode, not flushed before `fatal()` call. Obvious in retrospect. Bug? -Phil From loganaden at gmail.com Thu Apr 17 19:53:38 2014 From: loganaden at gmail.com (Loganaden Velvindron) Date: Thu, 17 Apr 2014 13:53:38 +0400 Subject: Undocumented sftp put -r quirk: Couldn't canonicalize: No such file or directory In-Reply-To: References: Message-ID: On Thursday, April 17, 2014, Parke wrote: > On Wed, Apr 16, 2014 at 8:45 PM, Damien Miller wrote: >> Could you file a bug for this at https://bugzilla.mindrot.org/ ? >x > Done. > > https://bugzilla.mindrot.org/show_bug.cgi?id=2230 The issue isn't present on native openssh in current. > > -Parke > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From loganaden at gmail.com Thu Apr 17 20:12:10 2014 From: loganaden at gmail.com (Loganaden Velvindron) Date: Thu, 17 Apr 2014 14:12:10 +0400 Subject: Undocumented sftp put -r quirk: Couldn't canonicalize: No such file or directory In-Reply-To: References: Message-ID: On Thursday, April 17, 2014, Loganaden Velvindron wrote: > > > On Thursday, April 17, 2014, Parke wrote: >> On Wed, Apr 16, 2014 at 8:45 PM, Damien Miller wrote: >>> Could you file a bug for this at https://bugzilla.mindrot.org/ ? >>x >> Done. >> >> https://bugzilla.mindrot.org/i_bug.cgi?id=2230 > > The issue isn't present on native openssh in current. > The issue isn't present on the portable -current as well. I'll test it on my ubuntu machine, once I get back home. > >> >> -Parke >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > -- > This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. > > > > > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From peter at stuge.se Thu Apr 17 20:46:14 2014 From: peter at stuge.se (Peter Stuge) Date: Thu, 17 Apr 2014 12:46:14 +0200 Subject: OpenSSH 6.4, "ssh-add -l", output to non-tty In-Reply-To: <20140417090619.GA66055@redoubt.spodhuis.org> References: <20140417071557.GA63713@redoubt.spodhuis.org> <20140417090619.GA66055@redoubt.spodhuis.org> Message-ID: <20140417104614.8389.qmail@stuge.se> Phil Pennock wrote: > stdio buffering, not in line-buffering mode, not flushed before > `fatal()` call. > > Obvious in retrospect. Bug? I think it seems good to add two fflush() calls to fatal(). //Peter From phil.pennock at globnix.org Fri Apr 18 02:32:57 2014 From: phil.pennock at globnix.org (Phil Pennock) Date: Thu, 17 Apr 2014 12:32:57 -0400 Subject: OpenSSH 6.4, "ssh-add -l", output to non-tty In-Reply-To: <20140417104614.8389.qmail@stuge.se> References: <20140417071557.GA63713@redoubt.spodhuis.org> <20140417090619.GA66055@redoubt.spodhuis.org> <20140417104614.8389.qmail@stuge.se> Message-ID: <20140417163257.GA71270@redoubt.spodhuis.org> On 2014-04-17 at 12:46 +0200, Peter Stuge wrote: > Phil Pennock wrote: > > stdio buffering, not in line-buffering mode, not flushed before > > `fatal()` call. > > > > Obvious in retrospect. Bug? > > I think it seems good to add two fflush() calls to fatal(). What happens if fatal() is called from some place in a network speaker where the caller has decided to exit immediately for security reasons? (You might be right: this is an honest question from ignorance on my part.) It looks like openssh is already doing portability/brokenness checks to end up with a working setlinebuf() call. Switching ssh-add to be line-buffered when working with key conversion formats might conceivably affect broken tools, but it should be safe for list_identities() to do so. But this assumes that the remote agent will always have older, more broadly supported, key formats loaded first; true for a single invocation of 'ssh-add' loading one set of keys in default order, but buggy. It might be better to instead give key_fingerprint() a flag to avoid fatal()? diff --git a/ssh-add.c b/ssh-add.c index 3421452..9bf5f21 100644 --- a/ssh-add.c +++ b/ssh-add.c @@ -324,6 +324,9 @@ list_identities(AuthenticationConnection *ac, int do_fp) int had_identities = 0; int version; + /* key_fingerprint() can fatal() */ + setlinebuf(stdout); + for (version = 1; version <= 2; version++) { for (key = ssh_get_first_identity(ac, &comment, version); key != NULL; From imorgan at nas.nasa.gov Fri Apr 18 04:47:10 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 17 Apr 2014 11:47:10 -0700 Subject: Undocumented sftp put -r quirk: Couldn't canonicalize: No such file or directory In-Reply-To: References: Message-ID: <20140417184710.GA23852@linux124.nas.nasa.gov> On Thu, Apr 17, 2014 at 13:45:48 +1000, Damien Miller wrote: > On Wed, 16 Apr 2014, Parke wrote: > > > Hi, > > > > As of OpenSSH 6.5 on Ubuntu 14.04 (package version 1:6.5p1-6), there > > appears to be an undocumented requirement for the sftp "put -r" > > command. In order to "put -r foo", a remote directory named "foo" > > must already exist. > > Could you file a bug for this at https://bugzilla.mindrot.org/ ? > > IMO the directory should be created if it doesn't exist, just like > "cp -r" does. > Actually, bz#2150 already exists regardint this issue. -- Iain Morgan From djm at mindrot.org Sun Apr 20 17:14:08 2014 From: djm at mindrot.org (Damien Miller) Date: Sun, 20 Apr 2014 17:14:08 +1000 (EST) Subject: bad bignum encoding for curve25519-sha256@libssh.org Message-ID: Hi, So I screwed up when writing the support for the curve25519 KEX method that doesn't depend on OpenSSL's BIGNUM type - a bug in my code left leading zero bytes where they should have been skipped. The impact of this is that OpenSSH 6.5 and 6.6 will fail during key exchange with a peer that implements curve25519-sha256 at libssh.org properly about 0.2% of the time (one in every 512ish connections). We've fixed this for OpenSSH 6.7 by avoiding the curve25519-sha256 key exchange for previous versions, but I'd recommend distributors of OpenSSH apply this patch so the affected code doesn't become too entrenched in LTS releases. The patch fixes the bug and makes OpenSSH identify itself as 6.6.1 so as to distinguish itself from the incorrect versions so the compatibility code to disable the affected KEX isn't activated. I've committed this on the 6.6 branch too. Apologies for the hassle. -d Index: version.h =================================================================== RCS file: /var/cvs/openssh/version.h,v retrieving revision 1.82 diff -u -p -r1.82 version.h --- version.h 27 Feb 2014 23:01:54 -0000 1.82 +++ version.h 20 Apr 2014 03:35:15 -0000 @@ -1,6 +1,6 @@ /* $OpenBSD: version.h,v 1.70 2014/02/27 22:57:40 djm Exp $ */ -#define SSH_VERSION "OpenSSH_6.6" +#define SSH_VERSION "OpenSSH_6.6.1" #define SSH_PORTABLE "p1" #define SSH_RELEASE SSH_VERSION SSH_PORTABLE Index: compat.c =================================================================== RCS file: /var/cvs/openssh/compat.c,v retrieving revision 1.82 retrieving revision 1.85 diff -u -p -r1.82 -r1.85 --- compat.c 31 Dec 2013 01:25:41 -0000 1.82 +++ compat.c 20 Apr 2014 03:33:59 -0000 1.85 @@ -95,6 +95,9 @@ compat_datafellows(const char *version) { "Sun_SSH_1.0*", SSH_BUG_NOREKEY|SSH_BUG_EXTEOF}, { "OpenSSH_4*", 0 }, { "OpenSSH_5*", SSH_NEW_OPENSSH|SSH_BUG_DYNAMIC_RPORT}, + { "OpenSSH_6.6.1*", SSH_NEW_OPENSSH}, + { "OpenSSH_6.5*," + "OpenSSH_6.6*", SSH_NEW_OPENSSH|SSH_BUG_CURVE25519PAD}, { "OpenSSH*", SSH_NEW_OPENSSH }, { "*MindTerm*", 0 }, { "2.1.0*", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| @@ -251,7 +254,6 @@ compat_cipher_proposal(char *cipher_prop return cipher_prop; } - char * compat_pkalg_proposal(char *pkalg_prop) { @@ -263,5 +265,18 @@ compat_pkalg_proposal(char *pkalg_prop) if (*pkalg_prop == '\0') fatal("No supported PK algorithms found"); return pkalg_prop; +} + +char * +compat_kex_proposal(char *kex_prop) +{ + if (!(datafellows & SSH_BUG_CURVE25519PAD)) + return kex_prop; + debug2("%s: original KEX proposal: %s", __func__, kex_prop); + kex_prop = filter_proposal(kex_prop, "curve25519-sha256 at libssh.org"); + debug2("%s: compat KEX proposal: %s", __func__, kex_prop); + if (*kex_prop == '\0') + fatal("No supported key exchange algorithms found"); + return kex_prop; } Index: compat.h =================================================================== RCS file: /var/cvs/openssh/compat.h,v retrieving revision 1.42 retrieving revision 1.43 diff -u -p -r1.42 -r1.43 --- compat.h 31 Dec 2013 01:25:41 -0000 1.42 +++ compat.h 20 Apr 2014 03:25:31 -0000 1.43 @@ -59,6 +59,7 @@ #define SSH_BUG_RFWD_ADDR 0x02000000 #define SSH_NEW_OPENSSH 0x04000000 #define SSH_BUG_DYNAMIC_RPORT 0x08000000 +#define SSH_BUG_CURVE25519PAD 0x10000000 void enable_compat13(void); void enable_compat20(void); @@ -66,6 +67,7 @@ void compat_datafellows(const char * int proto_spec(const char *); char *compat_cipher_proposal(char *); char *compat_pkalg_proposal(char *); +char *compat_kex_proposal(char *); extern int compat13; extern int compat20; Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.448 retrieving revision 1.453 diff -u -p -r1.448 -r1.453 --- sshd.c 26 Feb 2014 23:20:08 -0000 1.448 +++ sshd.c 20 Apr 2014 03:28:41 -0000 1.453 @@ -2462,6 +2438,9 @@ do_ssh2_kex(void) if (options.kex_algorithms != NULL) myproposal[PROPOSAL_KEX_ALGS] = options.kex_algorithms; + myproposal[PROPOSAL_KEX_ALGS] = compat_kex_proposal( + myproposal[PROPOSAL_KEX_ALGS]); + if (options.rekey_limit || options.rekey_interval) packet_set_rekey_limits((u_int32_t)options.rekey_limit, (time_t)options.rekey_interval); Index: sshconnect2.c =================================================================== RCS file: /var/cvs/openssh/sshconnect2.c,v retrieving revision 1.197 retrieving revision 1.199 diff -u -p -r1.197 -r1.199 --- sshconnect2.c 4 Feb 2014 00:20:16 -0000 1.197 +++ sshconnect2.c 20 Apr 2014 03:25:31 -0000 1.199 @@ -195,6 +196,8 @@ ssh_kex2(char *host, struct sockaddr *ho } if (options.kex_algorithms != NULL) myproposal[PROPOSAL_KEX_ALGS] = options.kex_algorithms; + myproposal[PROPOSAL_KEX_ALGS] = compat_kex_proposal( + myproposal[PROPOSAL_KEX_ALGS]); if (options.rekey_limit || options.rekey_interval) packet_set_rekey_limits((u_int32_t)options.rekey_limit, Index: bufaux.c =================================================================== RCS file: /var/cvs/openssh/bufaux.c,v retrieving revision 1.62 retrieving revision 1.63 diff -u -p -r1.62 -r1.63 --- bufaux.c 4 Feb 2014 00:20:15 -0000 1.62 +++ bufaux.c 20 Apr 2014 03:24:50 -0000 1.63 @@ -1,4 +1,4 @@ -/* $OpenBSD: bufaux.c,v 1.56 2014/02/02 03:44:31 djm Exp $ */ +/* $OpenBSD: bufaux.c,v 1.57 2014/04/16 23:22:45 djm Exp $ */ /* * Author: Tatu Ylonen * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland @@ -372,6 +372,9 @@ buffer_put_bignum2_from_string(Buffer *b if (l > 8 * 1024) fatal("%s: length %u too long", __func__, l); + /* Skip leading zero bytes */ + for (; l > 0 && *s == 0; l--, s++) + ; p = buf = xmalloc(l + 1); /* * If most significant bit is set then prepend a zero byte to From mancha1 at zoho.com Mon Apr 21 04:26:58 2014 From: mancha1 at zoho.com (mancha) Date: Sun, 20 Apr 2014 18:26:58 +0000 Subject: bad bignum encoding for curve25519-sha256@libssh.org In-Reply-To: References: Message-ID: <20140420182658.GC29150@zoho.com> On Sun, Apr 20, 2014 at 05:14:08PM +1000, Damien Miller wrote: > Hi, > > The patch fixes the bug and makes OpenSSH identify itself as 6.6.1 so as > to distinguish itself from the incorrect versions so the compatibility > code to disable the affected KEX isn't activated. Thanks for the patch. I can provide independent confirmation it fixes things. I got 0 failures during key exchange post-patch using my custom KEX checker (built against libssl). Pre-patch I was experiencing about a 0.17% failure rate. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From aris at 0xbadc0de.be Tue Apr 22 03:58:30 2014 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Mon, 21 Apr 2014 19:58:30 +0200 Subject: bad bignum encoding for curve25519-sha256@libssh.org In-Reply-To: <20140420182658.GC29150@zoho.com> References: <20140420182658.GC29150@zoho.com> Message-ID: <53555C46.9040304@0xbadc0de.be> Le 20/04/14 20:26, mancha a ?crit : > On Sun, Apr 20, 2014 at 05:14:08PM +1000, Damien Miller wrote: >> Hi, >> >> The patch fixes the bug and makes OpenSSH identify itself as 6.6.1 so as >> to distinguish itself from the incorrect versions so the compatibility >> code to disable the affected KEX isn't activated. > > Thanks for the patch. I can provide independent confirmation it fixes > things. I got 0 failures during key exchange post-patch using my > custom KEX checker (built against libssl). Pre-patch I was experiencing > about a 0.17% failure rate. > > --mancha > > A libssh contributor noticed this as well. We'll introduce the same workaround as OpenSSH to avoid interoperability problems. Aris From djm at mindrot.org Tue Apr 22 17:33:59 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 22 Apr 2014 17:33:59 +1000 (EST) Subject: heads up: tcpwrappers support going away Message-ID: Hi, This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed. Removing it reduces the amount of code in the 'hot' pre-authentication path in sshd and rids us of a dependency. -d From plautrba at redhat.com Tue Apr 22 19:07:11 2014 From: plautrba at redhat.com (Petr Lautrbach) Date: Tue, 22 Apr 2014 11:07:11 +0200 Subject: heads up: tcpwrappers support going away In-Reply-To: References: Message-ID: <5356313F.2010604@redhat.com> On 04/22/2014 09:33 AM, Damien Miller wrote: > Hi, Hi, > This is an early warning: OpenSSH will drop tcpwrappers in the next > release. sshd_config has supported the Match keyword for a long time > and it is possible to express more useful conditions (e.g. matching > by user and address) than tcpwrappers allowed. I'd agree that you can express more useful conditions using Match but it is used in other application level than tcpwrappers. Using tcpwrappers, you can drop a connection before even the server identification string is sent, while Match block is applied after the transport layer is established. You don't have to restart sshd every time you want to change conditions in tcpwrappers, while every change in sshd_config has to be confirmed by restart. > Removing it reduces the amount of code in the 'hot' pre-authentication > path in sshd and rids us of a dependency. > I can see only 17 lines of code in sshd.c around if (!hosts_access(&req)). The tcpwrappers support is already optional so it is not a hard dependency. Petr -- Petr Lautrbach Security Technologies Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From djm at mindrot.org Tue Apr 22 19:46:43 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 22 Apr 2014 19:46:43 +1000 (EST) Subject: heads up: tcpwrappers support going away In-Reply-To: <5356313F.2010604@redhat.com> References: <5356313F.2010604@redhat.com> Message-ID: On Tue, 22 Apr 2014, Petr Lautrbach wrote: > Using tcpwrappers, you can drop a connection before even the server > identification string is sent, while Match block is applied after the > transport layer is established. > > You don't have to restart sshd every time you want to change > conditions in tcpwrappers, while every change in sshd_config has to be > confirmed by restart. You can use a packet filter for this; tcpwrappers dates back to the dark times before these were common on hosts. > I can see only 17 lines of code in sshd.c around if (!hosts_access(&req)) Do you stop counting attack surface at the first function call? FYI, the first function call in hosts_access is a setjmp() :/ Old, redundant code needs to be retired. -d From cloos at jhcloos.com Wed Apr 23 08:31:27 2014 From: cloos at jhcloos.com (James Cloos) Date: Tue, 22 Apr 2014 18:31:27 -0400 Subject: heads up: tcpwrappers support going away In-Reply-To: (Damien Miller's message of "Tue, 22 Apr 2014 17:33:59 +1000 (EST)") References: Message-ID: >>>>> "DM" == Damien Miller writes: DM> This is an early warning: OpenSSH will drop tcpwrappers in the next DM> release. This will need a wider announcement. Most auto-block solutions I've looked at add entries to hosts.allow. Everyone using such will need to adapt their setup to cope. Several use the notion of of a spawn line in hosts.allow. With the loss of tcpwrapper, openssh should add an option to run a command for each incomming conenction (before it sends the banner, et alia) which can check for abuse patterns and add (or expire) a packet filter. The external should be expected to return zero to permit the connection or non-zero to prevent it, plus perform any side-effects the admin wants. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From alex at alex.org.uk Wed Apr 23 17:34:00 2014 From: alex at alex.org.uk (Alex Bligh) Date: Wed, 23 Apr 2014 08:34:00 +0100 Subject: heads up: tcpwrappers support going away In-Reply-To: References: Message-ID: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> On 22 Apr 2014, at 23:31, James Cloos wrote: >>>>>> "DM" == Damien Miller writes: > > DM> This is an early warning: OpenSSH will drop tcpwrappers in the next > DM> release. > > This will need a wider announcement. Most auto-block solutions I've > looked at add entries to hosts.allow. +1. Denyhosts suddenly stopping working is not a great plan. Personally I don't want an automated script futzing with iptables, and making it reload sshd.conf does not seem a great plan either. Making things 'fail insecure' does not seem the right thing to do. -- Alex Bligh From vinschen at redhat.com Wed Apr 23 18:54:26 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 23 Apr 2014 10:54:26 +0200 Subject: heads up: tcpwrappers support going away In-Reply-To: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> Message-ID: <20140423085426.GK2339@calimero.vinschen.de> On Apr 23 08:34, Alex Bligh wrote: > > On 22 Apr 2014, at 23:31, James Cloos wrote: > > >>>>>> "DM" == Damien Miller writes: > > > > DM> This is an early warning: OpenSSH will drop tcpwrappers in the next > > DM> release. > > > > This will need a wider announcement. Most auto-block solutions I've > > looked at add entries to hosts.allow. > > +1. Denyhosts suddenly stopping working is not a great plan. Indeed. The problem here is not that no replacement methods exist (though I'm not so sure how to do that on Windows, I admit), the problem is that you're leaving users hanging in the rain. Assuming you're updating your Linux distro. You're using tcp_wrappers in conjunction with OpenSSH for years. The distro update comes with OpenSSH 6.7, now without tcp_wrappers support. But the OpenSSH update is just one updated package of several hundreds or thousands. How many users will not even get the information that their tcp_wrappers installation doesn't work anymore? tcp_wrappers might be an old concept, but simply pulling the plug and removing the few lines required to support it seems a bit heavy-handed considering what effect this may have. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From opensshdev at r.paypc.com Wed Apr 23 19:21:21 2014 From: opensshdev at r.paypc.com (Morham) Date: Wed, 23 Apr 2014 02:21:21 -0700 Subject: heads up: tcpwrappers support going away In-Reply-To: <20140423085426.GK2339@calimero.vinschen.de> References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> <20140423085426.GK2339@calimero.vinschen.de> Message-ID: <53578611.2020709@r.paypc.com> On 4/23/2014 1:54 AM, Corinna Vinschen wrote: > Assuming you're updating your Linux distro. You're using tcp_wrappers > in conjunction with OpenSSH for years. The distro update comes with > OpenSSH 6.7, now without tcp_wrappers support. But the OpenSSH update > is just one updated package of several hundreds or thousands. How > many users will not even get the information that their tcp_wrappers > installation doesn't work anymore? > > tcp_wrappers might be an old concept, but simply pulling the plug and > removing the few lines required to support it seems a bit heavy-handed > considering what effect this may have. Absolutely. While I agree with some of the impetus behind the abandonment of tcpwrappers, I do think it's time for FOSS projects to stop operating as if their projects comprise the Alpha and Omega of peoples' systems. At the very least, a full cycle of announcing the retirement/obsoletion of the feature in question, followed by issuing a "heads up!" to all distros to warn them that potentially significant consequences will result from people upgrading past a certain version. While systems that "fail badly", i.e., result in unreachable SSHDs are no doubt quickly noticed and redressed by sysadmins, of more worry are those that simply "work as before" but without the limitations defined at some point in the nebulous past by sysadmins before them. I realise that these maintenance tasks are mostly unpaid and thankless, and such recommendations are no doubt unwelcome as addition burdens, but this *IS* ssh we're talking about. I don't know about others in the Linux/BSD-server-sphere, but aside from only DNS, I cannot think of a single thing I expect to work "perfectly" let alone "securely", hundreds of times per day. To me, it's more important than httpd. =M= From andre at ae-35.com Wed Apr 23 20:08:36 2014 From: andre at ae-35.com (=?UTF-8?B?QW5kcsOpIEx1Y2Fz?=) Date: Wed, 23 Apr 2014 11:08:36 +0100 Subject: heads up: tcpwrappers support going away In-Reply-To: <53578611.2020709@r.paypc.com> References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> <20140423085426.GK2339@calimero.vinschen.de> <53578611.2020709@r.paypc.com> Message-ID: On 23 April 2014 10:21, Morham wrote: ... > I realise that these maintenance tasks are mostly unpaid and thankless, > and such recommendations are no doubt unwelcome as addition burdens, but > this *IS* ssh we're talking about. > > I don't know about others in the Linux/BSD-server-sphere, but aside from > only DNS, I cannot think of a single thing I expect to work "perfectly" > let alone "securely", hundreds of times per day. To me, it's more > important than httpd. [Re-replying to the list, finger trouble.] Agreed; but to me that's why the developers' willingness to prune potentially dangerous features, even when it's likely to cause controversy, is so valuable. I wish it were more common. For those that rely on llibwrap, or for distros who want to support it for their users, the option exists to patch it back in. I doubt it would be at all difficult to do. Hopefully, some will decide instead that the reasons given above for not using libwrap are pretty convincing, and that maybe they or their users will be better served by doing something else. -Andr? From djm at mindrot.org Wed Apr 23 21:39:27 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 23 Apr 2014 21:39:27 +1000 (EST) Subject: heads up: tcpwrappers support going away In-Reply-To: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> Message-ID: On Wed, 23 Apr 2014, Alex Bligh wrote: > On 22 Apr 2014, at 23:31, James Cloos wrote: > > >>>>>> "DM" == Damien Miller writes: > > > > DM> This is an early warning: OpenSSH will drop tcpwrappers in the next > > DM> release. > > > > This will need a wider announcement. Most auto-block solutions I've > > looked at add entries to hosts.allow. > > +1. Denyhosts suddenly stopping working is not a great plan. > > Personally I don't want an automated script futzing with iptables, as opposed to letting one futz with something that can execute shell commands? A simple way out of this would be adding "Match exec" support to sshd_config like ssh_config got in the last couple of releases. Anyone want to do this? -d From cloos at jhcloos.com Wed Apr 23 22:59:32 2014 From: cloos at jhcloos.com (James Cloos) Date: Wed, 23 Apr 2014 08:59:32 -0400 Subject: heads up: tcpwrappers support going away In-Reply-To: (Damien Miller's message of "Wed, 23 Apr 2014 21:39:27 +1000 (EST)") References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> Message-ID: >>>>> "DM" == Damien Miller writes: DM> A simple way out of this would be adding "Match exec" support to sshd_config DM> like ssh_config got in the last couple of releases. Anyone want to do this? Yes. I'd forgotten about match exec in ssh_config(5), and only read sshd_config(5) before posting, but match exec is exactly what I suggested. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From iszczesniak at gmail.com Thu Apr 24 03:51:52 2014 From: iszczesniak at gmail.com (Irek Szczesniak) Date: Wed, 23 Apr 2014 19:51:52 +0200 Subject: VETO! Re: heads up: tcpwrappers support going away Message-ID: On Tue, Apr 22, 2014 at 9:33 AM, Damien Miller wrote: > Hi, > > This is an early warning: OpenSSH will drop tcpwrappers in the next > release. sshd_config has supported the Match keyword for a long time > and it is possible to express more useful conditions (e.g. matching > by user and address) than tcpwrappers allowed. > > Removing it reduces the amount of code in the 'hot' pre-authentication > path in sshd and rids us of a dependency. Can I VETO that change, please? tcpwrappers provides a *central* configuration to protect all services based on per IP address authentication. This is not perfect but greatly reduces the area exposed to possible attacks, long before any ssh auth code runs. Removing this functionality creates a lot more headaches for security people and marres opensshs otherwise good, multilayer security architecture. Also, do you think that this change serves the needs of your customers? The first thing I can imagine is that *every* Linux distro on this planet just patches tcpwrappers support back into the code. Irek From imorgan at nas.nasa.gov Thu Apr 24 05:26:58 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 23 Apr 2014 12:26:58 -0700 Subject: heads up: tcpwrappers support going away In-Reply-To: References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> Message-ID: <20140423192658.GB23852@linux124.nas.nasa.gov> On Wed, Apr 23, 2014 at 21:39:27 +1000, Damien Miller wrote: > On Wed, 23 Apr 2014, Alex Bligh wrote: > > > On 22 Apr 2014, at 23:31, James Cloos wrote: > > > > >>>>>> "DM" == Damien Miller writes: > > > > > > DM> This is an early warning: OpenSSH will drop tcpwrappers in the next > > > DM> release. > > > > > > This will need a wider announcement. Most auto-block solutions I've > > > looked at add entries to hosts.allow. > > > > +1. Denyhosts suddenly stopping working is not a great plan. > > > > Personally I don't want an automated script futzing with iptables, > > as opposed to letting one futz with something that can execute shell > commands? > > A simple way out of this would be adding "Match exec" support to sshd_config > like ssh_config got in the last couple of releases. Anyone want to do this? > > -d This wouldn't be a drop-in solution, but pam_access might be an option for platforms that support PAM. The syntax is similar, but not equivalent to libwrap. Admittedly, this has the disadvantage that a rejection would occur later in the connection process, so it might not be suitable in all cases. A slightly better solution would be a PAM module that uses the same syntax as libwrap. Possibly someone has already written such a module. -- Iain Morgan From mouring at eviladmin.org Thu Apr 24 05:31:43 2014 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 23 Apr 2014 14:31:43 -0500 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: References: Message-ID: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> On Apr 23, 2014, at 12:51 PM, Irek Szczesniak wrote: > Can I VETO that change, please? > > tcpwrappers provides a *central* configuration to protect all services > based on per IP address authentication. This is not perfect but > greatly reduces the area exposed to possible attacks, long before any > ssh auth code runs. Removing this functionality creates a lot more > headaches for security people and marres opensshs otherwise good, > multilayer security architecture. > > Also, do you think that this change serves the needs of your > customers? The first thing I can imagine is that *every* Linux distro > on this planet just patches tcpwrappers support back into the code. Let them. Each distro has their pet patches that OpenSSH has rejected. Personally, I'm glad to see us finally doing away with tcpwrapper. It is a dark part of our history that should be scorched from the planet so we can get people to start doing stuff the right away. - Ben From mancha1 at zoho.com Thu Apr 24 05:40:06 2014 From: mancha1 at zoho.com (mancha) Date: Wed, 23 Apr 2014 19:40:06 +0000 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> References: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> Message-ID: <20140423194006.GA18585@zoho.com> On Wed, Apr 23, 2014 at 02:31:43PM -0500, Ben Lindstrom wrote: > Personally, I'm glad to see us finally doing away with tcpwrapper. It > is a dark part of our history that should be scorched from the planet > so we can get people to start doing stuff the right away. > > - Ben Don't use "--with-tcp-wrappers" --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mancha1 at zoho.com Thu Apr 24 05:43:05 2014 From: mancha1 at zoho.com (mancha) Date: Wed, 23 Apr 2014 19:43:05 +0000 Subject: heads up: tcpwrappers support going away In-Reply-To: <20140423192658.GB23852@linux124.nas.nasa.gov> References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> <20140423192658.GB23852@linux124.nas.nasa.gov> Message-ID: <20140423194305.GB18585@zoho.com> On Wed, Apr 23, 2014 at 12:26:58PM -0700, Iain Morgan wrote: > A slightly better solution would be a PAM module that uses the same > syntax as libwrap. Possibly someone has already written such a module. Possibly, but only for platforms which use for PAM. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From cedric.blancher at gmail.com Thu Apr 24 05:55:14 2014 From: cedric.blancher at gmail.com (Cedric Blancher) Date: Wed, 23 Apr 2014 21:55:14 +0200 Subject: hackers celebrate this day: openssh drops security! was: Re: heads up: tcpwrappers support going away Message-ID: On 23 April 2014 21:43, mancha wrote: > On Wed, Apr 23, 2014 at 12:26:58PM -0700, Iain Morgan wrote: >> A slightly better solution would be a PAM module that uses the same >> syntax as libwrap. Possibly someone has already written such a module. > > Possibly, but only for platforms which use for PAM. Pam is executed so late in the chain that any possible security issue has long been exposed to half of China and the KGB. Hackers will celebrate this day - openssh drops security. Time to move on to ssh.com's ssh variant. Seriously - the discussion is stupid: If tcpwrappers support gets removed than a replacement is required which is executed at the same location and not much later in the code. Ced -- Cedric Blancher Institute Pasteur From kop at meme.com Thu Apr 24 06:22:50 2014 From: kop at meme.com (Karl O. Pinc) Date: Wed, 23 Apr 2014 15:22:50 -0500 Subject: hackers celebrate this day: openssh drops security! was: Re: heads up: tcpwrappers support going away In-Reply-To: (from cedric.blancher@gmail.com on Wed Apr 23 14:55:14 2014) Message-ID: <1398284570.12871.9@slate> On 04/23/2014 02:55:14 PM, Cedric Blancher wrote: > Seriously - the discussion is stupid: If tcpwrappers support gets > removed than a replacement is required which is executed at the same > location and not much later in the code. Well, no. If you want system-wide packet filtering, which is what tcpwrapper provides, putting that into the application layer is what is stupid. Use, instead, a real system wide packet filter -- whatever the system firewall is. What I find interesting is that the ssh maintainers seem to have declared, purposefully or not, that they are serving the distros not the end user. They are leaving it to the distros to provide a smooth upgrade path to the end-user. Nothing really wrong with that. The alternative, depreciation with warnings in the logs or whatever for a lengthy transition period, being work that might be better spent on maintaining security. I do find that abrupt dropping of a feature is a little jarring. But on the other hand who hasn't known forever that tcpwrappers is a lame solution? (Most everybody?!) The writing has been on the wall for a long time. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein From djm at mindrot.org Thu Apr 24 08:58:02 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Apr 2014 08:58:02 +1000 (EST) Subject: heads up: tcpwrappers support going away In-Reply-To: References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> Message-ID: On Wed, 23 Apr 2014, Damien Miller wrote: > A simple way out of this would be adding "Match exec" support to sshd_config > like ssh_config got in the last couple of releases. Anyone want to do this? like this: Index: servconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.c,v retrieving revision 1.249 diff -u -p -r1.249 servconf.c --- servconf.c 29 Jan 2014 06:18:35 -0000 1.249 +++ servconf.c 23 Apr 2014 22:56:54 -0000 @@ -50,6 +50,7 @@ #include "packet.h" #include "hostfile.h" #include "auth.h" +#include "misc.h" static void add_listen_addr(ServerOptions *, char *, int); static void add_one_listen_addr(ServerOptions *, char *, int); @@ -604,9 +605,10 @@ out: static int match_cfg_line(char **condition, int line, struct connection_info *ci) { - int result = 1, attributes = 0, port; - char *arg, *attrib, *cp = *condition; + int r, result = 1, attributes = 0, port; + char *arg, *attrib, *cmd, *cp = *condition; size_t len; + char thishost[NI_MAXHOST], shorthost[NI_MAXHOST], portstr[NI_MAXSERV]; if (ci == NULL) debug3("checking syntax for 'Match %s'", cp); @@ -717,6 +719,45 @@ match_cfg_line(char **condition, int lin ci->laddress, port, line); else result = 0; + } else if (strcasecmp(attrib, "exec") == 0) { + if (ci == NULL) { + result = 0; + continue; + } + if (gethostname(thishost, sizeof(thishost)) == -1) + fatal("gethostname: %s", strerror(errno)); + strlcpy(shorthost, thishost, sizeof(shorthost)); + shorthost[strcspn(thishost, ".")] = '\0'; + snprintf(portstr, sizeof(portstr), "%d", ci->lport); + + cmd = percent_expand(arg, + "L", shorthost, + "l", thishost, + "h", ci->host, + "P", portstr, + "u", ci->user, + "a", ci->address, + "A", ci->laddress, + (char *)NULL); + if (result != 1) { + /* skip execution if prior predicate failed */ + debug("config line %d: skipped exec \"%.100s\"", + line, cmd); + } else { + r = execute_in_shell(cmd, 0); + if (r == -1) { + fatal("config line %d: match exec " + "'%.100s' error", line, cmd); + } else if (r == 0) { + debug("config line %d: matched " + "'exec \"%.100s\"'", line, cmd); + } else { + debug("config line %d: no match " + "'exec \"%.100s\"'", line, cmd); + result = 0; + } + } + free(cmd); } else { error("Unsupported Match attribute %s", attrib); return -1; Index: readconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.c,v retrieving revision 1.219 diff -u -p -r1.219 readconf.c --- readconf.c 23 Apr 2014 12:42:34 -0000 1.219 +++ readconf.c 23 Apr 2014 22:56:55 -0000 @@ -15,7 +15,6 @@ #include #include #include -#include #include #include @@ -27,7 +26,6 @@ #include #include #include -#include #include #include #include @@ -46,7 +44,6 @@ #include "buffer.h" #include "kex.h" #include "mac.h" -#include "uidswap.h" /* Format of the configuration file: @@ -376,80 +373,6 @@ default_ssh_port(void) } /* - * Execute a command in a shell. - * Return its exit status or -1 on abnormal exit. - */ -static int -execute_in_shell(const char *cmd) -{ - char *shell, *command_string; - pid_t pid; - int devnull, status; - extern uid_t original_real_uid; - - if ((shell = getenv("SHELL")) == NULL) - shell = _PATH_BSHELL; - - /* - * Use "exec" to avoid "sh -c" processes on some platforms - * (e.g. Solaris) - */ - xasprintf(&command_string, "exec %s", cmd); - - /* Need this to redirect subprocess stdin/out */ - if ((devnull = open(_PATH_DEVNULL, O_RDWR)) == -1) - fatal("open(/dev/null): %s", strerror(errno)); - - debug("Executing command: '%.500s'", cmd); - - /* Fork and execute the command. */ - if ((pid = fork()) == 0) { - char *argv[4]; - - /* Child. Permanently give up superuser privileges. */ - permanently_drop_suid(original_real_uid); - - /* Redirect child stdin and stdout. Leave stderr */ - if (dup2(devnull, STDIN_FILENO) == -1) - fatal("dup2: %s", strerror(errno)); - if (dup2(devnull, STDOUT_FILENO) == -1) - fatal("dup2: %s", strerror(errno)); - if (devnull > STDERR_FILENO) - close(devnull); - closefrom(STDERR_FILENO + 1); - - argv[0] = shell; - argv[1] = "-c"; - argv[2] = command_string; - argv[3] = NULL; - - execv(argv[0], argv); - error("Unable to execute '%.100s': %s", cmd, strerror(errno)); - /* Die with signal to make this error apparent to parent. */ - signal(SIGTERM, SIG_DFL); - kill(getpid(), SIGTERM); - _exit(1); - } - /* Parent. */ - if (pid < 0) - fatal("%s: fork: %.100s", __func__, strerror(errno)); - - close(devnull); - free(command_string); - - while (waitpid(pid, &status, 0) == -1) { - if (errno != EINTR && errno != EAGAIN) - fatal("%s: waitpid: %s", __func__, strerror(errno)); - } - if (!WIFEXITED(status)) { - error("command '%.100s' exited abnormally", cmd); - return -1; - } - debug3("command returned status %d", WEXITSTATUS(status)); - return WEXITSTATUS(status); -} - -/* * Parse and execute a Match directive. */ static int @@ -461,6 +384,7 @@ match_cfg_line(Options *options, char ** int r, port, result = 1, attributes = 0; size_t len; char thishost[NI_MAXHOST], shorthost[NI_MAXHOST], portstr[NI_MAXSERV]; + extern uid_t original_real_uid; /* * Configuration is likely to be incomplete at this point so we @@ -544,7 +468,7 @@ match_cfg_line(Options *options, char ** debug("%.200s line %d: skipped exec \"%.100s\"", filename, linenum, cmd); } else { - r = execute_in_shell(cmd); + r = execute_in_shell(cmd, original_real_uid); if (r == -1) { fatal("%.200s line %d: match exec " "'%.100s' error", filename, Index: misc.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/misc.c,v retrieving revision 1.93 diff -u -p -r1.93 misc.c --- misc.c 20 Apr 2014 02:30:25 -0000 1.93 +++ misc.c 23 Apr 2014 22:56:55 -0000 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include @@ -41,6 +42,7 @@ #include #include #include +#include #include #include #include @@ -1019,3 +1021,80 @@ lowercase(char *s) for (; *s; s++) *s = tolower((u_char)*s); } + +/* + * Execute a command in a shell. + * Return its exit status or -1 on abnormal exit. + */ +int +execute_in_shell(const char *cmd, uid_t drop_uid) +{ + char *shell, *command_string; + pid_t pid; + int devnull, status; + + if ((shell = getenv("SHELL")) == NULL) + shell = _PATH_BSHELL; + + /* + * Use "exec" to avoid "sh -c" processes on some platforms + * (e.g. Solaris) + */ + xasprintf(&command_string, "exec %s", cmd); + + /* Need this to redirect subprocess stdin/out */ + if ((devnull = open(_PATH_DEVNULL, O_RDWR)) == -1) + fatal("open(/dev/null): %s", strerror(errno)); + + debug("Executing command: '%.500s'", cmd); + + /* Fork and execute the command. */ + if ((pid = fork()) == 0) { + char *argv[4]; + + /* Child. Permanently give up superuser privileges. */ + if (drop_uid != 0 && + setresuid(drop_uid, drop_uid, drop_uid) != 0) + fatal("%s: setresuid %lu: %s", __func__, + (u_long)drop_uid, strerror(errno)); + + /* Redirect child stdin and stdout. Leave stderr */ + if (dup2(devnull, STDIN_FILENO) == -1) + fatal("dup2: %s", strerror(errno)); + if (dup2(devnull, STDOUT_FILENO) == -1) + fatal("dup2: %s", strerror(errno)); + if (devnull > STDERR_FILENO) + close(devnull); + closefrom(STDERR_FILENO + 1); + + argv[0] = shell; + argv[1] = "-c"; + argv[2] = command_string; + argv[3] = NULL; + + execv(argv[0], argv); + error("Unable to execute '%.100s': %s", cmd, strerror(errno)); + /* Die with signal to make this error apparent to parent. */ + signal(SIGTERM, SIG_DFL); + kill(getpid(), SIGTERM); + _exit(1); + } + /* Parent. */ + if (pid < 0) + fatal("%s: fork: %.100s", __func__, strerror(errno)); + + close(devnull); + free(command_string); + + while (waitpid(pid, &status, 0) == -1) { + if (errno != EINTR && errno != EAGAIN) + fatal("%s: waitpid: %s", __func__, strerror(errno)); + } + if (!WIFEXITED(status)) { + error("command '%.100s' exited abnormally", cmd); + return -1; + } + debug3("command returned status %d", WEXITSTATUS(status)); + return WEXITSTATUS(status); +} + Index: misc.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/misc.h,v retrieving revision 1.52 diff -u -p -r1.52 misc.h --- misc.h 20 Apr 2014 02:30:25 -0000 1.52 +++ misc.h 23 Apr 2014 22:56:55 -0000 @@ -37,6 +37,7 @@ void ms_subtract_diff(struct timeval *, void ms_to_timeval(struct timeval *, int); time_t monotime(void); void lowercase(char *s); +int execute_in_shell(const char *, uid_t); struct passwd *pwcopy(struct passwd *); const char *ssh_gai_strerror(int); From djm at mindrot.org Thu Apr 24 09:46:07 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Apr 2014 09:46:07 +1000 (EST) Subject: hackers celebrate this day: openssh drops security! was: Re: heads up: tcpwrappers support going away In-Reply-To: References: Message-ID: On Wed, 23 Apr 2014, Cedric Blancher wrote: > Hackers will celebrate this day - openssh drops security. > Time to move on to ssh.com's ssh variant. good luck with that https://answers.ssh.com/questions/398/support-for-tcp-wrappers > Seriously - the discussion is stupid: If tcpwrappers support gets > removed than a replacement is required which is executed at the same > location and not much later in the code. How about a packet filter? That way no code gets executed at all... -d From christian.heinrich at cmlh.id.au Thu Apr 24 09:59:23 2014 From: christian.heinrich at cmlh.id.au (Christian Heinrich) Date: Thu, 24 Apr 2014 09:59:23 +1000 Subject: hackers celebrate this day: openssh drops security! was: Re: heads up: tcpwrappers support going away In-Reply-To: References: Message-ID: Cedric, On Thu, Apr 24, 2014 at 5:55 AM, Cedric Blancher wrote: Is http://www.theregister.co.uk/2013/11/12/cdric_sid_blancher_dead_at_37/ you? -- Regards, Christian Heinrich http://cmlh.id.au/contact From djm at mindrot.org Thu Apr 24 10:07:13 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Apr 2014 10:07:13 +1000 (EST) Subject: heads up: tcpwrappers support going away In-Reply-To: References: <9D17A0CF-3319-499A-A177-73002BA0D879@alex.org.uk> Message-ID: On Thu, 24 Apr 2014, Damien Miller wrote: > On Wed, 23 Apr 2014, Damien Miller wrote: > > > A simple way out of this would be adding "Match exec" support to sshd_config > > like ssh_config got in the last couple of releases. Anyone want to do this? > > like this: > > Index: servconf.c ... and applied using: Match exec "/path/to/wrapssh '%h' '%a' '%l' '%A'" MaxAuthTries 0 with a helper as simple as: (btw, I'd accept a fleshed-out version of this for contrib/ if anyone wants to do the work) #include #include int main(int argc, char **argv) { struct request_info req; openlog("sshd-tcpwrap", LOG_NDELAY|LOG_PERROR|LOG_PID, LOG_AUTH); /* Client host, client address, server host, server address */ if (argc != 5) { syslog(LOG_ERR, "expected 4 arguments, got %d", argc - 1); return 2; } request_init(&req, RQ_DAEMON, "sshd", RQ_CLIENT_NAME, argv[1], RQ_CLIENT_ADDR, argv[2], RQ_SERVER_NAME, argv[3], RQ_SERVER_ADDR, argv[4], 0); if (!hosts_access(&req)) { syslog(LOG_ERR, "tcpwrappers refused connection"); return 1; } return 0; } From bdrewery at FreeBSD.org Thu Apr 24 11:03:43 2014 From: bdrewery at FreeBSD.org (Bryan Drewery) Date: Wed, 23 Apr 2014 20:03:43 -0500 Subject: bad bignum encoding for curve25519-sha256@libssh.org In-Reply-To: References: Message-ID: <535862EF.4010309@FreeBSD.org> On 4/20/2014 2:14 AM, Damien Miller wrote: > Hi, > > So I screwed up when writing the support for the curve25519 KEX method > that doesn't depend on OpenSSL's BIGNUM type - a bug in my code left > leading zero bytes where they should have been skipped. The impact of > this is that OpenSSH 6.5 and 6.6 will fail during key exchange with a > peer that implements curve25519-sha256 at libssh.org properly about 0.2% > of the time (one in every 512ish connections). > > We've fixed this for OpenSSH 6.7 by avoiding the curve25519-sha256 > key exchange for previous versions, but I'd recommend distributors > of OpenSSH apply this patch so the affected code doesn't become > too entrenched in LTS releases. > > The patch fixes the bug and makes OpenSSH identify itself as 6.6.1 so as > to distinguish itself from the incorrect versions so the compatibility > code to disable the affected KEX isn't activated. > > I've committed this on the 6.6 branch too. > > Apologies for the hassle. > > -d Am I the only one who finds a bugfix non-release via unsigned mail with an inline patch a problem? -- Regards, Bryan Drewery -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From djm at mindrot.org Thu Apr 24 11:15:49 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Apr 2014 11:15:49 +1000 (EST) Subject: bad bignum encoding for curve25519-sha256@libssh.org In-Reply-To: <535862EF.4010309@FreeBSD.org> References: <535862EF.4010309@FreeBSD.org> Message-ID: On Wed, 23 Apr 2014, Bryan Drewery wrote: > Am I the only one who finds a bugfix non-release via unsigned mail with > an inline patch a problem? It's only a problem if you can't/won't read the code. -d From bdrewery at FreeBSD.org Thu Apr 24 11:17:49 2014 From: bdrewery at FreeBSD.org (Bryan Drewery) Date: Wed, 23 Apr 2014 20:17:49 -0500 Subject: bad bignum encoding for curve25519-sha256@libssh.org In-Reply-To: References: <535862EF.4010309@FreeBSD.org> Message-ID: <5358663D.5060408@FreeBSD.org> On 4/23/2014 8:15 PM, Damien Miller wrote: > On Wed, 23 Apr 2014, Bryan Drewery wrote: > >> Am I the only one who finds a bugfix non-release via unsigned mail with >> an inline patch a problem? > > It's only a problem if you can't/won't read the code. > > -d > Why not do an actual release? The official changelog linked from the site, ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/ChangeLog, is missing it as well. So it looks suspicious for me to add it as an extra patch into our port. -- Regards, Bryan Drewery -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From djm at mindrot.org Thu Apr 24 11:20:24 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Apr 2014 11:20:24 +1000 (EST) Subject: bad bignum encoding for curve25519-sha256@libssh.org In-Reply-To: <5358663D.5060408@FreeBSD.org> References: <535862EF.4010309@FreeBSD.org> <5358663D.5060408@FreeBSD.org> Message-ID: On Wed, 23 Apr 2014, Bryan Drewery wrote: > Why not do an actual release? I judged the problem too minor to make a release for. > The official changelog linked from the site, > ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/ChangeLog, is > missing it as well. So it looks suspicious for me to add it as an extra > patch into our port. That changelog is for releases only. If you want a live one, then use the cvs/git repository. -d From mancha1 at zoho.com Thu Apr 24 12:24:39 2014 From: mancha1 at zoho.com (mancha) Date: Thu, 24 Apr 2014 02:24:39 +0000 Subject: bad bignum encoding for curve25519-sha256@libssh.org In-Reply-To: References: <535862EF.4010309@FreeBSD.org> Message-ID: <20140424022439.GA19637@zoho.com> On Thu, Apr 24, 2014 at 11:15:49AM +1000, Damien Miller wrote: > On Wed, 23 Apr 2014, Bryan Drewery wrote: > > > Am I the only one who finds a bugfix non-release via unsigned mail with > > an inline patch a problem? > > It's only a problem if you can't/won't read the code. > > -d I don't think Bryan's comment is without merit. When I saw the ML patch I reconstructed it from commits in portable's git repo for my own peace of mind [1]. Would it be possible to have "official" patches provided via the ML be PGP-signed in the future? I think many would appreciate it. --mancha PS Also, not sure what git you use on mindrot but by way of FYI, as of version 1.7.9, git allows PGP signing individual commits (e.g. git commit -S -m "blah"). ========= [1] Ingredients of Curve25519 bugfix patch: https://anongit.mindrot.org/openssh.git/commit/?id=adbfdbbdcc https://anongit.mindrot.org/openssh.git/commit/?id=9395b28223 https://anongit.mindrot.org/openssh.git/commit/?id=0e6b67423b https://anongit.mindrot.org/openssh.git/commit/?id=b628cc4c3e -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From cedric.blancher at gmail.com Fri Apr 25 03:20:02 2014 From: cedric.blancher at gmail.com (Cedric Blancher) Date: Thu, 24 Apr 2014 19:20:02 +0200 Subject: hackers celebrate this day: openssh drops security! was: Re: heads up: tcpwrappers support going away In-Reply-To: References: Message-ID: On 24 April 2014 01:59, Christian Heinrich wrote: > Cedric, > > On Thu, Apr 24, 2014 at 5:55 AM, Cedric Blancher > wrote: > > Is http://www.theregister.co.uk/2013/11/12/cdric_sid_blancher_dead_at_37/ you? Not very funny. No, we're only remotely related, and yes, I know about this because some idiot called my wife to pay his condolences while I was on a conference. F*ck. Ced -- Cedric Blancher Institute Pasteur From cedric.blancher at gmail.com Fri Apr 25 03:24:42 2014 From: cedric.blancher at gmail.com (Cedric Blancher) Date: Thu, 24 Apr 2014 19:24:42 +0200 Subject: hackers celebrate this day: openssh drops security! was: Re: heads up: tcpwrappers support going away In-Reply-To: References: Message-ID: On 24 April 2014 19:20, Cedric Blancher wrote: > On 24 April 2014 01:59, Christian Heinrich > wrote: >> Cedric, >> >> On Thu, Apr 24, 2014 at 5:55 AM, Cedric Blancher >> wrote: >> >> Is http://www.theregister.co.uk/2013/11/12/cdric_sid_blancher_dead_at_37/ you? > > Not very funny. No, we're only remotely related, and yes, I know about > this because some idiot called my wife to pay his condolences while I > was on a conference. F*ck. Apologies for the strong and inappropriate language. I overreacted because I remembered the shock my wife got from that phone call, and it took her weeks to recover from it Ced -- Cedric Blancher Institute Pasteur From bert.haverkamp at gmail.com Fri Apr 25 20:00:02 2014 From: bert.haverkamp at gmail.com (Bert Haverkamp) Date: Fri, 25 Apr 2014 11:00:02 +0100 Subject: Request for reviewing lsetstat patch Message-ID: Dear all, With openssh 6.6 out the door, I want to make a case to add lsetstat to sftp-server. The patches are provided in bug 2067. I hope they can be incorporated in the next version.I have them running for a year on several systems already and they work fine IMHO. At the moment sftp is not able to set timestamps on symlinks. In order to make this possible lsetstat needs to be implemented. Attached patch makes this addition. This patch is particularly useful when using sshfs. It makes the filesystem even more transparent to use. On a related note, I am/was also interested in the patches attached to bug 1555. As far as I can see these patches were long ago incorporated. If so, bug 1555 should be closed. Please let me know if you have any feedback on the above patches. Kind regards, Bert Haverkamp From openssh-unix-dev at thegeezer.net Fri Apr 25 22:52:46 2014 From: openssh-unix-dev at thegeezer.net (TheGezer) Date: Fri, 25 Apr 2014 13:52:46 +0100 Subject: public key authentication -- log invalid keys Message-ID: <535A5A9E.5090408@thegeezer.net> Hi guys, i was wondering if someone could point me in the right direction please. if someone connects using public keys, but uses the wrong keys to connect, openssh logs this kind of thing: Apr 21 23:50:04 [sshd] SSH: Server;Ltype: Version;Remote: 122.169.248.92-49232;Protocol: 2.0;Client: libssh-0.2 Apr 21 23:50:05 [sshd] SSH: Server;Ltype: Kex;Remote: 122.169.248.92-49232;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth] Apr 21 23:50:05 [sshd] SSH: Server;Ltype: Version;Remote: 122.169.248.92-51680;Protocol: 2.0;Client: libssh-0.2 Apr 21 23:50:05 [sshd] SSH: Server;Ltype: Kex;Remote: 122.169.248.92-51680;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth] while i appreciate that bruteforcing a public key is significantly more difficult than a short password, this does make me a little uneasy and i'd like to be able to feed these bad IP addresses to my firewall. however, when I correctly ssh to my machines, i get similar entries Apr 20 09:16:24 [sshd] SSH: Server;Ltype: Version;Remote: 192.168.x.100-55939;Protocol: 2.0;Client: OpenSSH_5.9p1 Debian-5ubuntu3 Apr 20 09:16:24 [sshd] SSH: Server;Ltype: Kex;Remote: 192.168.x.100-55939;Enc: aes128-ctr;MAC: hmac-md5;Comp: none [preauth] Apr 20 09:16:24 [sshd] SSH: Server;Ltype: Authname;Remote: 192.168.x.100-55939;Name: root [preauth] Apr 20 09:16:28 [sshd] Accepted keyboard-interactive/pam for root from 192.168.x.100 port 55939 ssh2 i've tried changing LogLevel VERBOSE but it doesn't seem to make any difference what i was hoping for is something similar to this: Apr 24 11:53:47 [sshd] input_userauth_request: invalid user ubuntu [preauth] but saying "invalid keys" or similar. any pointers gratefully received, thanks in advance and especially thanks for openssh ! From esk-openssh at esk.cs.usu.edu Sat Apr 26 02:41:22 2014 From: esk-openssh at esk.cs.usu.edu (Eldon Koyle) Date: Fri, 25 Apr 2014 10:41:22 -0600 Subject: public key authentication -- log invalid keys In-Reply-To: <535A5A9E.5090408@thegeezer.net> References: <535A5A9E.5090408@thegeezer.net> Message-ID: <20140425164122.GX8684@esk.usu.edu> I think you could end up with a lot of false positives doing this. I know I have quite a few keys that my client will try before falling back to password authentication. You would need to have enough logic in your script to see if the authentication succeeds at some point or have a very high limit. It might be more interesting to make a database of bad public keys or fingerprints and block any addresses that attempt one of them (assuming you can get openssh to log the failed keys somehow). -- Eldon Koyle On Apr 25 13:52+0100, TheGezer wrote: > Hi guys, > i was wondering if someone could point me in the right direction please. > if someone connects using public keys, but uses the wrong keys to > connect, openssh logs this kind of thing: > > Apr 21 23:50:04 [sshd] SSH: Server;Ltype: Version;Remote: > 122.169.248.92-49232;Protocol: 2.0;Client: libssh-0.2 > Apr 21 23:50:05 [sshd] SSH: Server;Ltype: Kex;Remote: > 122.169.248.92-49232;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth] > Apr 21 23:50:05 [sshd] SSH: Server;Ltype: Version;Remote: > 122.169.248.92-51680;Protocol: 2.0;Client: libssh-0.2 > Apr 21 23:50:05 [sshd] SSH: Server;Ltype: Kex;Remote: > 122.169.248.92-51680;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth] > > while i appreciate that bruteforcing a public key is significantly more > difficult than a short password, this does make me a little uneasy and > i'd like to be able to feed these bad IP addresses to my firewall. > > however, when I correctly ssh to my machines, i get similar entries > Apr 20 09:16:24 [sshd] SSH: Server;Ltype: Version;Remote: > 192.168.x.100-55939;Protocol: 2.0;Client: OpenSSH_5.9p1 Debian-5ubuntu3 > Apr 20 09:16:24 [sshd] SSH: Server;Ltype: Kex;Remote: > 192.168.x.100-55939;Enc: aes128-ctr;MAC: hmac-md5;Comp: none [preauth] > Apr 20 09:16:24 [sshd] SSH: Server;Ltype: Authname;Remote: > 192.168.x.100-55939;Name: root [preauth] > Apr 20 09:16:28 [sshd] Accepted keyboard-interactive/pam for root from > 192.168.x.100 port 55939 ssh2 > > i've tried changing LogLevel VERBOSE but it doesn't seem to make any > difference > what i was hoping for is something similar to this: > > Apr 24 11:53:47 [sshd] input_userauth_request: invalid user ubuntu [preauth] > > but saying "invalid keys" or similar. > > any pointers gratefully received, > thanks in advance and especially thanks for openssh ! > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From openssh-unix-dev at thegeezer.net Sat Apr 26 03:07:55 2014 From: openssh-unix-dev at thegeezer.net (TheGezer) Date: Fri, 25 Apr 2014 18:07:55 +0100 Subject: public key authentication -- log invalid keys In-Reply-To: <20140425164122.GX8684@esk.usu.edu> References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> Message-ID: <535A966B.3040701@thegeezer.net> On 04/25/2014 05:41 PM, Eldon Koyle wrote: > I think you could end up with a lot of false positives doing this. yup > I know I have quite a few keys that my client will try before falling > back to password authentication. You would need to have enough logic in > your script to see if the authentication succeeds at some point or have > a very high limit. > > It might be more interesting to make a database of bad public keys or interestingly openssh *does* log revoked keys http://en.wikibooks.org/wiki/OpenSSH/Logging#Logging_Revoked_Keys > fingerprints and block any addresses that attempt one of them (assuming > you can get openssh to log the failed keys somehow). > if only i knew how to log the failed keys :) From nkadel at gmail.com Sat Apr 26 11:14:38 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 25 Apr 2014 21:14:38 -0400 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: <20140423194006.GA18585@zoho.com> References: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> <20140423194006.GA18585@zoho.com> Message-ID: On Wed, Apr 23, 2014 at 3:40 PM, mancha wrote: > On Wed, Apr 23, 2014 at 02:31:43PM -0500, Ben Lindstrom wrote: >> Personally, I'm glad to see us finally doing away with tcpwrapper. It >> is a dark part of our history that should be scorched from the planet >> so we can get people to start doing stuff the right away^H^H^H^H our way Fixed That For You(tm). > Don't use "--with-tcp-wrappers" > > --mancha tcp_wrappers has been a much, much easier and safer to set up lightweight, application firewall filter for a *long* time. It's been useful aand safer to implement than the plethora of easily fractured firewall configurations configured, and inconsistently configured, by every GUI script kiddie with an attitude who's never actually learned to do flow charts and logic diagrams and really understand how firewalls work. It's integration with SSH has helped make SSH safer to configure when touching the firewall was out of the scope of the host specific admin, and I've personally encountered such situations. (Do not get me *started* on Puppet, Tuttle, CFengine and Chef admins who will insist on retaining sitewide control of the firewall configs and really don't know how to do them well.) iptables and pif are ikely to be overridden in a larger environment by someone else's standards, but you can get away with noticeably improved system access control despite this by configuring at least tcp_wrappers. Please leave in a lightweight, stable, useful future. From kop at meme.com Sat Apr 26 11:35:08 2014 From: kop at meme.com (Karl O. Pinc) Date: Fri, 25 Apr 2014 20:35:08 -0500 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: (from nkadel@gmail.com on Fri Apr 25 20:14:38 2014) References: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> <20140423194006.GA18585@zoho.com> Message-ID: <1398476108.17492.1@slate> On 04/25/2014 08:14:38 PM, Nico Kadel-Garcia wrote: > It's integration with SSH has helped make SSH safer to configure when > touching the firewall was out of the scope of the host specific > admin, > and I've personally encountered such situations. (Do not get me > *started* on Puppet, Tuttle, CFengine and Chef admins who will insist > on retaining sitewide control of the firewall configs and really > don't > know how to do them well.) iptables and pif are ikely to be > overridden > in a larger environment by someone else's standards, but you can get > away with noticeably improved system access control despite this by > configuring at least tcp_wrappers. I bet sshd could be run from a tcpwrapper enabled inetd using 'sshd -D'. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein From nicolai-openssh at chocolatine.org Sun Apr 27 01:57:42 2014 From: nicolai-openssh at chocolatine.org (Nicolai) Date: Sat, 26 Apr 2014 10:57:42 -0500 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: <1398476108.17492.1@slate> References: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> <20140423194006.GA18585@zoho.com> <1398476108.17492.1@slate> Message-ID: <20140426155741.GA3568@vectra.student.iastate.edu> On Fri, Apr 25, 2014 at 08:35:08PM -0500, Karl O. Pinc wrote: > I bet sshd could be run from a tcpwrapper enabled inetd > using 'sshd -D'. Good point. I use -ieDf for ssh over CurveCP and it works like a charm even on old hardware. So really, the desired functionality will still be in OpenSSH, and there will still be at least two distinct ways of getting it (instead of three). It's sensible to remove duplicate functionality in OpenSSH, particularly where it's better placed elsewhere. So people can look at -i and -D flags. They work! Nicolai From nkadel at gmail.com Sun Apr 27 02:14:25 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 26 Apr 2014 12:14:25 -0400 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: <20140426155741.GA3568@vectra.student.iastate.edu> References: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> <20140423194006.GA18585@zoho.com> <1398476108.17492.1@slate> <20140426155741.GA3568@vectra.student.iastate.edu> Message-ID: On Sat, Apr 26, 2014 at 11:57 AM, Nicolai wrote: > On Fri, Apr 25, 2014 at 08:35:08PM -0500, Karl O. Pinc wrote: >> I bet sshd could be run from a tcpwrapper enabled inetd >> using 'sshd -D'. > > Good point. I use -ieDf for ssh over CurveCP and it works like a charm > even on old hardware. So really, the desired functionality will still > be in OpenSSH, and there will still be at least two distinct ways of > getting it (instead of three). It's sensible to remove duplicate > functionality in OpenSSH, particularly where it's better placed > elsewhere. > > So people can look at -i and -D flags. They work! Isn't it significantly more efficient to allow sshd to do its own forks, rather than doing 'ssd -D' and having one new daemon running for every connection? I'm not personally convinced it's "better placed elsewhere". If tcp_wrappers is yanked out, perhaps a friendly note in the documentation explaining just this suggestion would help replace it. From lionelcons1972 at gmail.com Sun Apr 27 02:18:37 2014 From: lionelcons1972 at gmail.com (Lionel Cons) Date: Sat, 26 Apr 2014 18:18:37 +0200 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: References: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> <20140423194006.GA18585@zoho.com> <1398476108.17492.1@slate> <20140426155741.GA3568@vectra.student.iastate.edu> Message-ID: On 26 April 2014 18:14, Nico Kadel-Garcia wrote: > On Sat, Apr 26, 2014 at 11:57 AM, Nicolai > wrote: >> On Fri, Apr 25, 2014 at 08:35:08PM -0500, Karl O. Pinc wrote: >>> I bet sshd could be run from a tcpwrapper enabled inetd >>> using 'sshd -D'. >> >> Good point. I use -ieDf for ssh over CurveCP and it works like a charm >> even on old hardware. So really, the desired functionality will still >> be in OpenSSH, and there will still be at least two distinct ways of >> getting it (instead of three). It's sensible to remove duplicate >> functionality in OpenSSH, particularly where it's better placed >> elsewhere. >> >> So people can look at -i and -D flags. They work! > > Isn't it significantly more efficient to allow sshd to do its own > forks, rather than doing 'ssd -D' and having one new daemon running > for every connection? I'm not personally convinced it's "better placed > elsewhere". If tcp_wrappers is yanked out, perhaps a friendly note in > the documentation explaining just this suggestion would help replace > it. Sure. The documentation will be a fully-blown CERN Security announcement that openssh dropped a vital security feature. We've just drafted one and will submit it once the matching openssh release will hit the release download area. Lionel From dtucker at zip.com.au Sun Apr 27 03:01:49 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 26 Apr 2014 13:01:49 -0400 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: References: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> <20140423194006.GA18585@zoho.com> <1398476108.17492.1@slate> <20140426155741.GA3568@vectra.student.iastate.edu> Message-ID: On Sat, Apr 26, 2014 at 12:14 PM, Nico Kadel-Garcia wrote: > > Isn't it significantly more efficient to allow sshd to do its own > forks, rather than doing 'ssd -D' sshd -i > and having one new daemon running > for every connection? In the common case, probably not, since sshd re-execs itself on each connection (using a lot of code originally for -i) to provide randomization of the runtime environment (ASLR and such). Protocol 1 connections will need to generate an ephemeral server key so they'll probably be noticeably slower. -- 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 nkadel at gmail.com Sun Apr 27 03:45:39 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 26 Apr 2014 13:45:39 -0400 Subject: VETO! Re: heads up: tcpwrappers support going away In-Reply-To: References: <558BFE6B-346D-48E8-BC13-C3032C1DA20A@eviladmin.org> <20140423194006.GA18585@zoho.com> <1398476108.17492.1@slate> <20140426155741.GA3568@vectra.student.iastate.edu> Message-ID: On Sat, Apr 26, 2014 at 1:01 PM, Darren Tucker wrote: > On Sat, Apr 26, 2014 at 12:14 PM, Nico Kadel-Garcia > wrote: >> >> Isn't it significantly more efficient to allow sshd to do its own >> forks, rather than doing 'ssd -D' > > > sshd -i Good point, yes. >> and having one new daemon running >> for every connection? > > > In the common case, probably not, since sshd re-execs itself on each > connection (using a lot of code originally for -i) to provide randomization > of the runtime environment (ASLR and such). Protocol 1 connections will need > to generate an ephemeral server key so they'll probably be noticeably > slower. Has anyone actually using this approach, with or without tcp_wrappers, gathered any statistics for the current release? From eric at rigelfore.com Mon Apr 28 01:59:44 2014 From: eric at rigelfore.com (Eric Melville) Date: Sun, 27 Apr 2014 11:59:44 -0400 (EDT) Subject: environment logged by debug3 (-vvv) Message-ID: <863888689.648392.1398614384709.open-xchange@email.1and1.com> When using debug3 one gets all kinds of lovely environment information - debug3: Ignored env TMPDIR debug3: Ignored env TERM_PROGRAM_VERSION debug3: Ignored env Apple_PubSub_Socket_Render debug3: Ignored env __CHECKFIX1436934 debug3: Ignored env TERM_PROGRAM debug3: Ignored env TERM_SESSION_ID debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env TERM debug3: Ignored env DISPLAY debug3: Ignored env __CF_USER_TEXT_ENCODING debug3: Ignored env SHELL debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env USER debug3: Ignored env PATH debug3: Ignored env SHLVL debug3: Ignored env PWD debug3: Ignored env OLDPWD debug3: Ignored env _ However, it appears to be limited to telling the user which variables are being ignored. It would be useful to see what variables are impacting the session as well, such as KRB5CCNAME and any X11/DISPLAY related variables, spelled out, as well. Thanks! From daggs at gmx.com Mon Apr 28 04:30:15 2014 From: daggs at gmx.com (daggs at gmx.com) Date: Sun, 27 Apr 2014 14:30:15 -0400 Subject: right match rule for port and address in sshd_config Message-ID: <20140427183016.10760@gmx.com> Greetings, I want to create a set of rules that will be in affect when I connection originates from outside of my local lan (internet) and on a specific port, this is what I've wrote: Match LocalPort 11111, Address *,!10.0.0.0/24 but when I start ssh, I get this error: Invalid LocalPort '11111,' on Match line /etc/ssh/sshd_config line 176: Bad Match condition why is that? how can I solve it? Thanks. From dtucker at zip.com.au Mon Apr 28 04:50:51 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 27 Apr 2014 14:50:51 -0400 Subject: right match rule for port and address in sshd_config In-Reply-To: <20140427183016.10760@gmx.com> References: <20140427183016.10760@gmx.com> Message-ID: On 27 Apr 2014 14:30, wrote: > > Greetings, > > I want to create a set of rules that will be in affect when I connection originates from outside of my local lan (internet) and on a specific port, this is what I've wrote: > Match LocalPort 11111, Address *,!10.0.0.0/24 Try removing the trailing comma after the port number. From daggs at gmx.com Mon Apr 28 05:10:17 2014 From: daggs at gmx.com (daggs at gmx.com) Date: Sun, 27 Apr 2014 15:10:17 -0400 Subject: right match rule for port and address in sshd_config Message-ID: <20140427191018.10770@gmx.com> > ----- Original Message ----- > From: Darren Tucker > Sent: 04/27/14 09:50 PM > To: daggs at gmx.com > Subject: Re: right match rule for port and address in sshd_config > > On 27 Apr 2014 14:30, wrote: > > > > Greetings, > > > > I want to create a set of rules that will be in affect when I connection > originates from outside of my local lan (internet) and on a specific port, > this is what I've wrote: > > Match LocalPort 11111, Address *,!10.0.0.0/24 > > Try removing the trailing comma after the port number. thanks, that seems to have solved it. From djm at mindrot.org Mon Apr 28 09:14:28 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 28 Apr 2014 09:14:28 +1000 (EST) Subject: environment logged by debug3 (-vvv) In-Reply-To: <863888689.648392.1398614384709.open-xchange@email.1and1.com> References: <863888689.648392.1398614384709.open-xchange@email.1and1.com> Message-ID: On Sun, 27 Apr 2014, Eric Melville wrote: > However, it appears to be limited to telling the user which variables > are being ignored. It would be useful to see what variables are > impacting the session as well, such as KRB5CCNAME and any X11/DISPLAY > related variables, spelled out, as well. If you run with 'ssh -vv' (i.e. less than three 'v' options) then you won't see the 'Ignored' lines and will just see the 'Sending' lines. > if (!matched) { > debug3("Ignored env %s", name); > free(name); > continue; > } > > debug("Sending env %s = %s", name, val); This only applies to environment variables that are explicitly passed. Some are implicitly passed ($TERM) and others are implicitly set by forwarding and authentication ($DISPLAY, $SSH_AUTH_SOCK, $KRB5CCNAME). The ones that are implicitly set are done by the server, so there are no easy ways for the client to see what the server is setting them to. If you run a server in debug mode ('sshd -ddd') then you'll see everything the server sets. -d From openssh-unix-dev at thegeezer.net Tue Apr 29 05:43:12 2014 From: openssh-unix-dev at thegeezer.net (TheGezer) Date: Mon, 28 Apr 2014 20:43:12 +0100 Subject: public key authentication -- log invalid keys In-Reply-To: <535A966B.3040701@thegeezer.net> References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> <535A966B.3040701@thegeezer.net> Message-ID: <535EAF50.9080009@thegeezer.net> OK so i've been doing some digging and a bit more testing. seems i do get an error but only in verbose loglevel. but I have to increase LogLevel to verbose to only get " [sshd] Failed publickey for root " undeterred i went digging in the source it looks like auth2-pubkey.c has function "user_key_allowed" which in turn calls "user_key_allowed2" which calls "check_authkeys_file" so there is a line for key not found, but i'm not getting this with LogLevel = VERBOSE http://fossies.org/dox/openssh-6.6p1/auth2-pubkey_8c_source.html#l00651 418 if (!found_key) 419 debug2("key not found"); so with LogLevel DEBUG2 and this gives me much much more info including "key not found" OK so far so good, the logging I requested is there but at debug2 level, or more generically at verbose level. with more and more bruteforce toys being available online I do wonder if this kind of thing really ought to be at a higher volume to alert that unknown keys are being used on systems. with lost/stolen keys I would imagine most people would delete and recreate rather than making use of RevokedKeys, and so not know if folks are silently trying to connect to their hosts. I do appreciate though that many machines will try their public keys first and thus possibly create unnecessary noise in logs. is it worth making this a config file option that could be enabled / disabled on sshd start ? or am i alone in this line of thinking and should just patch my source appropriately? please let me know your thoughts, thanks From sduckwo at clemson.edu Tue Apr 29 06:13:53 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Mon, 28 Apr 2014 16:13:53 -0400 Subject: public key authentication -- log invalid keys In-Reply-To: <535A966B.3040701@thegeezer.net> References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> <535A966B.3040701@thegeezer.net> Message-ID: On Fri, Apr 25, 2014 at 1:07 PM, TheGezer wrote: > On 04/25/2014 05:41 PM, Eldon Koyle wrote: > > I think you could end up with a lot of false positives doing this. > yup > > I know I have quite a few keys that my client will try before falling > > back to password authentication. You would need to have enough logic in > > your script to see if the authentication succeeds at some point or have > > a very high limit. > > > > It might be more interesting to make a database of bad public keys or > interestingly openssh *does* log revoked keys > http://en.wikibooks.org/wiki/OpenSSH/Logging#Logging_Revoked_Keys > > fingerprints and block any addresses that attempt one of them (assuming > > you can get openssh to log the failed keys somehow). > > > if only i knew how to log the failed keys :) > If sshd doesn't log what you need, perhaps you can use AuthorizedKeysCommand with the akcenv patch [ https://github.com/ScottDuckworth/openssh-akcenv] to generate the logs for you. The akcenv patch passes the key and the fingerprint to the AuthorizedKeysCommand process in environment variables, so you could make a script that searches for the matching key in ~/.ssh/authorized_keys (or some other source) and write to a log (or update your firewall directly) if it's not found. The akcenv patch was first proposed on this mailing list last month, ending up with what seemed like a general consensus of being a good thing, but seems to have fizzled out in the bug tracker [ https://bugzilla.mindrot.org/show_bug.cgi?id=2081]. If you find it of use for your scenario (which is very different than the use case it was designed for) then please update that bug so that the maintainers know it's useful for multiple things. From djm at mindrot.org Tue Apr 29 14:30:42 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 29 Apr 2014 14:30:42 +1000 (EST) Subject: public key authentication -- log invalid keys In-Reply-To: <535EAF50.9080009@thegeezer.net> References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> <535A966B.3040701@thegeezer.net> <535EAF50.9080009@thegeezer.net> Message-ID: On Mon, 28 Apr 2014, TheGezer wrote: > OK so i've been doing some digging and a bit more testing. seems i do > get an error but only in verbose loglevel. > but I have to increase LogLevel to verbose to only get > " [sshd] Failed publickey for root " OpenSSH since 6.3 logs the key for success and failure at LogLevel=verbose: Apr 29 14:27:35 fuyu sshd[11783]: Failed publickey for djm from 192.168.0.5 port 45142 ssh2: ECDSA c9:e8:d5:d6:ed:59:fe:10:52:e4:4f:95:13:e8:fd:01 From ymartin1040 at gmail.com Wed Apr 30 20:42:02 2014 From: ymartin1040 at gmail.com (Yves Martin) Date: Wed, 30 Apr 2014 12:42:02 +0200 Subject: SSH command line behavior with explicit identity file Message-ID: Hello, I got a trouble with ssh command line when investigating a connection issue to a (Stash/Git) server. When invoking "ssh -p 7999 -i /path/to/my/id_dsa git at stashserver" I just got the answer "Permission denied (publickey)." I had to enable traces: "ssh -t -p 7999 -i /path/to/my/id_dsa git at stashserver" to understand why: debug1: Server accepts key: pkalg ssh-dss blen 433 debug1: could not open key file '/path/to/my/id_dsa': Permission denied debug1: No more authentication methods to try. Permission denied (publickey). In my opinion, I would expect that ssh command outputs to stderr the "could not open key file '/path/to/my/id_dsa': Permission denied" message when a identity file is explicitly given in options. What do you think about that error handling proposal ? Thank you for your attention Best regards -- Yves Martin From djm at mindrot.org Wed Apr 30 23:36:35 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Apr 2014 23:36:35 +1000 (EST) Subject: SSH command line behavior with explicit identity file In-Reply-To: References: Message-ID: On Wed, 30 Apr 2014, Yves Martin wrote: > In my opinion, I would expect that ssh command outputs to stderr the "could > not open key file '/path/to/my/id_dsa': Permission denied" message when a > identity file is explicitly given in options. You neglected to mention which OpenSSH version you are using. Recent versions do warn: [djm at haru ~]$ ssh -i /root/xxx 127.0.0.1 Warning: Identity file /root/xxx not accessible: Permission denied.