From Vincent.LEFEVERE at hei.fr Wed Feb 1 01:03:45 2017 From: Vincent.LEFEVERE at hei.fr (Vincent LEFEVERE) Date: Tue, 31 Jan 2017 14:03:45 +0000 Subject: log port forwarding Message-ID: <5a5c83b196c7483ab7548138a98074f4@FRL13RTVM20.campus-hei.intranet> Hello Needing to log all outbound tunnels via sshd and noting that this option was not available, I propose a patch to enable this logging via sshd_config. Best regards Vincent Lef?v?re -------------- next part -------------- A non-text attachment was scrubbed... Name: log_port_forwarding.patch.gz Type: application/x-gzip Size: 1597 bytes Desc: log_port_forwarding.patch.gz URL: From sudarshan12s at gmail.com Wed Feb 1 04:44:40 2017 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Tue, 31 Jan 2017 23:14:40 +0530 Subject: ^C doesnt work on ssh session In-Reply-To: References: <587D2053.7090605@eviladmin.org> Message-ID: Hi Darren, I m sending sshd logs : any suggestion/hint please ... /usr/bin/sshd -ddd -p 2024 -f /etc/ssh/sshd_config -h /etc/ssh_key debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 764 debug2: parse_server_config: config /etc/ssh/sshd_config len 764 debug3: /etc/ssh/sshd_config:2 setting Port 22 debug3: /etc/ssh/sshd_config:3 setting Protocol 2 debug3: /etc/ssh/sshd_config:4 setting HostKey /etc/ssh/ssh_host_key debug3: /etc/ssh/sshd_config:5 setting HostKey /etc/ssh/ssh_host_rsa_key debug3: /etc/ssh/sshd_config:6 setting MACs hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com debug3: macs ok: [hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com] debug3: /etc/ssh/sshd_config:7 setting Ciphers aes128-ctr,aes192-ctr,aes256-ctr debug3: ciphers ok: [aes128-ctr,aes192-ctr,aes256-ctr] debug3: /etc/ssh/sshd_config:8 setting AllowUsers root debug3: /etc/ssh/sshd_config:10 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /etc/ssh/sshd_config:11 setting PermitEmptyPasswords yes debug3: /etc/ssh/sshd_config:12 setting PasswordAuthentication yes debug3: /etc/ssh/sshd_config:13 setting ChallengeResponseAuthentication no debug3: /etc/ssh/sshd_config:14 setting AllowAgentForwarding no debug3: /etc/ssh/sshd_config:15 setting GatewayPorts no debug3: /etc/ssh/sshd_config:16 setting X11Forwarding no debug3: /etc/ssh/sshd_config:17 setting TCPKeepAlive yes debug3: /etc/ssh/sshd_config:18 setting PidFile /tmp/sshd.pid debug3: /etc/ssh/sshd_config:19 setting UsePrivilegeSeparation no debug3: /etc/ssh/sshd_config:20 setting ClientAliveInterval 15 debug3: /etc/ssh/sshd_config:21 setting ClientAliveCountMax 3 debug3: /etc/ssh/sshd_config:22 setting MaxStartups 25 debug3: /etc/ssh/sshd_config:23 setting PermitTunnel no debug3: /etc/ssh/sshd_config:24 setting DenyPortFwd 127.0.0.0/8 debug1: Deny port forwarding to host 127.0.0.0/8 debug3: /etc/ssh/sshd_config:25 setting Subsystem sftp /usr/libexec/sftp-server debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1h 5 Jun 2014 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 "/etc/ssh_key" as a RSA1 public key debug1: private host key: #0 type 1 RSA debug1: could not open key file '/etc/ssh/ssh_host_key': No such file or directory Could not load host key: /etc/ssh/ssh_host_key debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': No such file or directory Could not load host key: /etc/ssh/ssh_host_rsa_key debug1: rexec_argv[0]='/usr/bin/sshd' debug1: rexec_argv[1]='-ddd' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2024' debug1: rexec_argv[4]='-f' debug1: rexec_argv[5]='/etc/ssh/sshd_config' debug1: rexec_argv[6]='-h' debug1: rexec_argv[7]='/etc/ssh_key' debug3: oom_adjust_setup Set /proc/self/oom_score_adj from 0 to -1000 debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2024 on 0.0.0.0. Server listening on 0.0.0.0 port 2024. debug2: fd 4 setting O_NONBLOCK debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Bind to port 2024 on ::. Server listening on :: port 2024. debug3: fd 5 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 764 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 10.220.82.17 port 52586 on 10.100.212.166 port 2024 debug1: Client protocol version 2.0; client software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6 debug2: fd 3 setting O_NONBLOCK debug1: list_hostkey_types: ssh-rsa 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-rsa debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-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,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-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: mac_setup: setup hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none debug2: mac_setup: setup hmac-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received WARNING: /usr/local/etc/moduli does not exist, using fixed modulus debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: bits set: 1088/2048 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: bits set: 1005/2048 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: Trying to reverse map address 10.220.82.17. debug2: parse_server_config: config reprocess config len 764 debug3: auth_shadow_acctexpired: today 17197 sp_expire -1 days left -17198 debug3: account expiration disabled debug2: input_userauth_request: setting up authctxt for root debug2: input_userauth_request: try method none debug3: auth_shadow_pwexpired: today 17197 sp_lstchg 17177 sp_max 99999 Failed none for root from 10.220.82.17 port 52586 ssh2 debug3: userauth_finish: failure partial=0 next methods="publickey,password" debug1: userauth-request for user root service ssh-connection method password debug1: attempt 1 failures 0 debug2: input_userauth_request: try method password Accepted password for root from 10.220.82.17 port 52586 ssh2 debug1: Entering interactive session for SSH2. debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/2 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 shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell Starting session: shell on pts/2 for root from 10.220.82.17 port 52586 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: channel 0: rfd 8 isatty debug2: fd 8 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug2: channel 0: request keepalive at openssh.com confirm 1 debug1: Got 100/12 for keepalive debug1: Received SIGCHLD. debug1: session_by_pid: pid 1871 debug1: session_exit_message: session 0 channel 0 pid 1871 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 debug1: session_pty_cleanup: session 0 release /dev/pts/2 debug2: channel 0: read<=0 rfd 8 len -1 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: channel 0: send close debug2: notify_done: reading debug3: channel 0: will not send data after close debug2: channel 0: rcvd close Received disconnect from 10.220.82.17: 11: disconnected by user debug1: do_cleanup ssh logs: ssh -vvv root at 10.100.212.166 -p 2024 OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.100.212.166 [10.100.212.166] port 2024. debug1: Connection established. debug1: identity file /home/ssoma/.ssh/identity type -1 debug1: identity file /home/ssoma/.ssh/identity-cert type -1 debug1: identity file /home/ssoma/.ssh/id_rsa type -1 debug1: identity file /home/ssoma/.ssh/id_rsa-cert type -1 debug1: identity file /home/ssoma/.ssh/id_dsa type -1 debug1: identity file /home/ssoma/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6 debug1: match: OpenSSH_6.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug3: Wrote 960 bytes for a total of 981 debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-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,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-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 ,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-rsa debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com 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-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug2: mac_setup: found hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug3: Wrote 24 bytes for a total of 1005 debug2: dh_gen_key: priv key bits set: 154/320 debug2: bits set: 1005/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: Wrote 272 bytes for a total of 1277 debug3: put_host_port: [10.100.212.166]:2024 debug3: put_host_port: [10.100.212.166]:2024 debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /etc/ssh/ssh_known_hosts debug1: checking without port identifier debug3: check_host_in_hostfile: host 10.100.212.166 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host 10.100.212.166 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: match line 135 debug1: Host '10.100.212.166' is known and matches the RSA host key. debug1: Found key in /home/ssoma/.ssh/known_hosts:135 debug1: found matching key w/out port debug2: bits set: 1088/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: Wrote 16 bytes for a total of 1293 debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug3: Wrote 52 bytes for a total of 1345 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/ssoma/.ssh/identity ((nil)) debug2: key: /home/ssoma/.ssh/id_rsa ((nil)) debug2: key: /home/ssoma/.ssh/id_dsa ((nil)) debug3: Wrote 68 bytes for a total of 1413 debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,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/ssoma/.ssh/identity debug3: no such identity: /home/ssoma/.ssh/identity debug1: Trying private key: /home/ssoma/.ssh/id_rsa debug3: no such identity: /home/ssoma/.ssh/id_rsa debug1: Trying private key: /home/ssoma/.ssh/id_dsa debug3: no such identity: /home/ssoma/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password root at 10.100.212.166's password: debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64) debug2: we sent a password packet, wait for reply debug3: Wrote 148 bytes for a total of 1561 debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug3: Wrote 136 bytes for a total of 1697 debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env CCACHE_NOSTATS debug3: Ignored env HOSTNAME debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env HISTSIZE debug3: Ignored env SSH_CLIENT debug3: Ignored env CCACHE_LOGFILE debug3: Ignored env QTDIR debug3: Ignored env QTINC debug3: Ignored env SSH_TTY debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env CSCOPE_EDITOR debug3: Ignored env COVLM debug3: Ignored env MAIL debug3: Ignored env PATH debug3: Ignored env PWD debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env MODULEPATH debug3: Ignored env LOADEDMODULES debug3: Ignored env P4CLIENT debug3: Ignored env SSH_ASKPASS debug3: Ignored env HISTCONTROL debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env QTLIB debug3: Ignored env CVS_RSH debug3: Ignored env SSH_CONNECTION debug3: Ignored env MODULESHOME debug3: Ignored env LESSOPEN debug3: Ignored env P4PORT debug3: Ignored env G_BROKEN_FILENAMES debug3: Ignored env BASH_FUNC_module() debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: Wrote 460 bytes for a total of 2157 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Tue Jan 31 16:45:24 2017 from 10.220.82.17 debug1: permanently_set_uid: 0/0 Environment: USER=root LOGNAME=root HOME=/root PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin MAIL=/var/mail/root SHELL=/bin/bash TZ=UTC SSH_CLIENT=10.220.82.17 52586 2024 SSH_CONNECTION=10.220.82.17 52586 10.100.212.166 2024 SSH_TTY=/dev/pts/2 TERM=xterm -bash: no job control in this shell file setup_env.sh found... On Fri, Jan 20, 2017 at 11:57 AM, Sudarshan Soma wrote: > Thanks Darren, will check on your response. > I am attaching sshd, ssh logs with debug flags. Please see if it gives any > hint: > > when I press ^C in ssh session, no log gets printed in both server/client > side. > > Best Regards, > > > > > On Wed, Jan 18, 2017 at 3:09 AM, Darren Tucker wrote: > >> On Wed, Jan 18, 2017 at 5:10 AM, Sudarshan Soma >> wrote: >> > Thanks Ben. i am checking in linux. >> > I do have this command working: >> > ssh localhost -o password=abc123 >> >> That's definitely a modified ssh binary. >> >> > will try to getback on openssh used. But is it possible to show some >> > pointers for my queries, avoid arguments in ps or /proc >> >> I don't think you reliably can. >> >> You can add a call to setproctitle() to ssh but I don't think that >> affects all sets of options to ps, and even if it did there's still a >> race between when the process starts and when you call setproctitle >> during which the password is exposed. >> >> So don't do that, instead use public-key, or if you must use a >> password read it from a suitably locked down file. You can (with some >> difficulty) get ssh to read a password via an $SSH_ASKPASS program. >> >> > and other one was on ^C not working on my ssh sessions. >> >> just a guess but check the permissions on /dev/tty on the server. >> They should look like: >> crw-rw-rw- 1 root tty 5, 0 Jan 17 19:34 /dev/tty >> >> Failing that please post the debug output of ssh -vvv and sshd -ddd >> from an unmodified (ie as available from openssh.com) client and >> server pair. >> >> -- >> Darren Tucker (dtucker at zip.com.au) >> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA >> (new) >> Good judgement comes with experience. Unfortunately, the experience >> usually comes from bad judgement. >> > > From sudarshan12s at gmail.com Wed Feb 1 05:04:31 2017 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Tue, 31 Jan 2017 23:34:31 +0530 Subject: ^C doesnt work on ssh session In-Reply-To: References: <587D2053.7090605@eviladmin.org> Message-ID: echo $TERM xterm does this variable cause issue, setting it to vt100 ( by export TERM=vt100) , doesnt make difference. On Tue, Jan 31, 2017 at 11:14 PM, Sudarshan Soma wrote: > Hi Darren, I m sending sshd logs : any suggestion/hint please ... > > /usr/bin/sshd -ddd -p 2024 -f /etc/ssh/sshd_config -h /etc/ssh_key > debug2: load_server_config: filename /etc/ssh/sshd_config > debug2: load_server_config: done config len = 764 > debug2: parse_server_config: config /etc/ssh/sshd_config len 764 > debug3: /etc/ssh/sshd_config:2 setting Port 22 > debug3: /etc/ssh/sshd_config:3 setting Protocol 2 > debug3: /etc/ssh/sshd_config:4 setting HostKey /etc/ssh/ssh_host_key > debug3: /etc/ssh/sshd_config:5 setting HostKey /etc/ssh/ssh_host_rsa_key > debug3: /etc/ssh/sshd_config:6 setting MACs hmac-sha1-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,hmac-sha2-256,hmac- > sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > debug3: macs ok: [hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac- > ripemd160 at openssh.com] > debug3: /etc/ssh/sshd_config:7 setting Ciphers > aes128-ctr,aes192-ctr,aes256-ctr > debug3: ciphers ok: [aes128-ctr,aes192-ctr,aes256-ctr] > debug3: /etc/ssh/sshd_config:8 setting AllowUsers root > debug3: /etc/ssh/sshd_config:10 setting AuthorizedKeysFile > .ssh/authorized_keys > debug3: /etc/ssh/sshd_config:11 setting PermitEmptyPasswords yes > debug3: /etc/ssh/sshd_config:12 setting PasswordAuthentication yes > debug3: /etc/ssh/sshd_config:13 setting ChallengeResponseAuthentication no > debug3: /etc/ssh/sshd_config:14 setting AllowAgentForwarding no > debug3: /etc/ssh/sshd_config:15 setting GatewayPorts no > debug3: /etc/ssh/sshd_config:16 setting X11Forwarding no > debug3: /etc/ssh/sshd_config:17 setting TCPKeepAlive yes > debug3: /etc/ssh/sshd_config:18 setting PidFile /tmp/sshd.pid > debug3: /etc/ssh/sshd_config:19 setting UsePrivilegeSeparation no > debug3: /etc/ssh/sshd_config:20 setting ClientAliveInterval 15 > debug3: /etc/ssh/sshd_config:21 setting ClientAliveCountMax 3 > debug3: /etc/ssh/sshd_config:22 setting MaxStartups 25 > debug3: /etc/ssh/sshd_config:23 setting PermitTunnel no > debug3: /etc/ssh/sshd_config:24 setting DenyPortFwd 127.0.0.0/8 > debug1: Deny port forwarding to host 127.0.0.0/8 > debug3: /etc/ssh/sshd_config:25 setting Subsystem sftp > /usr/libexec/sftp-server > debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1h 5 Jun 2014 > 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 "/etc/ssh_key" as a RSA1 public key > debug1: private host key: #0 type 1 RSA > debug1: could not open key file '/etc/ssh/ssh_host_key': No such file or > directory > Could not load host key: /etc/ssh/ssh_host_key > debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': No such file > or directory > Could not load host key: /etc/ssh/ssh_host_rsa_key > debug1: rexec_argv[0]='/usr/bin/sshd' > debug1: rexec_argv[1]='-ddd' > debug1: rexec_argv[2]='-p' > debug1: rexec_argv[3]='2024' > debug1: rexec_argv[4]='-f' > debug1: rexec_argv[5]='/etc/ssh/sshd_config' > debug1: rexec_argv[6]='-h' > debug1: rexec_argv[7]='/etc/ssh_key' > debug3: oom_adjust_setup > Set /proc/self/oom_score_adj from 0 to -1000 > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 2024 on 0.0.0.0. > Server listening on 0.0.0.0 port 2024. > debug2: fd 4 setting O_NONBLOCK > debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY > debug1: Bind to port 2024 on ::. > Server listening on :: port 2024. > > > > > > > > > > > > > > > > > > > > > debug3: fd 5 is not O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 8 config len 764 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 > debug1: inetd sockets after dupping: 3, 3 > Connection from 10.220.82.17 port 52586 on 10.100.212.166 port 2024 > debug1: Client protocol version 2.0; client software version OpenSSH_5.3 > debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.6 > debug2: fd 3 setting O_NONBLOCK > debug1: list_hostkey_types: ssh-rsa > 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-rsa > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac- > sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac- > sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: diffie-hellman-group-exchange- > sha256,diffie-hellman-group-exchange-sha1,diffie-hellman- > group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com,s > sh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh > -dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256- > ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish- > cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256- > ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish- > cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com, > hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com > ,hmac-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: mac_setup: setup hmac-sha1 > debug1: kex: client->server aes128-ctr hmac-sha1 none > debug2: mac_setup: setup hmac-sha1 > debug1: kex: server->client aes128-ctr hmac-sha1 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > WARNING: /usr/local/etc/moduli does not exist, using fixed modulus > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug2: bits set: 1088/2048 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug2: bits set: 1005/2048 > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: KEX done > debug1: userauth-request for user root service ssh-connection method none > debug1: attempt 0 failures 0 > debug3: Trying to reverse map address 10.220.82.17. > debug2: parse_server_config: config reprocess config len 764 > debug3: auth_shadow_acctexpired: today 17197 sp_expire -1 days left -17198 > debug3: account expiration disabled > debug2: input_userauth_request: setting up authctxt for root > debug2: input_userauth_request: try method none > debug3: auth_shadow_pwexpired: today 17197 sp_lstchg 17177 sp_max 99999 > Failed none for root from 10.220.82.17 port 52586 ssh2 > debug3: userauth_finish: failure partial=0 next > methods="publickey,password" > debug1: userauth-request for user root service ssh-connection method > password > debug1: attempt 1 failures 0 > debug2: input_userauth_request: try method password > Accepted password for root from 10.220.82.17 port 52586 ssh2 > debug1: Entering interactive session for SSH2. > debug2: fd 4 setting O_NONBLOCK > debug2: fd 5 setting O_NONBLOCK > debug1: server_init_dispatch_20 > debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max > 16384 > debug1: input_session_request > debug1: channel 0: new [server-session] > debug2: session_new: allocate (allocated 0 max 10) > debug3: session_unused: session id 0 unused > debug1: session_new: session 0 > debug1: session_open: channel 0 > debug1: session_open: session 0: link with channel 0 > debug1: server_input_channel_open: confirm session > debug1: server_input_global_request: rtype no-more-sessions at openssh.com > want_reply 0 > debug1: server_input_channel_req: channel 0 request pty-req reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req pty-req > debug1: Allocating pty. > debug1: session_pty_req: session 0 alloc /dev/pts/2 > 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 shell reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req shell > Starting session: shell on pts/2 for root from 10.220.82.17 port 52586 > debug2: fd 3 setting TCP_NODELAY > debug3: packet_set_tos: set IP_TOS 0x10 > debug2: channel 0: rfd 8 isatty > debug2: fd 8 setting O_NONBLOCK > debug3: fd 6 is O_NONBLOCK > debug2: channel 0: request keepalive at openssh.com confirm 1 > debug1: Got 100/12 for keepalive > > debug1: Received SIGCHLD. > debug1: session_by_pid: pid 1871 > debug1: session_exit_message: session 0 channel 0 pid 1871 > 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 > debug1: session_pty_cleanup: session 0 release /dev/pts/2 > debug2: channel 0: read<=0 rfd 8 len -1 > debug2: channel 0: read failed > debug2: channel 0: close_read > debug2: channel 0: input open -> drain > debug2: channel 0: ibuf empty > debug2: channel 0: send eof > debug2: channel 0: input drain -> closed > debug2: channel 0: send close > debug2: notify_done: reading > debug3: channel 0: will not send data after close > debug2: channel 0: rcvd close > Received disconnect from 10.220.82.17: 11: disconnected by user > debug1: do_cleanup > > > > > ssh logs: > > ssh -vvv root at 10.100.212.166 -p 2024 > OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 10.100.212.166 [10.100.212.166] port 2024. > debug1: Connection established. > debug1: identity file /home/ssoma/.ssh/identity type -1 > debug1: identity file /home/ssoma/.ssh/identity-cert type -1 > debug1: identity file /home/ssoma/.ssh/id_rsa type -1 > debug1: identity file /home/ssoma/.ssh/id_rsa-cert type -1 > debug1: identity file /home/ssoma/.ssh/id_dsa type -1 > debug1: identity file /home/ssoma/.ssh/id_dsa-cert type -1 > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6 > debug1: match: OpenSSH_6.6 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.3 > debug2: fd 4 setting O_NONBLOCK > debug1: SSH2_MSG_KEXINIT sent > debug3: Wrote 960 bytes for a total of 981 > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: diffie-hellman-group-exchange- > sha256,diffie-hellman-group-exchange-sha1,diffie-hellman- > group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com,s > sh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh > -dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256- > ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish- > cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256- > ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish- > cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com, > hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com > ,hmac-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, > 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-rsa > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr > debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac- > sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac- > sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > 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-sha1 > debug1: kex: server->client aes128-ctr hmac-sha1 none > debug2: mac_setup: found hmac-sha1 > debug1: kex: client->server aes128-ctr hmac-sha1 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug3: Wrote 24 bytes for a total of 1005 > debug2: dh_gen_key: priv key bits set: 154/320 > debug2: bits set: 1005/2048 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: Wrote 272 bytes for a total of 1277 > debug3: put_host_port: [10.100.212.166]:2024 > debug3: put_host_port: [10.100.212.166]:2024 > debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename > /home/ssoma/.ssh/known_hosts > debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename > /home/ssoma/.ssh/known_hosts > debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename > /etc/ssh/ssh_known_hosts > debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename > /etc/ssh/ssh_known_hosts > debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename > /home/ssoma/.ssh/known_hosts > debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename > /home/ssoma/.ssh/known_hosts > debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename > /etc/ssh/ssh_known_hosts > debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename > /etc/ssh/ssh_known_hosts > debug1: checking without port identifier > debug3: check_host_in_hostfile: host 10.100.212.166 filename > /home/ssoma/.ssh/known_hosts > debug3: check_host_in_hostfile: host 10.100.212.166 filename > /home/ssoma/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 135 > debug1: Host '10.100.212.166' is known and matches the RSA host key. > debug1: Found key in /home/ssoma/.ssh/known_hosts:135 > debug1: found matching key w/out port > debug2: bits set: 1088/2048 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug3: Wrote 16 bytes for a total of 1293 > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug3: Wrote 52 bytes for a total of 1345 > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /home/ssoma/.ssh/identity ((nil)) > debug2: key: /home/ssoma/.ssh/id_rsa ((nil)) > debug2: key: /home/ssoma/.ssh/id_dsa ((nil)) > debug3: Wrote 68 bytes for a total of 1413 > debug1: Authentications that can continue: publickey,password > debug3: start over, passed a different list publickey,password > debug3: preferred gssapi-keyex,gssapi-with-mic,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/ssoma/.ssh/identity > debug3: no such identity: /home/ssoma/.ssh/identity > debug1: Trying private key: /home/ssoma/.ssh/id_rsa > debug3: no such identity: /home/ssoma/.ssh/id_rsa > debug1: Trying private key: /home/ssoma/.ssh/id_dsa > debug3: no such identity: /home/ssoma/.ssh/id_dsa > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: ,password > debug3: authmethod_is_enabled password > debug1: Next authentication method: password > root at 10.100.212.166's password: > debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64) > debug2: we sent a password packet, wait for reply > debug3: Wrote 148 bytes for a total of 1561 > debug1: Authentication succeeded (password). > debug1: channel 0: new [client-session] > debug3: ssh_session2_open: channel_new: 0 > debug2: channel 0: send open > debug1: Requesting no-more-sessions at openssh.com > debug1: Entering interactive session. > debug3: Wrote 136 bytes for a total of 1697 > debug2: callback start > debug2: client_session2_setup: id 0 > debug2: channel 0: request pty-req confirm 1 > debug1: Sending environment. > debug3: Ignored env CCACHE_NOSTATS > debug3: Ignored env HOSTNAME > debug3: Ignored env TERM > debug3: Ignored env SHELL > debug3: Ignored env HISTSIZE > debug3: Ignored env SSH_CLIENT > debug3: Ignored env CCACHE_LOGFILE > debug3: Ignored env QTDIR > debug3: Ignored env QTINC > debug3: Ignored env SSH_TTY > debug3: Ignored env USER > debug3: Ignored env LS_COLORS > debug3: Ignored env CSCOPE_EDITOR > debug3: Ignored env COVLM > debug3: Ignored env MAIL > debug3: Ignored env PATH > debug3: Ignored env PWD > debug1: Sending env LANG = en_US.UTF-8 > debug2: channel 0: request env confirm 0 > debug3: Ignored env MODULEPATH > debug3: Ignored env LOADEDMODULES > debug3: Ignored env P4CLIENT > debug3: Ignored env SSH_ASKPASS > debug3: Ignored env HISTCONTROL > debug3: Ignored env SHLVL > debug3: Ignored env HOME > debug3: Ignored env LOGNAME > debug3: Ignored env QTLIB > debug3: Ignored env CVS_RSH > debug3: Ignored env SSH_CONNECTION > debug3: Ignored env MODULESHOME > debug3: Ignored env LESSOPEN > debug3: Ignored env P4PORT > debug3: Ignored env G_BROKEN_FILENAMES > debug3: Ignored env BASH_FUNC_module() > debug3: Ignored env _ > debug2: channel 0: request shell confirm 1 > debug2: fd 4 setting TCP_NODELAY > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug3: Wrote 460 bytes for a total of 2157 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: PTY allocation request accepted on channel 0 > debug2: channel 0: rcvd adjust 2097152 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: shell request accepted on channel 0 > Last login: Tue Jan 31 16:45:24 2017 from 10.220.82.17 > debug1: permanently_set_uid: 0/0 > Environment: > USER=root > LOGNAME=root > HOME=/root > PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin > MAIL=/var/mail/root > SHELL=/bin/bash > TZ=UTC > SSH_CLIENT=10.220.82.17 52586 2024 > SSH_CONNECTION=10.220.82.17 52586 10.100.212.166 2024 > SSH_TTY=/dev/pts/2 > TERM=xterm > -bash: no job control in this shell > file setup_env.sh found... > > > On Fri, Jan 20, 2017 at 11:57 AM, Sudarshan Soma > wrote: > >> Thanks Darren, will check on your response. >> I am attaching sshd, ssh logs with debug flags. Please see if it gives >> any hint: >> >> when I press ^C in ssh session, no log gets printed in both server/client >> side. >> >> Best Regards, >> >> >> >> >> On Wed, Jan 18, 2017 at 3:09 AM, Darren Tucker >> wrote: >> >>> On Wed, Jan 18, 2017 at 5:10 AM, Sudarshan Soma >>> wrote: >>> > Thanks Ben. i am checking in linux. >>> > I do have this command working: >>> > ssh localhost -o password=abc123 >>> >>> That's definitely a modified ssh binary. >>> >>> > will try to getback on openssh used. But is it possible to show some >>> > pointers for my queries, avoid arguments in ps or /proc >>> >>> I don't think you reliably can. >>> >>> You can add a call to setproctitle() to ssh but I don't think that >>> affects all sets of options to ps, and even if it did there's still a >>> race between when the process starts and when you call setproctitle >>> during which the password is exposed. >>> >>> So don't do that, instead use public-key, or if you must use a >>> password read it from a suitably locked down file. You can (with some >>> difficulty) get ssh to read a password via an $SSH_ASKPASS program. >>> >>> > and other one was on ^C not working on my ssh sessions. >>> >>> just a guess but check the permissions on /dev/tty on the server. >>> They should look like: >>> crw-rw-rw- 1 root tty 5, 0 Jan 17 19:34 /dev/tty >>> >>> Failing that please post the debug output of ssh -vvv and sshd -ddd >>> from an unmodified (ie as available from openssh.com) client and >>> server pair. >>> >>> -- >>> Darren Tucker (dtucker at zip.com.au) >>> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA >>> (new) >>> Good judgement comes with experience. Unfortunately, the experience >>> usually comes from bad judgement. >>> >> >> > From Zube at stat.colostate.edu Wed Feb 1 05:21:57 2017 From: Zube at stat.colostate.edu (Zube) Date: Tue, 31 Jan 2017 11:21:57 -0700 Subject: sshd 7.4p1 with ssl 1.0.2j seg faults, MacOSX 10.12.2/3, clang-800.0.42.1 In-Reply-To: References: <20170125234906.GA52441@quantum.stat.colostate.edu> Message-ID: <20170131182157.GA61146@quantum.stat.colostate.edu> On Thu Jan 26 11:41:50 AM, Darren Tucker wrote: > On Thu, Jan 26, 2017 at 10:49 AM, Zube wrote: > [...] > > regress/unittests/utf8/tests.c: 51 > > test #9 "utf8_inv_badbyt" > > > > ASSERT_INT_EQ (len, wantlen) failed: > > len = 2 > > wantlen = 5 > > That's not a segfault, it's an assertion failure in a UTF8 unit test, > most likely because it's not escaping something that the tests think > should be. > You can skip these tests by setting the environment variable > TEST_SSH_UTF8=no to see if there are other problems. > > The test in question is: > > one("inv_badbyte", "\377x", -2, -2, -2, "\\377x"); > > which passes it through OpenSSH's snmprintf which passes it through a > handful of multibyte and wide character functions, so it's not > immediately obvious what's going on. It passes here on a mac mini > running 11.4.2, though, so it'd be interesting to see what's different > between them. Thank you for your reply. Sorry for the delay in getting back to this. For the record, I do see a segfault if I try to run sshd as a non-root user. Not sure if that is relevant, though. Let me take it from the top and add additional information. openssl 1.0.2k is configured with: ./Configure shared darwin64-x86_64-cc openssh 7.4p1 is configured with: ./configure --prefix=/usr/local/ssh --with-ssl-dir=/usr/local/ssl --with-ldflags=-ldl --with-md5-passwords --with-pam --with-sandbox=rlimit --without-pie On a 10.12.2 machine using Apple LLVM version 7.3.0 (clang-703.0.31), this builds and runs fine. On a 10.12.2 machine using Apple LLVM version 8.0.0 (clang-800.0.42.1), it builds fine, but when executed, I get these two entries in the system logs: com.apple.xpc.launchd[1] (com.apple.ReportCrash.Root[5419]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.ReportCrash.DirectoryService assertion failed 16C67: libsystem_trace.dynlib+76912 [5BD4ECD4-75CA-38EA-AF5C-B481C15955F8]: 0x0 and nothing else. sshd does not run. Then we have the UTF8 failure from the tests noted above. If I set TEST_SSH_UTF8=no and rerun the tests, it fails later on when it tries to run connect.sh: Fatal: no sshd running on port 4242 make[1]: *** [t-exec] Error 1 So, again, sshd built with the latter compiler falls over when executed. Thanks for any additional clues. Perhaps it's time to build or brew gcc and be done with it. Cheers, Zube From sudarshan12s at gmail.com Wed Feb 1 06:05:36 2017 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Wed, 1 Feb 2017 00:35:36 +0530 Subject: sshd custom shell script for specifc user In-Reply-To: References: Message-ID: Hi Darren, the clients config would need customer to change firewall settings to allow 1023 port. my server is behind the firewall. firewall settings say that my server 1023 is not accessable from outside. So If user tries -p 1023, it is rejected. hence user can only issue ssh customuser at ip . I am trying to instead connect to 1023 from my server, which doesnt go to firewall, hence from my server ssh admin at 127.0.0.1 -p 1023 should work. I have shared sshd logs , can you see if it gives hint on why reading passwd happens in sshd side and echo and read for user happens at client side. server logs with debug level=3 debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: Deny port forwarding to host 127.0.0.0/8 debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1h 5 Jun 2014 debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: inetd sockets after dupping: 3, 3 Connection from 10.220.82.17 port 54086 on 10.220.167.184 port 22 debug1: Client protocol version 2.0; client software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6 debug1: list_hostkey_types: ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-ctr hmac-sha1 none debug1: kex: server->client aes128-ctr hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received WARNING: /usr/local/etc/moduli does not exist, using fixed modulus debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user cliuser service ssh-connection method none debug1: attempt 0 failures 0 debug1: user customuser matched 'User customuser' at line 35 Could not get shadow information for customuser Accepted none for cliuser from 10.220.82.17 port 54086 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] 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 debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/3 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 debug1: server_input_channel_req: channel 0 request shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell Starting session: forced-command (config) '. /etc/myscript' on pts/3 for cliuser from 10.220.82.17 port 54086 secadmin at 127.0.0.1's password: On Tue, Jan 31, 2017 at 10:53 AM, Darren Tucker wrote: > On Tue, Jan 31, 2017 at 3:55 PM, Sudarshan Soma > wrote: > > Thanks Darren, the intention to do this : > > allow users to access my own shell/CLI(including authentication) on port > 22. > > their firewall settings doesnt allow anything other than port 22, so I > would > > internally redirect to port 1023 when customuser is provided. > > If the clients are openssh you could use it in "stdio forwarding" mode > to establish an end-to-end connection to the sshd on port 1023. > > You'd configure the server something like this in the main sshd's config: > > Match user customuser > MaxSessions 0 > PermitOpen localhost:1023 > > then in the client's config > > Host yourapplication > ProxyCommand ssh -W localhost:1023 customuser at yourgateway > > which should allow "ssh admin at yourapplication" to work. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From dtucker at zip.com.au Wed Feb 1 08:56:04 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 1 Feb 2017 08:56:04 +1100 Subject: sshd custom shell script for specifc user In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 6:05 AM, Sudarshan Soma wrote: > Hi Darren, the clients config would need customer to change firewall > settings to allow 1023 port. Not in the configuration I proposed: the first ssh command runs the second to connect to the server so you'd end up with TCP connections client -> server:22 and server ->server:1023 and an end-to-end ssh connection from the client to the sshd on port 1023. > ssh admin at 127.0.0.1 -p 1023 should work. I have shared sshd logs , can you > see if it gives hint on why reading passwd happens in sshd side and echo and > read for user happens at client side. Looking at the debug log I think it might be a bug in sshd. The log says it's 6.6, which is a few years old. Is it an unmodified version built from the source from openssh.com, and does the current release (7.4) do the same thing? -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From 1.41421 at gmail.com Wed Feb 1 10:40:53 2017 From: 1.41421 at gmail.com (JCA) Date: Tue, 31 Jan 2017 16:40:53 -0700 Subject: No point compression in SSH2_MSG_KEX_ECDH_INIT Message-ID: I have noticed that the EC public key sent in the SSH2_MSG_KEX_ECDH_INIT message is sent without point compression. Are there any plans to use point compression eventually? I imagine that, in part, you guys are not yet implementing it for patent reasons, right? From adam at continusec.com Wed Feb 1 21:40:56 2017 From: adam at continusec.com (Adam Eijdenberg) Date: Wed, 1 Feb 2017 21:40:56 +1100 Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? Message-ID: As background, for one of my clients we built out a command line tool which does SSO with Google Apps, then generates a new SSH key pair, and sends this off to an internal service which verifies the request and then issues a new short lived (24 hour) certificate (if interested the code for the server and client is open-sourced here: https://github.com/continusec/geecert), overwriting the previous certificate and private key. Some of our users like to use SSH agent forwarding, and while this generally works fine, when our users run their daily command to get a new certificate, their ssh-agent still holds the old one. Would it be reasonable to write a patch to ssh-agent to that changed its behavior to: Check whether a certificate it is going to use is expired (or close to it, or maybe just changed on disk), and if so, check if there is a new certificate at the same location, and if so, drop the current certificate / private key, and replace with the new certificate private key? Alternatively I could change our daily command to check if ssh-agent is running with the cert there, and ask it to add a new one (and somehow clean out the old one), but since I'm a glutton for punishment, I thought I'd ask here whether a more general solution is likely to be accepted if I submitted a patch along those lines. From djm at mindrot.org Wed Feb 1 22:37:30 2017 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 Feb 2017 22:37:30 +1100 (AEDT) Subject: No point compression in SSH2_MSG_KEX_ECDH_INIT In-Reply-To: References: Message-ID: On Tue, 31 Jan 2017, JCA wrote: > I have noticed that the EC public key sent in the SSH2_MSG_KEX_ECDH_INIT > message is sent without point compression. Are there any plans to use point > compression eventually? I imagine that, in part, you guys are not yet > implementing it for patent reasons, right? I'm not aware of any plans for implementing point compression and I don't plan on adding it myself. Motivation for not including it was as much keeping the pre-auth code as simple as possible as anything else. -d From mindrot at hda3.com Thu Feb 2 01:16:44 2017 From: mindrot at hda3.com (Peter Moody) Date: Wed, 1 Feb 2017 06:16:44 -0800 Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: References: Message-ID: why not add the certificate to the running ssh-agent with a timeout that expires when the cert does? I don't think ssh-agent exposes a "how long until this key expires" api, but you can at least use this method to see if the cert/key are *on* the agent and you can assume that if they're on the agent, then they're valid. we make extensive use of the certificates at work and this is how we do it. On Wed, Feb 1, 2017 at 2:40 AM, Adam Eijdenberg wrote: > As background, for one of my clients we built out a command line tool > which does SSO with Google Apps, then generates a new SSH key pair, > and sends this off to an internal service which verifies the request > and then issues a new short lived (24 hour) certificate (if interested > the code for the server and client is open-sourced here: > https://github.com/continusec/geecert), overwriting the previous > certificate and private key. > > Some of our users like to use SSH agent forwarding, and while this > generally works fine, when our users run their daily command to get a > new certificate, their ssh-agent still holds the old one. > > Would it be reasonable to write a patch to ssh-agent to that changed > its behavior to: > > Check whether a certificate it is going to use is expired (or close to > it, or maybe just changed on disk), and if so, check if there is a new > certificate at the same location, and if so, drop the current > certificate / private key, and replace with the new certificate > private key? > > Alternatively I could change our daily command to check if ssh-agent > is running with the cert there, and ask it to add a new one (and > somehow clean out the old one), but since I'm a glutton for > punishment, I thought I'd ask here whether a more general solution is > likely to be accepted if I submitted a patch along those lines. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From sudarshan12s at gmail.com Thu Feb 2 06:58:36 2017 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Thu, 2 Feb 2017 01:28:36 +0530 Subject: sshd custom shell script for specifc user In-Reply-To: References: Message-ID: Thanks Darren. So user has to run the following command (alternatively, he can change .ssh/config) ssh -o ProxyCommand='ssh -W localhost:1023 customuser at 10.220.167.184' admin at 10.220.167.184 It works. But is it possible to change sshd_config (server side settings) , so that user (from client side) has to just type and at server side, we add code to prompt user name , something like this: ssh cliuser at 10.220.167.184 Username: admin password: I am trying alternatives, any quick hint would really help. Thanks !!! On Wed, Feb 1, 2017 at 3:26 AM, Darren Tucker wrote: > On Wed, Feb 1, 2017 at 6:05 AM, Sudarshan Soma > wrote: > > Hi Darren, the clients config would need customer to change firewall > > settings to allow 1023 port. > > Not in the configuration I proposed: the first ssh command runs the > second to connect to the server so you'd end up with TCP connections > client -> server:22 and server ->server:1023 and an end-to-end ssh > connection from the client to the sshd on port 1023. > > > ssh admin at 127.0.0.1 -p 1023 should work. I have shared sshd logs , can > you > > see if it gives hint on why reading passwd happens in sshd side and echo > and > > read for user happens at client side. > > Looking at the debug log I think it might be a bug in sshd. The log > says it's 6.6, which is a few years old. Is it an unmodified version > built from the source from openssh.com, and does the current release > (7.4) do the same thing? > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From adam at continusec.com Thu Feb 2 09:08:16 2017 From: adam at continusec.com (Adam Eijdenberg) Date: Thu, 2 Feb 2017 09:08:16 +1100 Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: References: Message-ID: On Thu, Feb 2, 2017 at 1:16 AM, Peter Moody wrote: > why not add the certificate to the running ssh-agent with a timeout > that expires when the cert does? That's an excellent idea. I've modified our tooling to do exactly that (https://github.com/continusec/geecert/commit/dfeee14b278e28d15bf532bb6e6e8ffe530e6b11). Thank you for the suggestion. > I don't think ssh-agent exposes a "how long until this key expires" > api, but you can at least use this method to see if the cert/key are > *on* the agent and you can assume that if they're on the agent, then > they're valid. I guess a case could be made for ssh-add to always set a timeout when adding a certificate with an expiry time, but I think for now I'm happy enough to do that on our end. From djm at mindrot.org Thu Feb 2 10:42:03 2017 From: djm at mindrot.org (Damien Miller) Date: Thu, 2 Feb 2017 10:42:03 +1100 (AEDT) Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: References: Message-ID: On Thu, 2 Feb 2017, Adam Eijdenberg wrote: > > I don't think ssh-agent exposes a "how long until this key expires" > > api, but you can at least use this method to see if the cert/key are > > *on* the agent and you can assume that if they're on the agent, then > > they're valid. > > I guess a case could be made for ssh-add to always set a timeout when > adding a certificate with an expiry time, but I think for now I'm > happy enough to do that on our end. That sounds like a fine idea. -d From adam at continusec.com Thu Feb 2 11:08:36 2017 From: adam at continusec.com (Adam Eijdenberg) Date: Thu, 2 Feb 2017 11:08:36 +1100 Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: References: Message-ID: On Thu, Feb 2, 2017 at 10:42 AM Damien Miller wrote: > On Thu, 2 Feb 2017, Adam Eijdenberg wrote: > > I guess a case could be made for ssh-add to always set a timeout when > > adding a certificate with an expiry time, but I think for now I'm > > happy enough to do that on our end. > > That sounds like a fine idea. Damien, to clarify did you mean it would be a fine idea to submit a patch to ssh-add to do so? (or a fine idea to leave it it alone and handle externally) From djm at mindrot.org Thu Feb 2 14:48:11 2017 From: djm at mindrot.org (Damien Miller) Date: Thu, 2 Feb 2017 14:48:11 +1100 (AEDT) Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: References: Message-ID: On Thu, 2 Feb 2017, Adam Eijdenberg wrote: > On Thu, Feb 2, 2017 at 10:42 AM Damien Miller wrote: > > On Thu, 2 Feb 2017, Adam Eijdenberg wrote: > > > I guess a case could be made for ssh-add to always set a timeout when > > > adding a certificate with an expiry time, but I think for now I'm > > > happy enough to do that on our end. > > > > That sounds like a fine idea. > > Damien, to clarify did you mean it would be a fine idea to submit a > patch to ssh-add to do so? (or a fine idea to leave it it alone and > handle externally) It's a fine idea for a feature - even just filing it on bugzilla would be good. -d From rwf at loonybin.net Thu Feb 2 17:27:05 2017 From: rwf at loonybin.net (Rob Foehl) Date: Thu, 2 Feb 2017 01:27:05 -0500 (EST) Subject: CanonicalizeHostname reparsing and vendor options Message-ID: I've been trying to take advantage of CanonicalizeHostname, and run into an issue with its reparsing behavior and vendor-supplied options in system config files. If a system config contains a stanza like this: Host * GSSAPIAuthentication yes ...there's now no way to set "GSSAPIAuthentication no" in any Host sections that only match the canonicalized hostname. I've already found https://bugzilla.mindrot.org/show_bug.cgi?id=2267 and https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033098.html concerning nearly the same problem, but I've got the additional wrinkle that I can't just change the "Host *" to "Match canonical all" and be done with it. (Well, I could, but fixing every instance in every vendor config in perpetuity is fighting a losing battle...) Have I missed some other way around this? CanonicalizeHostname fixes a long-standing consistency headache, but I'm kinda stuck here. -Rob From michael at stroeder.com Thu Feb 2 20:30:50 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 2 Feb 2017 10:30:50 +0100 Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: References: Message-ID: <0a0a4390-9dc8-9967-7db6-3d9c1f282282@stroeder.com> Damien Miller wrote: > On Thu, 2 Feb 2017, Adam Eijdenberg wrote: > >> On Thu, Feb 2, 2017 at 10:42 AM Damien Miller wrote: >>> On Thu, 2 Feb 2017, Adam Eijdenberg wrote: >>>> I guess a case could be made for ssh-add to always set a timeout when >>>> adding a certificate with an expiry time, but I think for now I'm >>>> happy enough to do that on our end. >>> >>> That sounds like a fine idea. >> >> Damien, to clarify did you mean it would be a fine idea to submit a >> patch to ssh-add to do so? (or a fine idea to leave it it alone and >> handle externally) > > It's a fine idea for a feature - even just filing it on bugzilla would be > good. I'm also thinking about how to raise the security bar of SSH keys. Would it be feasible to implement a SSH key agent which automagically generates a new key pair (e.g. when triggered by ssh-add or cert is expired) and sends the public key to a SSH signing service (authenticating the user with stronger authc mechs like 2FA) which returns the short-term SSH public-key cert? This would also make it possible to automatically add the "from=" key options because the SSH client's IP address is known. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From adam at continusec.com Thu Feb 2 21:23:48 2017 From: adam at continusec.com (Adam Eijdenberg) Date: Thu, 2 Feb 2017 21:23:48 +1100 Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: References: Message-ID: On Thu, Feb 2, 2017 at 2:48 PM, Damien Miller wrote: >> > On Thu, 2 Feb 2017, Adam Eijdenberg wrote: >> > > I guess a case could be made for ssh-add to always set a timeout when >> > > adding a certificate with an expiry time, but I think for now I'm >> > > happy enough to do that on our end. > It's a fine idea for a feature - even just filing it on bugzilla would be > good. Bug filed with first cut at patch for ssh-add here: https://bugzilla.mindrot.org/show_bug.cgi?id=2675 Although after this thread and an offline chat with Peter, it became clear that for our use-case we may not actually need to write the key or certificate to disk at all*, and can just feed them straight to ssh-agent (which was very easy to do with the Golang libraries). Really appreciate all the great suggestions and support in this forum. * Modulo Windows users. Sigh. From aris at 0xbadc0de.be Thu Feb 2 21:44:55 2017 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Thu, 2 Feb 2017 11:44:55 +0100 Subject: No point compression in SSH2_MSG_KEX_ECDH_INIT In-Reply-To: References: Message-ID: <71a7ea2a-c371-2311-d0c4-21c013fc6e82@0xbadc0de.be> On 1/02/17 12:37, Damien Miller wrote: > On Tue, 31 Jan 2017, JCA wrote: > >> I have noticed that the EC public key sent in the SSH2_MSG_KEX_ECDH_INIT >> message is sent without point compression. Are there any plans to use point >> compression eventually? I imagine that, in part, you guys are not yet >> implementing it for patent reasons, right? > I'm not aware of any plans for implementing point compression and I > don't plan on adding it myself. Motivation for not including it was > as much keeping the pre-auth code as simple as possible as anything > else. When I implemented ecdsa and ecdh in libssh I couldn't even find the code relevant to point compression in OpenSSL, because it does not exist. Apparently solving a second order equation in GFp is patented. Curve25519 and ed25519 don't have that problem, because they don't need point compression. Aris From adam at continusec.com Thu Feb 2 21:49:55 2017 From: adam at continusec.com (Adam Eijdenberg) Date: Thu, 2 Feb 2017 21:49:55 +1100 Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: <0a0a4390-9dc8-9967-7db6-3d9c1f282282@stroeder.com> References: <0a0a4390-9dc8-9967-7db6-3d9c1f282282@stroeder.com> Message-ID: On Thu, Feb 2, 2017 at 8:30 PM, Michael Str?der wrote: > Would it be feasible to implement a SSH key agent which automagically generates a new key > pair (e.g. when triggered by ssh-add or cert is expired) and sends the public key to a > SSH signing service (authenticating the user with stronger authc mechs like 2FA) which > returns the short-term SSH public-key cert? This would also make it possible to > automatically add the "from=" key options because the SSH client's IP address is known. Hi Michael, That pretty much describes what we're doing with one of my customers, with SSO to Google Apps (which in turn enforces 2FA etc), and I know we aren't the only ones doing it. Once a day our users run a command: $ updatecerts Please click the "Allow" button in your browser to authorize our SSO tool. 2017/02/02 21:34:44 Authorization code received. 2017/02/02 21:34:44 Exchanging authorization code for long-lived credentials. 2017/02/02 21:34:45 Received long-lived credentials. 2017/02/02 21:34:46 Have valid ID token 2017/02/02 21:34:46 Generating new private key. 2017/02/02 21:34:46 Requesting fresh certificates... 2017/02/02 21:34:47 Received new certificates from server. 2017/02/02 21:34:47 Writing new private key. 2017/02/02 21:34:47 Installing new certificate. 2017/02/02 21:34:47 SSH_AUTH_SOCK detected, adding certificate to ssh-agent. 2017/02/02 21:34:47 Certificate will be added with TTL of 86400 seconds. The company I did this work for (Androgogic) were kind enough to let me open-source it, so you can find the server and client here: https://github.com/continusec/geecert I think Teleport also do something similar: http://gravitational.com/teleport/ Facebook describe similar here too: https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-with-ssh/ Cheers, Adam From michael at stroeder.com Thu Feb 2 22:01:09 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=C3=B6der?=) Date: Thu, 02 Feb 2017 12:01:09 +0100 Subject: ssh-agent check for new fresh certificate (and key)? worthwhile doing? In-Reply-To: References: <0a0a4390-9dc8-9967-7db6-3d9c1f282282@stroeder.com> Message-ID: <4fa48152fe52437cb1fac66dfb7786ae@stroeder.com> On 2017-02-02 11:49, Adam Eijdenberg wrote: > On Thu, Feb 2, 2017 at 8:30 PM, Michael Str?der > wrote: >> Would it be feasible to implement a SSH key agent which automagically >> generates a new key >> pair (e.g. when triggered by ssh-add or cert is expired) and sends the >> public key to a >> SSH signing service (authenticating the user with stronger authc mechs >> like 2FA) which >> returns the short-term SSH public-key cert? This would also make it >> possible to >> automatically add the "from=" key options because the SSH client's IP >> address is known. > > That pretty much describes what we're doing with one of my customers, > with SSO to Google Apps (which in turn enforces 2FA etc), and I know > we aren't the only ones doing it. Once a day our users run a command: > > $ updatecerts > Please click the "Allow" button in your browser to authorize our SSO > tool. > [..] > 2017/02/02 21:34:47 SSH_AUTH_SOCK detected, adding certificate to > ssh-agent. Yes, I've already glanced over your github repo. I was rather thinking about integrating the whole thing into a custom SSO SSH key agent. Hmm, one could even skip the ssh-add and integrate it into a wrapper script when invoking ssh client. Thanks for the additional links. Ciao, Michael. From deengert at gmail.com Fri Feb 3 01:29:31 2017 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 2 Feb 2017 08:29:31 -0600 Subject: Server accepts key: pkalg rsa-sha2-512 vs ssh-rsa In-Reply-To: <53cb818d-e72e-78fe-7216-c1a56ef73f6f@redhat.com> References: <53cb818d-e72e-78fe-7216-c1a56ef73f6f@redhat.com> Message-ID: The original problem is some smart cards can not sign with SHA2-512. The release notes OpenSSH_7.3p1 point to: https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-03 https://tools.ietf.org/html/draft-ssh-ext-info-00 The current drafts (expiring Feb 17, 2017 and March 5, 2017) are: https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-02 https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-01 The drafts have: rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key If some services will only negotiate rsa-sha2-512 that is not in the spirit if the drafts, that make it optional. "2.2. Use for client authentication" defines" "3. Discovery of signature algorithms supported by servers" and draft-ietf-curdle-ssh-ext-info-01 discuss how a client can negotiate rsa-sha2-256. Your situation is a perfect example of why rsa-sha2-512 should be optional, and negotiation should be implemented. It may well be negotiation is implemented but not well tested, or documented because very few people could support rsa-sha2-256 but not rsa-sha2-512. Hopefully the drafts may help you determine if OpenSSH implemented the negotiation. Have you looked at the ssh_config HostKeyAlgorithms? It looks like the last entry is ssh-rsa, but the way I read the drafts this includes all the hashs. You could try and replace with rsa-sha2-256 or place rsa-sha2-256 before ssh-rsa. On 1/30/2017 3:58 AM, Jakub Jelen wrote: > On 01/26/2017 09:01 PM, Nuno Gon?alves wrote: >> Hi, >> >> I'm doing some test with a pkcs11 token that can only sign short messages. >> >> When connecting to one server, that reports pkalg rsa-sha2-512 blen >> 151, it fails to sign the pubkey because it is 83 bytes long. (sshd: >> OpenSSH_7.3p1) >> >> A older server that reports pkalg ssh-rsa blen 151, works perfectly as >> the pubkey signature required is only 35 bytes long. (sshd: >> OpenSSH_6.7p1) >> >> I am not sure where does this pkalg fit in the process, and all my >> attempts to downgrade the algorithm have failed. Even looking at >> identity_sign_encode at sshconnect2.c, doesn't help me at all, as >> ssh-rsa is not one option. >> >> So very simply, was this deprecated completely, does the new >> implementation not allow the client to downgrade it, or is there any >> option for it? >> >> Thanks, >> Nuno > > This is part of deprecation SHA1 for signatures, which were hardcoded into the core RFCs. The different hashes were introduced in OpenSSH 7.2 [1] and are negotiated using the protocol extension. I > don't think there are configuration options to control this behavior, but the new algorithms have higher priority for new OpenSSH versions. > > [1] http://www.openssh.com/txt/release-7.2 > > Regards, > -- Douglas E. Engert From dtucker at zip.com.au Fri Feb 3 14:17:47 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 3 Feb 2017 14:17:47 +1100 Subject: OpenSSH 7.4 p1 still can't be build without patch on Solaris 10 In-Reply-To: References: <84df953b-f31f-6a15-f14d-86ca85549247@gmail.com> Message-ID: Hi. On Mon, Jan 16, 2017 at 9:03 AM, Darren Tucker wrote: > On Mon, Jan 16, 2017 at 2:34 AM, Yuri Voinov wrote: >> OpenSSH 7.4 p1 still can't be build without patch on Solaris 10 (attached). > > What does it do (or not)? We test on an x86 Solaris 10 VM an it built on that. > >> -dnl Wide character support. Linux man page says it needs _XOPEN_SOURCE. >> -saved_CFLAGS="$CFLAGS" >> -CFLAGS="$CFLAGS -D_XOPEN_SOURCE" >> +dnl Wide character support. >> AC_CHECK_FUNCS([mblen mbtowc nl_langinfo wcwidth]) >> -CFLAGS="$saved_CFLAGS" > > That will break wide character detection on Linux. It turns out I was wrong about that. Your patch has been applied and will be in the next release. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From cristian.ionescu-idbohrn at axis.com Sat Feb 4 00:37:08 2017 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 3 Feb 2017 14:37:08 +0100 (CET) Subject: compilation errors on master Message-ID: `git describe' says V_7_3_P1-207-gc924b2ef (shouldn't it say V_7_4_P1-?). This is what I see: gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE -I. -I. -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/local/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c sshkey.c -o sshkey.o sshkey.c: In function ?sshkey_size?: sshkey.c:274:28: error: dereferencing pointer to incomplete type ?RSA {aka struct rsa_st}? return BN_num_bits(k->rsa->n); ^~ sshkey.c:277:28: error: dereferencing pointer to incomplete type ?DSA {aka struct dsa_st}? return BN_num_bits(k->dsa->p); ^~ sshkey.c: In function ?sshkey_new?: sshkey.c:478:11: error: dereferencing pointer to incomplete type ?RSA {aka struct rsa_st}? (rsa->n = BN_new()) == NULL || ^~ sshkey.c:490:11: error: dereferencing pointer to incomplete type ?DSA {aka struct dsa_st}? (dsa->p = BN_new()) == NULL || ^~ sshkey.c: In function ?sshkey_parse_private_pem_fileblob?: sshkey.c:3792:8: error: dereferencing pointer to incomplete type ?EVP_PKEY {aka struct evp_pkey_st}? if (pk->type == EVP_PKEY_RSA && ^~ Cheers, -- Cristian From scott_n at xypro.com Sat Feb 4 02:53:32 2017 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 3 Feb 2017 15:53:32 +0000 Subject: compilation errors on master In-Reply-To: References: Message-ID: It looks to me like you're building against OpenSSL 1.1.0. This won't work. You need 1.0.2 or earlier. The OpenSSL guys changed the API on 1.1.0. -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Cristian Ionescu-Idbohrn Sent: Friday, February 03, 2017 5:37 AM To: openssh-unix-dev at mindrot.org Subject: compilation errors on master `git describe' says V_7_3_P1-207-gc924b2ef (shouldn't it say V_7_4_P1-?). This is what I see: gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE -I. -I. -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/local/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c sshkey.c -o sshkey.o sshkey.c: In function ?sshkey_size?: sshkey.c:274:28: error: dereferencing pointer to incomplete type ?RSA {aka struct rsa_st}? return BN_num_bits(k->rsa->n); ^~ sshkey.c:277:28: error: dereferencing pointer to incomplete type ?DSA {aka struct dsa_st}? return BN_num_bits(k->dsa->p); ^~ sshkey.c: In function ?sshkey_new?: sshkey.c:478:11: error: dereferencing pointer to incomplete type ?RSA {aka struct rsa_st}? (rsa->n = BN_new()) == NULL || ^~ sshkey.c:490:11: error: dereferencing pointer to incomplete type ?DSA {aka struct dsa_st}? (dsa->p = BN_new()) == NULL || ^~ sshkey.c: In function ?sshkey_parse_private_pem_fileblob?: sshkey.c:3792:8: error: dereferencing pointer to incomplete type ?EVP_PKEY {aka struct evp_pkey_st}? if (pk->type == EVP_PKEY_RSA && ^~ Cheers, -- Cristian _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From cristian.ionescu-idbohrn at axis.com Sat Feb 4 04:56:41 2017 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Fri, 3 Feb 2017 18:56:41 +0100 (CET) Subject: compilation errors on master In-Reply-To: References: Message-ID: On Fri, 3 Feb 2017, Scott Neugroschl wrote: > > It looks to me like you're building against OpenSSL 1.1.0. This > won't work. You need 1.0.2 or earlier. The OpenSSL guys changed > the API on 1.1.0. Yes, when I look closer :) checking OpenSSL header version... 1010003f (OpenSSL 1.1.0c 10 Nov 2016) checking OpenSSL library version... 1010003f (OpenSSL 1.1.0c 10 Nov 2016) I guess I was expecting ./configure to err out or at least warn about that and/or "OpenSSH has been configured with the following options:" would display the openssl version. That would help. I see there's a guard for lowest possible version, but not the higest. This is a debian box. I see: libssl1.0.0:amd64 libssl1.0.2:amd64 libssl1.1:amd64 installed. How does one go about to tell ./configure what to choose? I looked through, but couldn't find info on a clean way to do that :( Cheers, -- Cristian From stefbon at gmail.com Sat Feb 4 23:06:07 2017 From: stefbon at gmail.com (Stef Bon) Date: Sat, 4 Feb 2017 13:06:07 +0100 Subject: Greeter openssh 7.4 is not according rfc4253. Message-ID: Hi, I discovered when using my fuse fs for connecting to a remote host using sftp that the new server version 7.4 sends a greeter which is not according the format desribed in https://tools.ietf.org/html/rfc4253#section-4 There is written that the greeter "MUST be terminated by a single Carriage Return (CR) and a single Line Feed (LF) character (ASCII 13 and 10, respectively)." Now the greeter send by openssh 7.4 looks like: 00000000 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 48 5f |SSH-2.0-OpenSSH_| 00000010 37 2e 34 0a |7.4.| 00000014 As you can see the greeter is terminated by "0a", which is a linefeed. The carriage return is not there. Stef Bon From schwarze at usta.de Sun Feb 5 03:36:23 2017 From: schwarze at usta.de (Ingo Schwarze) Date: Sat, 4 Feb 2017 17:36:23 +0100 Subject: How to track vulnerability fixes In-Reply-To: References: Message-ID: <20170204163623.GC12010@athene.usta.de> Hi, since nobody else answered: Sandeep Umesh wrote on Tue, Jan 31, 2017 at 11:44:31AM +0530: > We have 5 security related fixes, however CVE # has been assigned > to only 2 of them (CVE-2016-6210 and CVE-2015-8325). Does that > mean the other 3 are non security related fixes ? No. If it's marked as a security fix on the errata page, for example http://www.openbsd.org/errata60.html , or if it's listed on https://www.openssh.com/security.html , then it's a security fix. > When does a security fix qualify to be a assigned a CVE # ? Never. OpenBSD doesn't use the CVE process at all. A CVE number has no meaning whatsoever. If a CVE number is assigned to an OpenBSD or OpenSSH bug, then that usually means that some third party requested it. Sometimes that happens, but usually it doesn't. OpenBSD developers mostly ignore the CVE process even in cases where some third party bothers to request a CVE number. If a CVE number was assigned, it is often listed, but not even that is guaranteed. And even if a CVE number is assigned, that doesn't imply that it's security related. Just as there are important vulnerabilities without CVEs, there are CVEs that have no security implications. Do not report (suspected or confirmed) OpenSSH security issues to any third party, not even to MITRE. Please report them to , or if they are not security related, to this list or to https://bugzilla.mindrot.org/ . Yours, Ingo From cristian.ionescu-idbohrn at axis.com Sun Feb 5 06:24:41 2017 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sat, 4 Feb 2017 20:24:41 +0100 (CET) Subject: compilation errors on master In-Reply-To: References: Message-ID: On Fri, 3 Feb 2017, Cristian Ionescu-Idbohrn wrote: > On Fri, 3 Feb 2017, Scott Neugroschl wrote: > > > > It looks to me like you're building against OpenSSL 1.1.0. This > > won't work. You need 1.0.2 or earlier. The OpenSSL guys changed > > the API on 1.1.0. > > Yes, when I look closer :) > > checking OpenSSL header version... 1010003f (OpenSSL 1.1.0c 10 Nov 2016) > checking OpenSSL library version... 1010003f (OpenSSL 1.1.0c 10 Nov 2016) > > I guess I was expecting ./configure to err out or at least warn about > that and/or "OpenSSH has been configured with the following options:" > would display the openssl version. That would help. > > I see there's a guard for lowest possible version, but not the higest. Yes. Isn't there a way to detect OpenSSL version >= 1010003f? I see there's already code in configure.ac that does this: #if OPENSSL_VERSION_NUMBER < 0x0090807f /* 0.9.8g */ > This is a debian box. I see: > > libssl1.0.0:amd64 > libssl1.0.2:amd64 > libssl1.1:amd64 > > installed. How does one go about to tell ./configure what to choose? > I looked through, but couldn't find info on a clean way to do that :( Answering to myself. Yes, there's a way. Install package: libssl1.0-dev That will (if installed) remove package libssl-dev which points to openssl >= 1.1.0. Cheers, -- Cristian From lists at manon.de Mon Feb 6 02:03:20 2017 From: lists at manon.de (Manon Goo) Date: Sun, 05 Feb 2017 16:03:20 +0100 Subject: certificates keys on pkcs11 devices In-Reply-To: <731FFBFF46A3EBEFA2CF8976@dynhost-116-17.cgnhome.manon.de> References: <731FFBFF46A3EBEFA2CF8976@dynhost-116-17.cgnhome.manon.de> Message-ID: Hi, I created a patch that allows to add ssh User Certificates to ssh-agent independent from the key. This is useful when the private key is stored on a pkcs11 device. the patch adds an option "-C [cert_file]" to ssh-add. The patch adds function to ssh-add to check if a an keypair exists in ssh-agent. If a keypair corresponds to the public key of cert_file the certificate is added to the ssh-agent. If called with -d -C "[cert_file]" the certificate is removed. I added a "-v" Option to print debug messages. usage: ssh-add -s /usr/local/lib/opensc-pkcs11.so -C ~/.ssh/mysmartcard-cert.pub ssh-add -d -C ~/.ssh/mysmartcard-cert.pub ssh-add -C ~/.ssh/mysmartcard-other-cert.pub ssh-add -d -C mysmartcard-other-cert.pub I hope this function makes sense to you. Best wihses, Manon --On 28 December 2016 at 03:51:44 +0100 Manon Goo wrote: > Hi, > > I have not found any way to use a Certificate with ssh-agent when my Key > is stored on a pkcs11 device. I can add my key with > > ssh-add -s /usr/local/lib/opensc-pkcs11.so > > but > > ssh-add -s /usr/local/lib/opensc-pkcs11.so ~/.ssh/mykey-cert.pub > > does not add the certificate to my agent. As far as I undestand, in > ssh-add.c line 580 > > if (pkcs11provider != NULL) { > if (update_card(agent_fd, !deleting, pkcs11provider) == -1) > ret = 1; > goto done; > } > > does not check for additional (certifcate)-files files on the command > line and update_card neither does. > > Is there any intention to change this? > > Thanks in alot, > Manon > > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Manon Goo Dembach Goo Informatik GmbH & Co. KG Hohenzollernring 72 D-50672 K?ln Tel.: +49 221 12095-211 Mobil: +49 151 12222781 Fax: +49 221 12095-220 E-Mail:manon.goo at dg-i.net Support-Hotline: 0800 / 100 4323 Amtsgericht K?ln HRA 22794, USt-IdNr.: DE242 159 527 Haftende Gesellschafterin: Dembach Goo Verwaltungsgesellschaft mbH Deren Gesch?ftsf?hrer: Andreas Dembach, Manon Goo From lists at manon.de Mon Feb 6 02:10:41 2017 From: lists at manon.de (Manon Goo) Date: Sun, 05 Feb 2017 16:10:41 +0100 Subject: certificates keys on pkcs11 devices In-Reply-To: References: <731FFBFF46A3EBEFA2CF8976@dynhost-116-17.cgnhome.manon.de> Message-ID: patch against tags/V_7_4_P1: --- ssh-add.c.old 2017-02-04 00:03:34.000000000 +0100 +++ ssh-add.c 2017-02-05 15:26:40.000000000 +0100 @@ -58,6 +58,7 @@ #include "rsa.h" #include "log.h" #include "sshkey.h" +#include "crypto_api.h" #include "sshbuf.h" #include "authfd.h" #include "authfile.h" @@ -65,6 +66,7 @@ #include "misc.h" #include "ssherr.h" #include "digest.h" +#include "readconf.h" /* argv0 */ extern char *__progname; @@ -93,6 +95,17 @@ /* User has to confirm key use */ static int confirm = 0; +/* Flag indicating whether debug mode is on. May be set on the command line. */ +int debug_flag = 1; +int log_level = SYSLOG_LEVEL_INFO; + + +/* + * General data structure for command line options and options configurable + * in configuration files. See readconf.h. + */ +Options options; + /* we keep a cache of one passphrase */ static char *pass = NULL; static void @@ -331,6 +344,154 @@ } static int +add_cert(int agent_fd, const char *filename) +{ + struct sshkey *cert; + // struct sshkey *mypubkey; + char *comment = NULL; + char *certpath = NULL; + int r, ret = -1; + // struct sshbuf *keyblob; + int had_identities = 0; + struct ssh_identitylist *idlist; + size_t i; + int version = 2; + // u_char *tmp_ed25519_sk = malloc(ED25519_SK_SZ); + + xasprintf(&certpath, "%s", filename); + if ((r = sshkey_load_public(certpath, &cert, NULL)) != 0) { + fatal("Failed to load certificate \"%s\": %s", + certpath, ssh_err(r)); + } + debug2("loaded certificate %s", filename); + + if ((r = ssh_fetch_identitylist(agent_fd, version, + &idlist)) != 0) { + if (r != SSH_ERR_AGENT_NO_IDENTITIES) + fprintf(stderr, "error fetching identities for " + "protocol %d: %s\n", version, ssh_err(r)); + } + + for (i = 0; i < idlist->nkeys; i++) { + had_identities = 1; + debug3("\n\nLooping through identitys in agent, iteration: %zd", i); + debug("Processing id \"%s\"", idlist->comments[i]); + if (log_level >= SYSLOG_LEVEL_DEBUG3){ + fprintf(stderr, "Matching identity "); + if ((r = sshkey_write(idlist->keys[i], + stderr)) != 0) { + fprintf(stderr, "sshkey_write: %s\n", + ssh_err(r)); + + continue; + } + fprintf(stderr, "\n"); + } + if (log_level >= SYSLOG_LEVEL_DEBUG3){ + fprintf(stderr, "Against certificate "); + if ((r = sshkey_write(cert, stderr)) != 0) { + fprintf(stderr, "sshkey_write of cert: %s\n", + ssh_err(r)); + } + fprintf(stderr, "\n"); + } + + debug2("Type of cert: %s \t\t\t\t Type of identity from agent: %s", sshkey_type(cert), sshkey_type(idlist->keys[i]) ); + + if (sshkey_equal_public(cert, idlist->keys[i]) ) { + debug2("Certificate matches identity from agent"); + + + /* Graft Certificagte with private bits */ + switch (cert->type) { + case KEY_RSA_CERT : + /* initialize cert->rsa->iqmp,d,p,q */ + debug2("RSA-CERT"); + sshkey_add_private(cert); + break; + + case KEY_ED25519_CERT : + debug2("ED25519-CERT"); + cert->ed25519_sk = malloc(ED25519_SK_SZ); + break; + case KEY_ECDSA_CERT: + debug2("ECDSA-CERT"); + /* sshkey_add_private(cert); */ + /* don'tr know abouzt any smartcards doing ECDSA */ + fatal("ECDSA-CERT is not yet implemented"); + break; + case KEY_DSA_CERT: + debug2("DSA-CERT"); + sshkey_add_private(cert); + break; + } + + + if ((r = ssh_add_identity_constrained(agent_fd, cert, NULL, + lifetime, confirm)) != 0) { + error("Certificate %s (%s) add failed: %s", certpath, + cert->cert->key_id, ssh_err(r)); + goto out; + } + fprintf(stderr, "Certificate added: %s (%s)\n", certpath, + cert->cert->key_id); + ret = 0; + if (lifetime != 0) + fprintf(stderr, "Lifetime set to %d seconds\n", lifetime); + if (confirm != 0) + fprintf(stderr, "The user must confirm each use of the key\n"); + /* Skip proceeing other entries*/ + goto out; + } else { + debug("Certificate does not match key in agent"); + } + + } + fprintf(stderr, "Certificate does not match any identity from ssh-agent, concider usimng the CertificateFile option\n"); + + out: + free(certpath); + free(comment); + sshkey_free(cert); + ssh_free_identitylist(idlist); + return ret; +} + +static int +delete_cert(int agent_fd, const char *filename) +{ + struct sshkey *cert; + char *comment = NULL; + char *certpath = NULL; + int r, ret = -1; + + + xasprintf(&certpath, "%s", filename); + if ((r = sshkey_load_public(certpath, &cert, &comment)) != 0) { + if (r != SSH_ERR_SYSTEM_ERROR || errno != ENOENT) + fatal("Failed to load certificate \"%s\": %s", + certpath, ssh_err(r)); + } + debug2("loaded certificate %s", filename); + + /* initialize cert->rsa->iqmp,d,p,q with 0 */ + /* sshkey_add_private(cert); */ + + if ((r = ssh_remove_identity(agent_fd, cert)) == 0) { + fprintf(stderr, "Identity removed: %s (%s)\n", certpath, + comment); + ret = 0; + } else + fprintf(stderr, "Could not remove identity \"%s\": %s\n", + certpath, ssh_err(r)); + + sshkey_free(cert); + free(certpath); + free(comment); + return ret; +} + +static int update_card(int agent_fd, int add, const char *id) { char *pin = NULL; @@ -439,6 +600,21 @@ return (ret); } +/* Process "-C" */ +static int +do_cert(int agent_fd, int deleting, char *file) +{ + debug2("do_cert: %s", file ); + if (deleting) { + if (delete_cert(agent_fd, file) == -1) + return -1; + } else { + if (add_cert(agent_fd, file) == -1) + return -1; + } + return 0; +} + static int do_file(int agent_fd, int deleting, int key_only, char *file) { @@ -461,12 +637,14 @@ fprintf(stderr, " -E hash Specify hash algorithm used for fingerprints.\n"); fprintf(stderr, " -L List public key parameters of all identities.\n"); fprintf(stderr, " -k Load only keys and not certificates.\n"); + fprintf(stderr, " -C file Use the following certificate\n"); fprintf(stderr, " -c Require confirmation to sign using identities\n"); fprintf(stderr, " -t life Set lifetime (in seconds) when adding identities.\n"); fprintf(stderr, " -d Delete identity.\n"); fprintf(stderr, " -D Delete all identities.\n"); fprintf(stderr, " -x Lock agent.\n"); fprintf(stderr, " -X Unlock agent.\n"); + fprintf(stderr, " -v Verbose.\n"); fprintf(stderr, " -s pkcs11 Add keys from PKCS#11 provider.\n"); fprintf(stderr, " -e pkcs11 Remove keys provided by PKCS#11 provider.\n"); } @@ -478,6 +656,7 @@ extern int optind; int agent_fd; char *pkcs11provider = NULL; + char *certificateFile = NULL; int r, i, ch, deleting = 0, ret = 0, key_only = 0; int xflag = 0, lflag = 0, Dflag = 0; @@ -494,6 +673,12 @@ setvbuf(stdout, NULL, _IOLBF, 0); + /* + * Initialize "log" output. Since we are the client all output + * goes to stderr + */ + log_init(argv[0], SYSLOG_LEVEL_INFO, SYSLOG_FACILITY_USER, 1); + /* First, get a connection to the authentication agent. */ switch (r = ssh_get_authentication_socket(&agent_fd)) { case 0: @@ -507,7 +692,7 @@ exit(2); } - while ((ch = getopt(argc, argv, "klLcdDxXE:e:s:t:")) != -1) { + while ((ch = getopt(argc, argv, "klLcdDvxXC:E:e:s:t:")) != -1) { switch (ch) { case 'E': fingerprint_hash = ssh_digest_alg_by_name(optarg); @@ -532,6 +717,9 @@ case 'c': confirm = 1; break; + case 'C': + certificateFile = optarg; + break; case 'd': deleting = 1; break; @@ -552,13 +740,22 @@ goto done; } break; + case 'v': + if (log_level == SYSLOG_LEVEL_INFO) + log_level = SYSLOG_LEVEL_DEBUG1; + else { + if (log_level >= SYSLOG_LEVEL_DEBUG1 && + log_level < SYSLOG_LEVEL_DEBUG3) + log_level++; + } + break; default: usage(); ret = 1; goto done; } } - + if ((xflag != 0) + (lflag != 0) + (Dflag != 0) > 1) fatal("Invalid combination of actions"); else if (xflag) { @@ -575,12 +772,16 @@ goto done; } + /* reinit */ + log_init(argv[0], log_level, SYSLOG_FACILITY_USER, 1); + debug2("log level is: %s", log_level_name(log_level)); + argc -= optind; argv += optind; if (pkcs11provider != NULL) { if (update_card(agent_fd, !deleting, pkcs11provider) == -1) ret = 1; - goto done; + goto addcert; } if (argc == 0) { char buf[PATH_MAX]; @@ -615,6 +816,17 @@ } } clear_pass(); + +addcert: + /* process certificate passedc by -C [file] */ + if (certificateFile != NULL) { + debug("using certificate from file: %s", certificateFile); + if (do_cert(agent_fd, deleting, certificateFile) == -1) { + ret = 1; + goto done; + } + ret = 0; + } done: ssh_close_authentication_socket(agent_fd); --On 5 February 2017 at 16:03:20 +0100 Manon Goo wrote: > Hi, > > I created a patch that allows to add ssh User Certificates to ssh-agent > independent from the key. > This is useful when the private key is stored on a pkcs11 device. > > the patch adds an option "-C [cert_file]" to ssh-add. The patch adds > function to ssh-add to check if a an keypair exists in ssh-agent. If a > keypair corresponds to the public key of cert_file the certificate is > added to the ssh-agent. > If called with -d -C "[cert_file]" the certificate is removed. > I added a "-v" Option to print debug messages. > > usage: > > ssh-add -s /usr/local/lib/opensc-pkcs11.so -C ~/.ssh/mysmartcard-cert.pub > > ssh-add -d -C ~/.ssh/mysmartcard-cert.pub > > ssh-add -C ~/.ssh/mysmartcard-other-cert.pub > > ssh-add -d -C mysmartcard-other-cert.pub > > I hope this function makes sense to you. > > Best wihses, > Manon > > > > --On 28 December 2016 at 03:51:44 +0100 Manon Goo wrote: > >> Hi, >> >> I have not found any way to use a Certificate with ssh-agent when my Key >> is stored on a pkcs11 device. I can add my key with >> >> ssh-add -s /usr/local/lib/opensc-pkcs11.so >> >> but >> >> ssh-add -s /usr/local/lib/opensc-pkcs11.so ~/.ssh/mykey-cert.pub >> >> does not add the certificate to my agent. As far as I undestand, in >> ssh-add.c line 580 >> >> if (pkcs11provider != NULL) { >> if (update_card(agent_fd, !deleting, pkcs11provider) == -1) >> ret = 1; >> goto done; >> } >> >> does not check for additional (certifcate)-files files on the command >> line and update_card neither does. >> >> Is there any intention to change this? >> >> Thanks in alot, >> Manon >> >> >> >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > Manon Goo > Dembach Goo Informatik GmbH & Co. KG > Hohenzollernring 72 > D-50672 K?ln > > Tel.: +49 221 12095-211 > Mobil: +49 151 12222781 > Fax: +49 221 12095-220 > E-Mail:manon.goo at dg-i.net > > Support-Hotline: 0800 / 100 4323 > > Amtsgericht K?ln HRA 22794, USt-IdNr.: DE242 159 527 > Haftende Gesellschafterin: Dembach Goo Verwaltungsgesellschaft mbH > Deren Gesch?ftsf?hrer: Andreas Dembach, Manon Goo > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Manon Goo Dembach Goo Informatik GmbH & Co. KG Hohenzollernring 72 D-50672 K?ln Tel.: +49 221 12095-211 Mobil: +49 151 12222781 Fax: +49 221 12095-220 E-Mail:manon.goo at dg-i.net Support-Hotline: 0800 / 100 4323 Amtsgericht K?ln HRA 22794, USt-IdNr.: DE242 159 527 Haftende Gesellschafterin: Dembach Goo Verwaltungsgesellschaft mbH Deren Gesch?ftsf?hrer: Andreas Dembach, Manon Goo From stefbon at gmail.com Mon Feb 6 05:57:31 2017 From: stefbon at gmail.com (Stef Bon) Date: Sun, 5 Feb 2017 19:57:31 +0100 Subject: Greeter openssh 7.4 is not according rfc4253. In-Reply-To: References: Message-ID: 2017-02-04 13:06 GMT+01:00 Stef Bon : > Hi, > > I discovered when using my fuse fs for connecting to a remote host > using sftp that the new > > As you can see the greeter is terminated by "0a", which is a linefeed. > The carriage return is not there. > Hmm, this is remarkable. Following RFC's strictly is one of the rules when developing software. This bug is reproducable always. Nobody interested? Stef From phil.pennock at globnix.org Mon Feb 6 06:12:45 2017 From: phil.pennock at globnix.org (Phil Pennock) Date: Sun, 5 Feb 2017 19:12:45 +0000 Subject: Greeter openssh 7.4 is not according rfc4253. In-Reply-To: References: Message-ID: <20170205191244.GA81980@tower.spodhuis.org> On 2017-02-05 at 19:57 +0100, Stef Bon wrote: > Hmm, this is remarkable. Following RFC's strictly is one of the rules > when developing software. Without taking a stance on this particular issue reported against OpenSSH: No, following RFCs is a good default stance, unless and until you have a good reason to do otherwise. RFCs are not laws and they're not flawless. Sometimes it's right to break them. I'm one of the maintainers of Exim. That software handles a lot of mail. Sometimes we provide options to ignore RFC limits or act against them. Sometimes we make the default be explicitly against RFC and provide an option for folks to be compliant if they really want. Good engineering involves analysis of consequences and making judgement calls, not just doing whatever someone else managed to get written down. > Nobody interested? It's the weekend. You mailed on a Saturday and are chasing on a Sunday, disappointed that nobody has jumped on it already? Wait a couple more days before making such conclusions, let the OpenSSH maintainers have a chance to (1) enjoy their weekends, stress-free; (2) get around to it sometime in the week. If you want 24x7 support, you generally need to _pay_ for it. -Phil From mstone at mathom.us Mon Feb 6 09:12:30 2017 From: mstone at mathom.us (Michael Stone) Date: Sun, 5 Feb 2017 17:12:30 -0500 Subject: Greeter openssh 7.4 is not according rfc4253. In-Reply-To: References: Message-ID: On Sat, Feb 04, 2017 at 01:06:07PM +0100, Stef Bon wrote: >I discovered when using my fuse fs for connecting to a remote host >using sftp that the new >server version 7.4 sends a greeter which is not according the format desribed in > >https://tools.ietf.org/html/rfc4253#section-4 > >There is written that the greeter "MUST be terminated by a single >Carriage Return (CR) and a single Line Feed (LF) character (ASCII 13 >and 10, respectively)." > >Now the greeter send by openssh 7.4 looks like: > >00000000 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 48 5f |SSH-2.0-OpenSSH_| >00000010 37 2e 34 0a > |7.4.| >00000014 > >As you can see the greeter is terminated by "0a", which is a linefeed. >The carriage return is not there. It was probably because of this commit: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.472&r2=1.473 Which removed support for protocols older than 2 but perhaps failed to account for the fact that newline had been redefined when using protocol 2. But as someone else said, give it a few days for a response. Mike Stone From ag4ve.us at gmail.com Mon Feb 6 15:54:28 2017 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 5 Feb 2017 23:54:28 -0500 Subject: Smart card identityfile In-Reply-To: References: Message-ID: Not sure if it's just my Googlefu but... What's the syntax to add a smart card or other file in ssh-agent that isn't local to an identifyfile line? From sudarshan12s at gmail.com Mon Feb 6 18:44:52 2017 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Mon, 6 Feb 2017 13:14:52 +0530 Subject: ^C doesnt work on ssh session In-Reply-To: References: <587D2053.7090605@eviladmin.org> Message-ID: Hi Darren, I am sending openssh (unchanged ) version, can you please comment, if it has anything to do with linked libraries , libssl, libcrypto ? any hint/suggestion, please let us know :/root #/usr/bin/sshd -ddd -p 2024 -f /home//cliuser/sshd_config debug2: load_server_config: filename /home//cliuser/sshd_config debug2: load_server_config: done config len = 684 debug2: parse_server_config: config /home//cliuser/sshd_config len 684 debug3: /home//cliuser/sshd_config:2 setting Port 22 debug3: /home//cliuser/sshd_config:3 setting Protocol 2 debug3: /home//cliuser/sshd_config:4 setting HostKey /etc/ssh/ssh_host_key debug3: /home//cliuser/sshd_config:5 setting HostKey /etc/ssh/ssh_host_rsa_key debug3: /home//cliuser/sshd_config:6 setting MACs hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com debug3: macs ok: [hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com] debug3: /home//cliuser/sshd_config:7 setting Ciphers aes128-ctr,aes192-ctr,aes256-ctr debug3: ciphers ok: [aes128-ctr,aes192-ctr,aes256-ctr] debug3: /home//cliuser/sshd_config:8 setting AllowUsers cliuser acli xml sneaccess root debug3: /home//cliuser/sshd_config:10 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /home//cliuser/sshd_config:11 setting PermitEmptyPasswords yes debug3: /home//cliuser/sshd_config:12 setting PasswordAuthentication yes debug3: /home//cliuser/sshd_config:13 setting ChallengeResponseAuthentication no debug3: /home//cliuser/sshd_config:14 setting AllowAgentForwarding no debug3: /home//cliuser/sshd_config:15 setting GatewayPorts no debug3: /home//cliuser/sshd_config:16 setting X11Forwarding no debug3: /home//cliuser/sshd_config:17 setting TCPKeepAlive yes debug3: /home//cliuser/sshd_config:18 setting PidFile /tmp/sshd.pid debug3: /home//cliuser/sshd_config:19 setting UsePrivilegeSeparation no debug3: /home//cliuser/sshd_config:20 setting ClientAliveInterval 15 debug3: /home//cliuser/sshd_config:21 setting ClientAliveCountMax 3 debug3: /home//cliuser/sshd_config:22 setting MaxStartups 25 debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1h 5 Jun 2014 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 "/etc/ssh_key" as a RSA1 public key debug1: private host key: #0 type 1 RSA debug1: could not open key file '/etc/ssh/ssh_host_key': No such file or directory Could not load host key: /etc/ssh/ssh_host_key debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': No such file or directory Could not load host key: /etc/ssh/ssh_host_rsa_key debug1: rexec_argv[0]='/usr/bin/sshd' debug1: rexec_argv[1]='-ddd' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2024' debug1: rexec_argv[4]='-f' debug1: rexec_argv[5]='/home//cliuser/sshd_config' debug1: rexec_argv[6]='-h' debug1: rexec_argv[7]='/etc/ssh_key' debug3: oom_adjust_setup Set /proc/self/oom_score_adj from 0 to -1000 debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2024 on 0.0.0.0. Server listening on 0.0.0.0 port 2024. debug2: fd 4 setting O_NONBLOCK debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Bind to port 2024 on ::. Server listening on :: port 2024. debug3: fd 5 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 684 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 10.220.82.17 port 55099 on 10.100.212.166 port 2024 debug1: Client protocol version 2.0; client software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6 debug2: fd 3 setting O_NONBLOCK debug1: list_hostkey_types: ssh-rsa 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-rsa debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-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,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-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: mac_setup: setup hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none debug2: mac_setup: setup hmac-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received WARNING: /usr/local/etc/moduli does not exist, using fixed modulus debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: bits set: 991/2048 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: bits set: 1045/2048 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: Trying to reverse map address 10.220.82.17. debug2: parse_server_config: config reprocess config len 684 debug3: auth_shadow_acctexpired: today 17203 sp_expire -1 days left -17204 debug3: account expiration disabled debug2: input_userauth_request: setting up authctxt for root debug2: input_userauth_request: try method none debug3: auth_shadow_pwexpired: today 17203 sp_lstchg 17177 sp_max 99999 Failed none for root from 10.220.82.17 port 55099 ssh2 debug3: userauth_finish: failure partial=0 next methods="publickey,password" debug1: userauth-request for user root service ssh-connection method password debug1: attempt 1 failures 0 debug2: input_userauth_request: try method password Accepted password for root from 10.220.82.17 port 55099 ssh2 debug1: Entering interactive session for SSH2. debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/1 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 shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell Starting session: shell on pts/1 for root from 10.220.82.17 port 55099 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: channel 0: rfd 8 isatty debug2: fd 8 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug2: channel 0: request keepalive at openssh.com confirm 1 debug1: Got 100/21 for keepalive debug2: channel 0: request keepalive at openssh.com confirm 1 debug1: Got 100/22 for keepalive debug2: channel 0: request keepalive at openssh.com confirm 1 debug1: Got 100/23 for keepalive ^CExiting on signal 2 debug1: do_cleanup debug1: session_pty_cleanup: session 0 release /dev/pts/1 :/root # client logs: ssh -vvv root at 10.100.212.166 -p 2024 OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.100.212.166 [10.100.212.166] port 2024. debug1: Connection established. debug1: identity file /home/ssoma/.ssh/identity type -1 debug1: identity file /home/ssoma/.ssh/identity-cert type -1 debug1: identity file /home/ssoma/.ssh/id_rsa type -1 debug1: identity file /home/ssoma/.ssh/id_rsa-cert type -1 debug1: identity file /home/ssoma/.ssh/id_dsa type -1 debug1: identity file /home/ssoma/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6 debug1: match: OpenSSH_6.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug3: Wrote 960 bytes for a total of 981 debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-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,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-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 ,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-rsa debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com 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-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug2: mac_setup: found hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug3: Wrote 24 bytes for a total of 1005 debug2: dh_gen_key: priv key bits set: 165/320 debug2: bits set: 1045/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: Wrote 272 bytes for a total of 1277 debug3: put_host_port: [10.100.212.166]:2024 debug3: put_host_port: [10.100.212.166]:2024 debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename /etc/ssh/ssh_known_hosts debug1: checking without port identifier debug3: check_host_in_hostfile: host 10.100.212.166 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host 10.100.212.166 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: match line 135 debug1: Host '10.100.212.166' is known and matches the RSA host key. debug1: Found key in /home/ssoma/.ssh/known_hosts:135 debug1: found matching key w/out port debug2: bits set: 991/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: Wrote 16 bytes for a total of 1293 debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug3: Wrote 52 bytes for a total of 1345 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/ssoma/.ssh/identity ((nil)) debug2: key: /home/ssoma/.ssh/id_rsa ((nil)) debug2: key: /home/ssoma/.ssh/id_dsa ((nil)) debug3: Wrote 68 bytes for a total of 1413 debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,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/ssoma/.ssh/identity debug3: no such identity: /home/ssoma/.ssh/identity debug1: Trying private key: /home/ssoma/.ssh/id_rsa debug3: no such identity: /home/ssoma/.ssh/id_rsa debug1: Trying private key: /home/ssoma/.ssh/id_dsa debug3: no such identity: /home/ssoma/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password root at 10.100.212.166's password: debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64) debug2: we sent a password packet, wait for reply debug3: Wrote 148 bytes for a total of 1561 debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug3: Wrote 136 bytes for a total of 1697 debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env CCACHE_NOSTATS debug3: Ignored env HOSTNAME debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env HISTSIZE debug3: Ignored env SSH_CLIENT debug3: Ignored env CCACHE_LOGFILE debug3: Ignored env QTDIR debug3: Ignored env OLDPWD debug3: Ignored env QTINC debug3: Ignored env SSH_TTY debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env CSCOPE_EDITOR debug3: Ignored env COVLM debug3: Ignored env MAIL debug3: Ignored env PATH debug3: Ignored env PWD debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env MODULEPATH debug3: Ignored env LOADEDMODULES debug3: Ignored env P4CLIENT debug3: Ignored env SSH_ASKPASS debug3: Ignored env HISTCONTROL debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env QTLIB debug3: Ignored env CVS_RSH debug3: Ignored env SSH_CONNECTION debug3: Ignored env MODULESHOME debug3: Ignored env LESSOPEN debug3: Ignored env P4PORT debug3: Ignored env G_BROKEN_FILENAMES debug3: Ignored env BASH_FUNC_module() debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: Wrote 460 bytes for a total of 2157 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Mon Feb 6 06:46:17 2017 from 10.220.82.17 debug1: permanently_set_uid: 0/0 Environment: USER=root LOGNAME=root HOME=/root PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin MAIL=/var/mail/root SHELL=/bin/bash TZ=UTC SSH_CLIENT=10.220.82.17 55099 2024 SSH_CONNECTION=10.220.82.17 55099 10.100.212.166 2024 SSH_TTY=/dev/pts/1 TERM=xterm -bash: no job control in this shell file setup_env.sh found... CX1200F-166:1-1*:/root # debug3: Wrote 52 bytes for a total of 2209 debug3: Wrote 52 bytes for a total of 2261 debug3: Wrote 52 bytes for a total of 2313 sd debug3: Wrote 52 bytes for a total of 2365 debug3: Wrote 52 bytes for a total of 2417 debug3: Wrote 52 bytes for a total of 2469 debug3: Wrote 52 bytes for a total of 2521 sdebug3: Wrote 52 bytes for a total of 2573 debug3: Wrote 52 bytes for a total of 2625 debug1: client_input_channel_req: channel 0 rtype keepalive at openssh.com reply 1 debug3: Wrote 36 bytes for a total of 2661 debug1: client_input_channel_req: channel 0 rtype keepalive at openssh.com reply 1 debug3: Wrote 36 bytes for a total of 2697 debug1: client_input_channel_req: channel 0 rtype keepalive at openssh.com reply 1 debug3: Wrote 36 bytes for a total of 2733 debug3: Wrote 68 bytes for a total of 2801 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cfd -1) debug3: channel 0: close_fds r 5 w 6 e 7 c -1 Connection to 10.100.212.166 closed by remote host. Connection to 10.100.212.166 closed. Transferred: sent 2360, received 3088 bytes, in 58.3 seconds Bytes per second: sent 40.5, received 53.0 On Tue, Jan 31, 2017 at 11:34 PM, Sudarshan Soma wrote: > echo $TERM > xterm > > does this variable cause issue, setting it to vt100 ( by export > TERM=vt100) , doesnt make difference. > > On Tue, Jan 31, 2017 at 11:14 PM, Sudarshan Soma > wrote: > >> Hi Darren, I m sending sshd logs : any suggestion/hint please ... >> >> /usr/bin/sshd -ddd -p 2024 -f /etc/ssh/sshd_config -h /etc/ssh_key >> debug2: load_server_config: filename /etc/ssh/sshd_config >> debug2: load_server_config: done config len = 764 >> debug2: parse_server_config: config /etc/ssh/sshd_config len 764 >> debug3: /etc/ssh/sshd_config:2 setting Port 22 >> debug3: /etc/ssh/sshd_config:3 setting Protocol 2 >> debug3: /etc/ssh/sshd_config:4 setting HostKey /etc/ssh/ssh_host_key >> debug3: /etc/ssh/sshd_config:5 setting HostKey /etc/ssh/ssh_host_rsa_key >> debug3: /etc/ssh/sshd_config:6 setting MACs hmac-sha1-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,hmac-sha2-256,hmac-sha2 >> -512,hmac-ripemd160,hmac-ripemd160 at openssh.com >> debug3: macs ok: [hmac-sha1-etm at openssh.com,hmac-sha2-256-etm at openssh.com >> ,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hm >> ac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripe >> md160 at openssh.com] >> debug3: /etc/ssh/sshd_config:7 setting Ciphers >> aes128-ctr,aes192-ctr,aes256-ctr >> debug3: ciphers ok: [aes128-ctr,aes192-ctr,aes256-ctr] >> debug3: /etc/ssh/sshd_config:8 setting AllowUsers root >> debug3: /etc/ssh/sshd_config:10 setting AuthorizedKeysFile >> .ssh/authorized_keys >> debug3: /etc/ssh/sshd_config:11 setting PermitEmptyPasswords yes >> debug3: /etc/ssh/sshd_config:12 setting PasswordAuthentication yes >> debug3: /etc/ssh/sshd_config:13 setting ChallengeResponseAuthentication >> no >> debug3: /etc/ssh/sshd_config:14 setting AllowAgentForwarding no >> debug3: /etc/ssh/sshd_config:15 setting GatewayPorts no >> debug3: /etc/ssh/sshd_config:16 setting X11Forwarding no >> debug3: /etc/ssh/sshd_config:17 setting TCPKeepAlive yes >> debug3: /etc/ssh/sshd_config:18 setting PidFile /tmp/sshd.pid >> debug3: /etc/ssh/sshd_config:19 setting UsePrivilegeSeparation no >> debug3: /etc/ssh/sshd_config:20 setting ClientAliveInterval 15 >> debug3: /etc/ssh/sshd_config:21 setting ClientAliveCountMax 3 >> debug3: /etc/ssh/sshd_config:22 setting MaxStartups 25 >> debug3: /etc/ssh/sshd_config:23 setting PermitTunnel no >> debug3: /etc/ssh/sshd_config:24 setting DenyPortFwd 127.0.0.0/8 >> debug1: Deny port forwarding to host 127.0.0.0/8 >> debug3: /etc/ssh/sshd_config:25 setting Subsystem sftp >> /usr/libexec/sftp-server >> debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1h 5 Jun 2014 >> 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 "/etc/ssh_key" as a RSA1 public key >> debug1: private host key: #0 type 1 RSA >> debug1: could not open key file '/etc/ssh/ssh_host_key': No such file or >> directory >> Could not load host key: /etc/ssh/ssh_host_key >> debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': No such file >> or directory >> Could not load host key: /etc/ssh/ssh_host_rsa_key >> debug1: rexec_argv[0]='/usr/bin/sshd' >> debug1: rexec_argv[1]='-ddd' >> debug1: rexec_argv[2]='-p' >> debug1: rexec_argv[3]='2024' >> debug1: rexec_argv[4]='-f' >> debug1: rexec_argv[5]='/etc/ssh/sshd_config' >> debug1: rexec_argv[6]='-h' >> debug1: rexec_argv[7]='/etc/ssh_key' >> debug3: oom_adjust_setup >> Set /proc/self/oom_score_adj from 0 to -1000 >> debug2: fd 3 setting O_NONBLOCK >> debug1: Bind to port 2024 on 0.0.0.0. >> Server listening on 0.0.0.0 port 2024. >> debug2: fd 4 setting O_NONBLOCK >> debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY >> debug1: Bind to port 2024 on ::. >> Server listening on :: port 2024. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> debug3: fd 5 is not O_NONBLOCK >> debug1: Server will not fork when running in debugging mode. >> debug3: send_rexec_state: entering fd = 8 config len 764 >> debug3: ssh_msg_send: type 0 >> debug3: send_rexec_state: done >> debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 >> debug1: inetd sockets after dupping: 3, 3 >> Connection from 10.220.82.17 port 52586 on 10.100.212.166 port 2024 >> debug1: Client protocol version 2.0; client software version OpenSSH_5.3 >> debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 >> debug1: Enabling compatibility mode for protocol 2.0 >> debug1: Local version string SSH-2.0-OpenSSH_6.6 >> debug2: fd 3 setting O_NONBLOCK >> debug1: list_hostkey_types: ssh-rsa >> debug1: SSH2_MSG_KEXINIT sent >> debug1: SSH2_MSG_KEXINIT received >> debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,e >> cdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diff >> ie-hellman-group-exchange-sha256,diffie-hellman-group-exchan >> ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >> debug2: kex_parse_kexinit: ssh-rsa >> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr >> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr >> debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2 >> -512,hmac-ripemd160,hmac-ripemd160 at openssh.com >> debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2 >> -512,hmac-ripemd160,hmac-ripemd160 at openssh.com >> debug2: kex_parse_kexinit: none,zlib at openssh.com >> debug2: kex_parse_kexinit: none,zlib at openssh.com >> debug2: kex_parse_kexinit: >> debug2: kex_parse_kexinit: >> debug2: kex_parse_kexinit: first_kex_follows 0 >> debug2: kex_parse_kexinit: reserved 0 >> debug2: kex_parse_kexinit: diffie-hellman-group-exchange- >> sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-gro >> up14-sha1,diffie-hellman-group1-sha1 >> debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com,s >> sh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh >> -dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss >> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-c >> tr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc, >> cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se >> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-c >> tr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc, >> cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se >> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com >> ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com >> ,hmac-sha1-96,hmac-md5-96 >> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com >> ,hmac-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: mac_setup: setup hmac-sha1 >> debug1: kex: client->server aes128-ctr hmac-sha1 none >> debug2: mac_setup: setup hmac-sha1 >> debug1: kex: server->client aes128-ctr hmac-sha1 none >> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received >> WARNING: /usr/local/etc/moduli does not exist, using fixed modulus >> debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent >> debug2: bits set: 1088/2048 >> debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT >> debug2: bits set: 1005/2048 >> debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent >> debug2: kex_derive_keys >> debug2: set_newkeys: mode 1 >> debug1: SSH2_MSG_NEWKEYS sent >> debug1: expecting SSH2_MSG_NEWKEYS >> debug2: set_newkeys: mode 0 >> debug1: SSH2_MSG_NEWKEYS received >> debug1: KEX done >> debug1: userauth-request for user root service ssh-connection method none >> debug1: attempt 0 failures 0 >> debug3: Trying to reverse map address 10.220.82.17. >> debug2: parse_server_config: config reprocess config len 764 >> debug3: auth_shadow_acctexpired: today 17197 sp_expire -1 days left -17198 >> debug3: account expiration disabled >> debug2: input_userauth_request: setting up authctxt for root >> debug2: input_userauth_request: try method none >> debug3: auth_shadow_pwexpired: today 17197 sp_lstchg 17177 sp_max 99999 >> Failed none for root from 10.220.82.17 port 52586 ssh2 >> debug3: userauth_finish: failure partial=0 next >> methods="publickey,password" >> debug1: userauth-request for user root service ssh-connection method >> password >> debug1: attempt 1 failures 0 >> debug2: input_userauth_request: try method password >> Accepted password for root from 10.220.82.17 port 52586 ssh2 >> debug1: Entering interactive session for SSH2. >> debug2: fd 4 setting O_NONBLOCK >> debug2: fd 5 setting O_NONBLOCK >> debug1: server_init_dispatch_20 >> debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max >> 16384 >> debug1: input_session_request >> debug1: channel 0: new [server-session] >> debug2: session_new: allocate (allocated 0 max 10) >> debug3: session_unused: session id 0 unused >> debug1: session_new: session 0 >> debug1: session_open: channel 0 >> debug1: session_open: session 0: link with channel 0 >> debug1: server_input_channel_open: confirm session >> debug1: server_input_global_request: rtype no-more-sessions at openssh.com >> want_reply 0 >> debug1: server_input_channel_req: channel 0 request pty-req reply 1 >> debug1: session_by_channel: session 0 channel 0 >> debug1: session_input_channel_req: session 0 req pty-req >> debug1: Allocating pty. >> debug1: session_pty_req: session 0 alloc /dev/pts/2 >> 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 shell reply 1 >> debug1: session_by_channel: session 0 channel 0 >> debug1: session_input_channel_req: session 0 req shell >> Starting session: shell on pts/2 for root from 10.220.82.17 port 52586 >> debug2: fd 3 setting TCP_NODELAY >> debug3: packet_set_tos: set IP_TOS 0x10 >> debug2: channel 0: rfd 8 isatty >> debug2: fd 8 setting O_NONBLOCK >> debug3: fd 6 is O_NONBLOCK >> debug2: channel 0: request keepalive at openssh.com confirm 1 >> debug1: Got 100/12 for keepalive >> >> debug1: Received SIGCHLD. >> debug1: session_by_pid: pid 1871 >> debug1: session_exit_message: session 0 channel 0 pid 1871 >> 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 >> debug1: session_pty_cleanup: session 0 release /dev/pts/2 >> debug2: channel 0: read<=0 rfd 8 len -1 >> debug2: channel 0: read failed >> debug2: channel 0: close_read >> debug2: channel 0: input open -> drain >> debug2: channel 0: ibuf empty >> debug2: channel 0: send eof >> debug2: channel 0: input drain -> closed >> debug2: channel 0: send close >> debug2: notify_done: reading >> debug3: channel 0: will not send data after close >> debug2: channel 0: rcvd close >> Received disconnect from 10.220.82.17: 11: disconnected by user >> debug1: do_cleanup >> >> >> >> >> ssh logs: >> >> ssh -vvv root at 10.100.212.166 -p 2024 >> OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 >> debug1: Reading configuration data /etc/ssh/ssh_config >> debug1: Applying options for * >> debug2: ssh_connect: needpriv 0 >> debug1: Connecting to 10.100.212.166 [10.100.212.166] port 2024. >> debug1: Connection established. >> debug1: identity file /home/ssoma/.ssh/identity type -1 >> debug1: identity file /home/ssoma/.ssh/identity-cert type -1 >> debug1: identity file /home/ssoma/.ssh/id_rsa type -1 >> debug1: identity file /home/ssoma/.ssh/id_rsa-cert type -1 >> debug1: identity file /home/ssoma/.ssh/id_dsa type -1 >> debug1: identity file /home/ssoma/.ssh/id_dsa-cert type -1 >> debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6 >> debug1: match: OpenSSH_6.6 pat OpenSSH* >> debug1: Enabling compatibility mode for protocol 2.0 >> debug1: Local version string SSH-2.0-OpenSSH_5.3 >> debug2: fd 4 setting O_NONBLOCK >> debug1: SSH2_MSG_KEXINIT sent >> debug3: Wrote 960 bytes for a total of 981 >> debug1: SSH2_MSG_KEXINIT received >> debug2: kex_parse_kexinit: diffie-hellman-group-exchange- >> sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-gro >> up14-sha1,diffie-hellman-group1-sha1 >> debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com,s >> sh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh >> -dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss >> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-c >> tr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc, >> cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se >> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-c >> tr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc, >> cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se >> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com >> ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com >> ,hmac-sha1-96,hmac-md5-96 >> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com >> ,hmac-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,e >> cdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diff >> ie-hellman-group-exchange-sha256,diffie-hellman-group-exchan >> ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 >> debug2: kex_parse_kexinit: ssh-rsa >> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr >> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr >> debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2 >> -512,hmac-ripemd160,hmac-ripemd160 at openssh.com >> debug2: kex_parse_kexinit: hmac-sha1-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,hmac-sha2-256,hmac-sha2 >> -512,hmac-ripemd160,hmac-ripemd160 at openssh.com >> 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-sha1 >> debug1: kex: server->client aes128-ctr hmac-sha1 none >> debug2: mac_setup: found hmac-sha1 >> debug1: kex: client->server aes128-ctr hmac-sha1 none >> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent >> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP >> debug3: Wrote 24 bytes for a total of 1005 >> debug2: dh_gen_key: priv key bits set: 154/320 >> debug2: bits set: 1005/2048 >> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent >> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY >> debug3: Wrote 272 bytes for a total of 1277 >> debug3: put_host_port: [10.100.212.166]:2024 >> debug3: put_host_port: [10.100.212.166]:2024 >> debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename >> /home/ssoma/.ssh/known_hosts >> debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename >> /home/ssoma/.ssh/known_hosts >> debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename >> /etc/ssh/ssh_known_hosts >> debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename >> /etc/ssh/ssh_known_hosts >> debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename >> /home/ssoma/.ssh/known_hosts >> debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename >> /home/ssoma/.ssh/known_hosts >> debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename >> /etc/ssh/ssh_known_hosts >> debug3: check_host_in_hostfile: host [10.100.212.166]:2024 filename >> /etc/ssh/ssh_known_hosts >> debug1: checking without port identifier >> debug3: check_host_in_hostfile: host 10.100.212.166 filename >> /home/ssoma/.ssh/known_hosts >> debug3: check_host_in_hostfile: host 10.100.212.166 filename >> /home/ssoma/.ssh/known_hosts >> debug3: check_host_in_hostfile: match line 135 >> debug1: Host '10.100.212.166' is known and matches the RSA host key. >> debug1: Found key in /home/ssoma/.ssh/known_hosts:135 >> debug1: found matching key w/out port >> debug2: bits set: 1088/2048 >> debug1: ssh_rsa_verify: signature correct >> debug2: kex_derive_keys >> debug2: set_newkeys: mode 1 >> debug1: SSH2_MSG_NEWKEYS sent >> debug1: expecting SSH2_MSG_NEWKEYS >> debug3: Wrote 16 bytes for a total of 1293 >> debug2: set_newkeys: mode 0 >> debug1: SSH2_MSG_NEWKEYS received >> debug1: SSH2_MSG_SERVICE_REQUEST sent >> debug3: Wrote 52 bytes for a total of 1345 >> debug2: service_accept: ssh-userauth >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> debug2: key: /home/ssoma/.ssh/identity ((nil)) >> debug2: key: /home/ssoma/.ssh/id_rsa ((nil)) >> debug2: key: /home/ssoma/.ssh/id_dsa ((nil)) >> debug3: Wrote 68 bytes for a total of 1413 >> debug1: Authentications that can continue: publickey,password >> debug3: start over, passed a different list publickey,password >> debug3: preferred gssapi-keyex,gssapi-with-mic,p >> ublickey,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/ssoma/.ssh/identity >> debug3: no such identity: /home/ssoma/.ssh/identity >> debug1: Trying private key: /home/ssoma/.ssh/id_rsa >> debug3: no such identity: /home/ssoma/.ssh/id_rsa >> debug1: Trying private key: /home/ssoma/.ssh/id_dsa >> debug3: no such identity: /home/ssoma/.ssh/id_dsa >> debug2: we did not send a packet, disable method >> debug3: authmethod_lookup password >> debug3: remaining preferred: ,password >> debug3: authmethod_is_enabled password >> debug1: Next authentication method: password >> root at 10.100.212.166's password: >> debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64) >> debug2: we sent a password packet, wait for reply >> debug3: Wrote 148 bytes for a total of 1561 >> debug1: Authentication succeeded (password). >> debug1: channel 0: new [client-session] >> debug3: ssh_session2_open: channel_new: 0 >> debug2: channel 0: send open >> debug1: Requesting no-more-sessions at openssh.com >> debug1: Entering interactive session. >> debug3: Wrote 136 bytes for a total of 1697 >> debug2: callback start >> debug2: client_session2_setup: id 0 >> debug2: channel 0: request pty-req confirm 1 >> debug1: Sending environment. >> debug3: Ignored env CCACHE_NOSTATS >> debug3: Ignored env HOSTNAME >> debug3: Ignored env TERM >> debug3: Ignored env SHELL >> debug3: Ignored env HISTSIZE >> debug3: Ignored env SSH_CLIENT >> debug3: Ignored env CCACHE_LOGFILE >> debug3: Ignored env QTDIR >> debug3: Ignored env QTINC >> debug3: Ignored env SSH_TTY >> debug3: Ignored env USER >> debug3: Ignored env LS_COLORS >> debug3: Ignored env CSCOPE_EDITOR >> debug3: Ignored env COVLM >> debug3: Ignored env MAIL >> debug3: Ignored env PATH >> debug3: Ignored env PWD >> debug1: Sending env LANG = en_US.UTF-8 >> debug2: channel 0: request env confirm 0 >> debug3: Ignored env MODULEPATH >> debug3: Ignored env LOADEDMODULES >> debug3: Ignored env P4CLIENT >> debug3: Ignored env SSH_ASKPASS >> debug3: Ignored env HISTCONTROL >> debug3: Ignored env SHLVL >> debug3: Ignored env HOME >> debug3: Ignored env LOGNAME >> debug3: Ignored env QTLIB >> debug3: Ignored env CVS_RSH >> debug3: Ignored env SSH_CONNECTION >> debug3: Ignored env MODULESHOME >> debug3: Ignored env LESSOPEN >> debug3: Ignored env P4PORT >> debug3: Ignored env G_BROKEN_FILENAMES >> debug3: Ignored env BASH_FUNC_module() >> debug3: Ignored env _ >> debug2: channel 0: request shell confirm 1 >> debug2: fd 4 setting TCP_NODELAY >> debug2: callback done >> debug2: channel 0: open confirm rwindow 0 rmax 32768 >> debug3: Wrote 460 bytes for a total of 2157 >> debug2: channel_input_status_confirm: type 99 id 0 >> debug2: PTY allocation request accepted on channel 0 >> debug2: channel 0: rcvd adjust 2097152 >> debug2: channel_input_status_confirm: type 99 id 0 >> debug2: shell request accepted on channel 0 >> Last login: Tue Jan 31 16:45:24 2017 from 10.220.82.17 >> debug1: permanently_set_uid: 0/0 >> Environment: >> USER=root >> LOGNAME=root >> HOME=/root >> PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin >> MAIL=/var/mail/root >> SHELL=/bin/bash >> TZ=UTC >> SSH_CLIENT=10.220.82.17 52586 2024 >> SSH_CONNECTION=10.220.82.17 52586 10.100.212.166 2024 >> SSH_TTY=/dev/pts/2 >> TERM=xterm >> -bash: no job control in this shell >> file setup_env.sh found... >> >> >> On Fri, Jan 20, 2017 at 11:57 AM, Sudarshan Soma >> wrote: >> >>> Thanks Darren, will check on your response. >>> I am attaching sshd, ssh logs with debug flags. Please see if it gives >>> any hint: >>> >>> when I press ^C in ssh session, no log gets printed in both >>> server/client side. >>> >>> Best Regards, >>> >>> >>> >>> >>> On Wed, Jan 18, 2017 at 3:09 AM, Darren Tucker >>> wrote: >>> >>>> On Wed, Jan 18, 2017 at 5:10 AM, Sudarshan Soma >>>> wrote: >>>> > Thanks Ben. i am checking in linux. >>>> > I do have this command working: >>>> > ssh localhost -o password=abc123 >>>> >>>> That's definitely a modified ssh binary. >>>> >>>> > will try to getback on openssh used. But is it possible to show some >>>> > pointers for my queries, avoid arguments in ps or /proc >>>> >>>> I don't think you reliably can. >>>> >>>> You can add a call to setproctitle() to ssh but I don't think that >>>> affects all sets of options to ps, and even if it did there's still a >>>> race between when the process starts and when you call setproctitle >>>> during which the password is exposed. >>>> >>>> So don't do that, instead use public-key, or if you must use a >>>> password read it from a suitably locked down file. You can (with some >>>> difficulty) get ssh to read a password via an $SSH_ASKPASS program. >>>> >>>> > and other one was on ^C not working on my ssh sessions. >>>> >>>> just a guess but check the permissions on /dev/tty on the server. >>>> They should look like: >>>> crw-rw-rw- 1 root tty 5, 0 Jan 17 19:34 /dev/tty >>>> >>>> Failing that please post the debug output of ssh -vvv and sshd -ddd >>>> from an unmodified (ie as available from openssh.com) client and >>>> server pair. >>>> >>>> -- >>>> Darren Tucker (dtucker at zip.com.au) >>>> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA >>>> (new) >>>> Good judgement comes with experience. Unfortunately, the experience >>>> usually comes from bad judgement. >>>> >>> >>> >> > From stefbon at gmail.com Mon Feb 6 19:31:53 2017 From: stefbon at gmail.com (Stef Bon) Date: Mon, 6 Feb 2017 09:31:53 +0100 Subject: Greeter openssh 7.4 is not according rfc4253. In-Reply-To: References: Message-ID: 2017-02-05 23:12 GMT+01:00 Michael Stone : > > It was probably because of this commit: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.472&r2=1.473 > Yes here the combination cr and lf is removed. > Which removed support for protocols older than 2 but perhaps failed to > account for the fact that newline had been redefined when using protocol 2. > But as someone else said, give it a few days for a response. Sure. I reacted not to make you hurry, but for me an error in the greeter (as in the whole init and negotiation phase) is crucial. And I think not only my software, but others too. Error's have to be reported as soon as possible, since openssh is widely used a lot and important to many. Thanks a lot, Stef From djm at mindrot.org Mon Feb 6 20:25:11 2017 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Feb 2017 20:25:11 +1100 (AEDT) Subject: Greeter openssh 7.4 is not according rfc4253. In-Reply-To: References: Message-ID: On Mon, 6 Feb 2017, Stef Bon wrote: > 2017-02-05 23:12 GMT+01:00 Michael Stone : > > > > It was probably because of this commit: > > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.472&r2=1.473 Thanks, I've committed a fix. > > Which removed support for protocols older than 2 but perhaps failed to > > account for the fact that newline had been redefined when using protocol 2. > > But as someone else said, give it a few days for a response. > > Sure. I reacted not to make you hurry, but for me an error in the > greeter (as in the whole init and negotiation phase) > is crucial. And I think not only my software, but others too. > Error's have to be reported as soon as possible, since openssh is > widely used a lot and important to many. It's not crucial at all. Clients must be prepared to handle ident strings terminated with \n, since it is what mixed SSHv1/SSHv2 servers typically send (e.g look at the first "if" block in the diff Michael sent). -d From stefbon at gmail.com Mon Feb 6 21:20:41 2017 From: stefbon at gmail.com (Stef Bon) Date: Mon, 6 Feb 2017 11:20:41 +0100 Subject: Greeter openssh 7.4 is not according rfc4253. In-Reply-To: References: Message-ID: 2017-02-06 10:25 GMT+01:00 Damien Miller : > On Mon, 6 Feb 2017, Stef Bon wrote: > > It's not crucial at all. Clients must be prepared to handle ident strings > terminated with \n, since it is what mixed SSHv1/SSHv2 servers typically > send (e.g look at the first "if" block in the diff Michael sent). > Yes you are right. This bug is not fatal. But the combination LF (thus without the CR) and SSH2 is still an error right? Stef From Vincent.LEFEVERE at hei.fr Mon Feb 6 21:40:37 2017 From: Vincent.LEFEVERE at hei.fr (Vincent LEFEVERE) Date: Mon, 6 Feb 2017 10:40:37 +0000 Subject: log port forwarding Message-ID: <5f0bd631fd0f44aeb3e3a78a8baf8266@FRL13RTVM20.campus-hei.intranet> Hello So that the user displayed in the log is the one of connection and not the first corresponding to the UID, I corrected the patch that I submitted last week. So it works even if you define multiple users with the same UID. Best regards Vincent Lef?v?re From Vincent.LEFEVERE at hei.fr Tue Feb 7 06:05:59 2017 From: Vincent.LEFEVERE at hei.fr (Vincent LEFEVERE) Date: Mon, 6 Feb 2017 19:05:59 +0000 Subject: log port forwarding Message-ID: <8fb52a91e4044231ad342375c3476daf@FRL13RTVM20.campus-hei.intranet> Sorry, I forgot to join the new patch Best regards Vincent Lef?v?re -------------- next part -------------- A non-text attachment was scrubbed... Name: log_port_forwarding.patch.gz Type: application/x-gzip Size: 1609 bytes Desc: log_port_forwarding.patch.gz URL: From dearvoid at gmail.com Tue Feb 7 17:15:03 2017 From: dearvoid at gmail.com (Clark Wang) Date: Tue, 7 Feb 2017 14:15:03 +0800 Subject: Why "ssh -f -n" still connects to ptys? Message-ID: See following example: $ ps p 45374 PID TTY STAT TIME COMMAND 45374 ? Ss 0:00 ssh -N -D 7777 -f -n localhost $ ls -l /proc/45374/fd/ total 0 lrwx------ 1 root root 64 2017-02-07 14:12 0 -> /dev/pts/2 lrwx------ 1 root root 64 2017-02-07 14:12 1 -> /dev/pts/2 lrwx------ 1 root root 64 2017-02-07 14:12 2 -> /dev/pts/2 lrwx------ 1 root root 64 2017-02-07 14:12 3 -> socket:[348711] lrwx------ 1 root root 64 2017-02-07 14:12 4 -> socket:[348767] $ Why not open FDs 0, 1 and 2 on /dev/null? -clark From alexis.horgix.chotard at gmail.com Wed Feb 8 08:55:55 2017 From: alexis.horgix.chotard at gmail.com (Alexis Horgix Chotard) Date: Tue, 7 Feb 2017 22:55:55 +0100 Subject: [Doc] Extension of Included configuration files Message-ID: Hello, I'm really happy that the 7.3 release of OpenSSH introduced the Include directive. However, since there is absolutely no restriction or advice neither on the name nor on the location of the included files, it makes it harder for external tools to recognize them; I'm mainly thinking about text editors that would like to enable syntax coloration for it ( https://github.com/vim/vim/pull/1452 ). Until now it wasn't a problem since the file was either `ssh_config` or `~/.ssh/config` in most cases - maybe all ? no idea if this is configurable. I would like to include a SHOULD part to the man section of the Include directive in an effort to make those included files recognizable. I'm sure you'll have a better suggestion for the wording than me; however you'll find a patch attached for the sentence "Configuration file(s) referenced by this Include directive should use the .sshconfig extension to be detected as such by external tools." but it could also be something simpler like "If you want external tools to detect your configuration files, they should use the .sshconfig extension". Let me know what you think about it, Regards, -- Alexis 'Horgix' Chotard -------------- next part -------------- A non-text attachment was scrubbed... Name: include-extension.patch Type: text/x-diff Size: 743 bytes Desc: not available URL: From dtucker at zip.com.au Wed Feb 8 15:33:37 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 8 Feb 2017 15:33:37 +1100 Subject: Why "ssh -f -n" still connects to ptys? In-Reply-To: References: Message-ID: On Tue, Feb 7, 2017 at 5:15 PM, Clark Wang wrote: > See following example: > > $ ps p 45374 > PID TTY STAT TIME COMMAND > 45374 ? Ss 0:00 ssh -N -D 7777 -f -n localhost > $ ls -l /proc/45374/fd/ > total 0 > lrwx------ 1 root root 64 2017-02-07 14:12 0 -> /dev/pts/2 > lrwx------ 1 root root 64 2017-02-07 14:12 1 -> /dev/pts/2 > lrwx------ 1 root root 64 2017-02-07 14:12 2 -> /dev/pts/2 > lrwx------ 1 root root 64 2017-02-07 14:12 3 -> socket:[348711] > lrwx------ 1 root root 64 2017-02-07 14:12 4 -> socket:[348767] > $ > > Why not open FDs 0, 1 and 2 on /dev/null? It's not obvious from the man page (I had to look at the code), but that's not how it works. -n affects the handling of the descriptor attached to the ssh command channel, not the descriptors that the ssh process uses to interact with the user. -n (or -f, you only need to set one of them) set stdin_null_flag, and what it does when setting up the channel connected to the remote command is: ssh_session2_open [...] if (stdin_null_flag) in = open(_PATH_DEVNULL, O_RDONLY); else in = dup(STDIN_FILENO); out = dup(STDOUT_FILENO); err = dup(STDERR_FILENO); Compare with and without -n: $ ssh localhost sleep 60 $ ls -l /proc/25235/fd lrwx------ 1 dtucker dtucker 64 Feb 8 15:26 0 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:26 1 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:26 2 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:26 3 -> 'socket:[149316207]' lrwx------ 1 dtucker dtucker 64 Feb 8 15:26 4 -> 'socket:[149316212]' lrwx------ 1 dtucker dtucker 64 Feb 8 15:26 5 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:26 6 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:26 7 -> /dev/pts/30 $ ssh -n localhost sleep 60 $ ls -l /proc/24959/fd/ total 0 lrwx------ 1 dtucker dtucker 64 Feb 8 15:25 0 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:25 1 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:25 2 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:25 3 -> 'socket:[149315695]' lrwx------ 1 dtucker dtucker 64 Feb 8 15:25 4 -> 'socket:[149315701]' lrwx------ 1 dtucker dtucker 64 Feb 8 15:25 6 -> /dev/pts/30 lrwx------ 1 dtucker dtucker 64 Feb 8 15:25 7 -> /dev/pts/30 Note that fd#5 (stdin attached to the command channel) is missing in the second. In your case you're not seeing any change in behaviour because -N causes ssh to not request a command channel at all. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Vincent.LEFEVERE at hei.fr Fri Feb 10 07:10:20 2017 From: Vincent.LEFEVERE at hei.fr (Vincent LEFEVERE) Date: Thu, 9 Feb 2017 20:10:20 +0000 Subject: log port forwarding Message-ID: <06e6532cd5a54e70b098749602ea894d@FRL13RTVM20.campus-hei.intranet> Hello, Not receiving a reply to the previous mail about logging port forwarding in the ssh daemon, let me explain the reason for this need. It is a question of using a machine as a bastion to isolate two networks and at the same time allow connections between these two networks via ssh tunnels. For security reasons, it is necessary to keep track of each tunnel associated with the login used in a log. It is of course necessary to set the user's shell to / bin / cat or an equivalent command so that the user can not run another solution to create tunnels. The patch that I have previously suggested logs in syslog every outgoing or dynamic tunnel. But it does not log the incoming tunnels. What can be judged insufficient! Using the variables displayed in debug, I discovered another problem: the address and port of the origin of the tunnels are always 0.0.0.0:0 This does not make it easy to link information between a firewall that logged an attack and the tunnel used by the attack (and the associated login). So, I corrected this with a new patch attached. (I tested it with IPv4 and IPv6 tunnels on Linux.) Could you tell me if you agree to integrate the feature (using or not the patch I gave you)? Thank you Best regards Vincent Lefevere From openssh at lists.killian.com Fri Feb 10 06:55:50 2017 From: openssh at lists.killian.com (Earl A. Killian) Date: Thu, 9 Feb 2017 11:55:50 -0800 Subject: ssh-keygen -T -j Message-ID: <8a047f8f-d172-47f8-a3b8-0d3bcd64c34f@killian.com> I was 8 hours into a ssh-keygen -T when the power went out. So I tried to restart by appending -j LINENO to the command line, but ssh-keygen just gave me the Usage message in response (and yes the usage for -T includes "[-j start_line]". The LINENO that I gave it was from the last output line before the crash where it says "processed LINENO of NUMLINES". Is there any documentation on how this is supposed to work? The man page does not give me any additional information. -Earl From dtucker at zip.com.au Fri Feb 10 14:50:10 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 10 Feb 2017 14:50:10 +1100 Subject: ssh-keygen -T -j In-Reply-To: <8a047f8f-d172-47f8-a3b8-0d3bcd64c34f@killian.com> References: <8a047f8f-d172-47f8-a3b8-0d3bcd64c34f@killian.com> Message-ID: On Fri, Feb 10, 2017 at 6:55 AM, Earl A. Killian wrote: > I was 8 hours into a ssh-keygen -T when the power went out. So I tried to > restart by appending -j LINENO to the command line, but ssh-keygen just gave > me the Usage message in response (and yes the usage for -T includes "[-j > start_line]". The LINENO that I gave it was from the last output line before > the crash where it says "processed LINENO of NUMLINES". > > Is there any documentation on how this is supposed to work? The man page > does not give me any additional information. You're probably doing it right, however the option handling of -j and -J was incorrectly removed between versions 6.9p1 and 7.3p1. It was restored in 7.4p1 and was never missing in any of the OpenBSD upstream versions (which is where we use it and hence why we didn't miss it). https://anongit.mindrot.org/openssh.git/commit/ssh-keygen.c?id=0bb2980260fb24e5e0b51adac471395781b66261 -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From A.MALDEME at olky.eu Fri Feb 10 19:20:47 2017 From: A.MALDEME at olky.eu (Alexandre MALDEME) Date: Fri, 10 Feb 2017 08:20:47 +0000 Subject: Disabling specific commands in sftp Message-ID: <3caaaa7beb20461a85af05f7a38539dc@srv-mail-01.OLKYPAY.LOCAL> Hi, On CentOS 7 I?m trying to set up a chrooted SFTP server on which specific users can only read and write on specific folder. And I?d like to disable some commands, so the users can only do ?cd?, ?ls?, ?get? and ?put? (and disabling ?chgrp?, ?chmod?, ?chown?, ?df? etc ?). Is there a way to achieve it, natively or with using a third-party software ? Alexandre MALDEME Analyste d'exploitation [cid:image025b45.PNG at eb29890d.49b3fa4c] +33 (0)9 74 74 88 05 [www.olkypay.com] www.olkypay.com [cid:image47a4b4.GIF at a587ac6d.4190a711] Please consider the environment before printing this email message. Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, merci d'en avertir A.MALDEME at olky.eu. Il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer A.MALDEME at olky.eu par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify A.MALDEME at olky.eu. This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify A.MALDEME at olky.eu immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nkadel at gmail.com Sun Feb 12 05:12:57 2017 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 11 Feb 2017 13:12:57 -0500 Subject: Disabling specific commands in sftp In-Reply-To: <3caaaa7beb20461a85af05f7a38539dc@srv-mail-01.OLKYPAY.LOCAL> References: <3caaaa7beb20461a85af05f7a38539dc@srv-mail-01.OLKYPAY.LOCAL> Message-ID: On Fri, Feb 10, 2017 at 3:20 AM, Alexandre MALDEME wrote: > Hi, > > On CentOS 7 I?m trying to set up a chrooted SFTP server on which specific users can only read and write on specific folder. And I?d like to disable some commands, so the users can only do ?cd?, ?ls?, ?get? and ?put? (and disabling ?chgrp?, ?chmod?, ?chown?, ?df? etc ?). Is there a way to achieve it, natively or with using a third-party software ? There were some published OpenSSH chroot patches years ago, but they've been repeatedly rejected for various security reasons. The underlying reasoning seems to be that a chroot cage is not a completely reliable security measure, since enough of the operating system is necessarily exposed inside the chroot cage to create a risk of possible exploitation and access to the hosting system. I've personally disagreed with this approach for a long time, because the lack of such tools leaves many casual adminstrators simply exposing their systems with full shell access and much less limited otols.. There is an old add-on tool called "rssh" that pretty effectively limits access to rsync, sftp, or scp on a selectable and configurable basis for specific users. It does badly need an update to its chroot cage building tool, which I've submitted as a patch and the maintainer of rssh has elected not to manage or maintain that tool. Rssh is available at http://www.pizzashack.org/rssh/.. My chroot cage building tools to go with it are at https://github.com/nkadel/rssh-chroot-tools. Another fast and dirty tool is to use the "validate-rsync.sh" tool locked to SSH key "command" settings, to fairly effectively allow only rsync access. Another approach is to give up on sftp, which does have some longstanding limitations, and use more cage-manageable tools like WebDAV over HTTPS, which is more easily published as a pure user-space without any other chroot cage components in it and is Apache supported, or even plain old FTPS, which also works well and is built into vsftpd. > Alexandre MALDEME > Analyste d'exploitation > [cid:image025b45.PNG at eb29890d.49b3fa4c] +33 (0)9 74 74 88 05 > [www.olkypay.com] > www.olkypay.com > > [cid:image47a4b4.GIF at a587ac6d.4190a711] > Please consider the environment before printing this email message. > > Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, merci d'en avertir A.MALDEME at olky.eu. Il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer A.MALDEME at olky.eu par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify A.MALDEME at olky.eu. This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify A.MALDEME at olky.eu immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From peter at stuge.se Sun Feb 12 06:02:22 2017 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Feb 2017 19:02:22 +0000 Subject: Disabling specific commands in sftp In-Reply-To: <3caaaa7beb20461a85af05f7a38539dc@srv-mail-01.OLKYPAY.LOCAL> References: <3caaaa7beb20461a85af05f7a38539dc@srv-mail-01.OLKYPAY.LOCAL> Message-ID: <20170211190222.GQ21523@foo.stuge.se> Alexandre MALDEME wrote: > On CentOS 7 I?m trying to set up a chrooted SFTP server on which > specific users can only read and write on specific folder. I don't know if your CentOS 7 constraint is helpful for you, but sshd has a ChrootDirectory configuration option and if you use internal-sftp for the sftp subsystem you do not need any special files in the chroot. > And I?d like to disable some commands, so the users can only do > ?cd?, ?ls?, ?get? and ?put? (and disabling ?chgrp?, ?chmod?, > ?chown?, ?df? etc ?). As for arbitrarily disabling commands, that may well need patching, because the OpenSSH sftp server does not really have any (policy) configuration. I for one like that. //Peter From jonathan at pauliwerks.com Sun Feb 12 06:40:28 2017 From: jonathan at pauliwerks.com (Jonathan Pauli) Date: Sat, 11 Feb 2017 11:40:28 -0800 Subject: Disabling specific commands in sftp In-Reply-To: References: <3caaaa7beb20461a85af05f7a38539dc@srv-mail-01.OLKYPAY.LOCAL> Message-ID: <0296CFF9-EBFC-4F84-A51A-EF726E0B2FF1@pauliwerks.com> I think for this I might try running sftp in a container instead of chroot. I might then add some feature flags around the commands I don't like and compile a custom version of it. Of course, auditors hate me, but so it goes. > On Feb 11, 2017, at 10:12 AM, Nico Kadel-Garcia wrote: > >> On Fri, Feb 10, 2017 at 3:20 AM, Alexandre MALDEME wrote: >> Hi, >> >> On CentOS 7 I?m trying to set up a chrooted SFTP server on which specific users can only read and write on specific folder. And I?d like to disable some commands, so the users can only do ?cd?, ?ls?, ?get? and ?put? (and disabling ?chgrp?, ?chmod?, ?chown?, ?df? etc ?). Is there a way to achieve it, natively or with using a third-party software ? > > There were some published OpenSSH chroot patches years ago, but > they've been repeatedly rejected for various security reasons. The > underlying reasoning seems to be that a chroot cage is not a > completely reliable security measure, since enough of the operating > system is necessarily exposed inside the chroot cage to create a risk > of possible exploitation and access to the hosting system. I've > personally disagreed with this approach for a long time, because the > lack of such tools leaves many casual adminstrators simply exposing > their systems with full shell access and much less limited otols.. > > There is an old add-on tool called "rssh" that pretty effectively > limits access to rsync, sftp, or scp on a selectable and configurable > basis for specific users. It does badly need an update to its chroot > cage building tool, which I've submitted as a patch and the maintainer > of rssh has elected not to manage or maintain that tool. Rssh is > available at http://www.pizzashack.org/rssh/.. My chroot cage building > tools to go with it are at > https://github.com/nkadel/rssh-chroot-tools. > > Another fast and dirty tool is to use the "validate-rsync.sh" tool > locked to SSH key "command" settings, to fairly effectively allow only > rsync access. > > Another approach is to give up on sftp, which does have some > longstanding limitations, and use more cage-manageable tools like > WebDAV over HTTPS, which is more easily published as a pure user-space > without any other chroot cage components in it and is Apache > supported, or even plain old FTPS, which also works well and is built > into vsftpd. > > >> Alexandre MALDEME >> Analyste d'exploitation >> [cid:image025b45.PNG at eb29890d.49b3fa4c] +33 (0)9 74 74 88 05 >> [www.olkypay.com] >> www.olkypay.com >> >> [cid:image47a4b4.GIF at a587ac6d.4190a711] >> Please consider the environment before printing this email message. >> >> Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, merci d'en avertir A.MALDEME at olky.eu. Il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer A.MALDEME at olky.eu par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme >> >> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify A.MALDEME at olky.eu. This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify A.MALDEME at olky.eu immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From nkadel at gmail.com Sun Feb 12 14:44:32 2017 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 11 Feb 2017 22:44:32 -0500 Subject: Disabling specific commands in sftp In-Reply-To: <0296CFF9-EBFC-4F84-A51A-EF726E0B2FF1@pauliwerks.com> References: <3caaaa7beb20461a85af05f7a38539dc@srv-mail-01.OLKYPAY.LOCAL> <0296CFF9-EBFC-4F84-A51A-EF726E0B2FF1@pauliwerks.com> Message-ID: On Sat, Feb 11, 2017 at 2:40 PM, Jonathan Pauli wrote: > I think for this I might try running sftp in a container instead of chroot. > > I might then add some feature flags around the commands I don't like and compile a custom version of it. Of course, auditors hate me, but so it goes. A container is a good move for this. And be sure, to take advantage of the limited chroot features for sftp, that you need *sftp* and not *scp*, *ssh*, *rsync*, or others. From dtucker at zip.com.au Sun Feb 12 16:30:35 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 12 Feb 2017 16:30:35 +1100 Subject: Disabling specific commands in sftp In-Reply-To: References: <3caaaa7beb20461a85af05f7a38539dc@srv-mail-01.OLKYPAY.LOCAL> Message-ID: On Sun, Feb 12, 2017 at 5:12 AM, Nico Kadel-Garcia wrote: > On Fri, Feb 10, 2017 at 3:20 AM, Alexandre MALDEME wrote: >> Hi, >> >> On CentOS 7 I?m trying to set up a chrooted SFTP server on which specific users can only read and write on specific folder. And I?d like to disable some commands, so the users can only do ?cd?, ?ls?, ?get? and ?put? (and disabling ?chgrp?, ?chmod?, ?chown?, ?df? etc ?). Is there a way to achieve it, natively or with using a third-party software ? > > There were some published OpenSSH chroot patches years ago, but > they've been repeatedly rejected for various security reasons. Err, sshd has ChrootDirectory which was added in the version 4.8 (released in 2008): https://www.openssh.com/releasenotes.html#4.8 sftp-server has flags -P and -p which blacklist and whitelist requests respectively which were added in 6.5: https://www.openssh.com/releasenotes.html#6.5. ChrootDirectory can be used inside a Match User block, but right now Subsystem can't. If Alexandre can get away with setting -P or -p globally for sftp-internal for all users then it should be possible, and Subsystem could be made to work inside a Match block with a bit of work. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From nunojpg at gmail.com Mon Feb 13 01:46:14 2017 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Sun, 12 Feb 2017 15:46:14 +0100 Subject: Fwd: Server accepts key: pkalg rsa-sha2-512 vs ssh-rsa In-Reply-To: <09db41ea-636c-2ec5-93e6-fe72d75aa0c7@gmail.com> References: <53cb818d-e72e-78fe-7216-c1a56ef73f6f@redhat.com> <09db41ea-636c-2ec5-93e6-fe72d75aa0c7@gmail.com> Message-ID: On 1/30/2017 3:58 AM, Jakub Jelen wrote: > This is part of deprecation SHA1 for signatures, which were hardcoded into the core RFCs. The different hashes were introduced in OpenSSH 7.2 [1] and are negotiated using the protocol extension. I > don't think there are configuration options to control this behavior, but the new algorithms have higher priority for new OpenSSH versions. > > [1] http://www.openssh.com/txt/release-7.2 > > Regards, In that case this is converted to a bug report: Deprecation of SHA1 is not being enforced since 7.4p1. The side effect of this bug is that my "problem" originally reported disappeared from 7.3p1 to 7.4p1. It was fixed by properly supporting rsa-sha2-256 from OpenSC (my pkcs11 lib) side, but during tests we found out that 7.4p1 was not using rsa-sha2-256 anymore. Bug was introduced with commit: https://github.com/openssh/openssh-portable/commit/130f5df4fa37cace8c079dccb690e5cafbf00751. Due to: https://bugzilla.mindrot.org/show_bug.cgi?id=2547 >From this commit rsa-sha2-256 and rsa-sha2-512 are no longer offered so all is downgraded to rsa-sha. A fix applied at current master could be: diff --git a/kex.c b/kex.c index a30dabe..13bb9aa 100644 --- a/kex.c +++ b/kex.c @@ -348,7 +348,7 @@ kex_send_ext_info(struct ssh *ssh) int r; char *algs; - if ((algs = sshkey_alg_list(0, 1, ',')) == NULL) + if ((algs = sshkey_alg_list(0, 1, 1, ',')) == NULL) return SSH_ERR_ALLOC_FAIL; if ((r = sshpkt_start(ssh, SSH2_MSG_EXT_INFO)) != 0 || (r = sshpkt_put_u32(ssh, 1)) != 0 || diff --git a/ssh.c b/ssh.c index ee0b16d..edef335 100644 --- a/ssh.c +++ b/ssh.c @@ -684,11 +684,11 @@ main(int ac, char **av) else if (strcmp(optarg, "kex") == 0) cp = kex_alg_list('\n'); else if (strcmp(optarg, "key") == 0) - cp = sshkey_alg_list(0, 0, '\n'); + cp = sshkey_alg_list(0, 0, 0, '\n'); else if (strcmp(optarg, "key-cert") == 0) - cp = sshkey_alg_list(1, 0, '\n'); + cp = sshkey_alg_list(1, 0, 0, '\n'); else if (strcmp(optarg, "key-plain") == 0) - cp = sshkey_alg_list(0, 1, '\n'); + cp = sshkey_alg_list(0, 1, 0, '\n'); else if (strcmp(optarg, "protocol-version") == 0) { #ifdef WITH_SSH1 cp = xstrdup("1\n2"); diff --git a/sshkey.c b/sshkey.c index 31710e5..1c5dfdb 100644 --- a/sshkey.c +++ b/sshkey.c @@ -195,14 +195,16 @@ sshkey_ecdsa_nid_from_name(const char *name) } char * -sshkey_alg_list(int certs_only, int plain_only, char sep) +sshkey_alg_list(int certs_only, int plain_only, int sigonly_also, char sep) { char *tmp, *ret = NULL; size_t nlen, rlen = 0; const struct keytype *kt; for (kt = keytypes; kt->type != -1; kt++) { - if (kt->name == NULL || kt->sigonly) + if (kt->name == NULL) + continue; + if (!sigonly_also && kt->sigonly) continue; if ((certs_only && !kt->cert) || (plain_only && kt->cert)) continue; diff --git a/sshkey.h b/sshkey.h index f393638..6a3ff2f 100644 --- a/sshkey.h +++ b/sshkey.h @@ -156,7 +156,7 @@ int sshkey_ec_validate_private(const EC_KEY *); const char *sshkey_ssh_name(const struct sshkey *); const char *sshkey_ssh_name_plain(const struct sshkey *); int sshkey_names_valid2(const char *, int); -char *sshkey_alg_list(int, int, char); +char *sshkey_alg_list(int, int, int, char); int sshkey_from_blob(const u_char *, size_t, struct sshkey **); int sshkey_fromb(struct sshbuf *, struct sshkey **); Thanks, Nuno From andrei650816 at gmail.com Mon Feb 13 17:12:11 2017 From: andrei650816 at gmail.com (Andrey Klimentev) Date: Mon, 13 Feb 2017 09:12:11 +0300 Subject: Logfile encoding question Message-ID: Hello. I've got a question about encoding in sshd's log files. When I try to log in with a "?" username, which is a cyrillic "h" (U+0445), I get this message in a logfile: input_userauth_request: invalid user \\321\\205 [preauth]. I am struggling to understand: is that hex, is that octal? It doesn't map to any encoding that I know of. From dtucker at zip.com.au Mon Feb 13 17:29:29 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 13 Feb 2017 17:29:29 +1100 Subject: Logfile encoding question In-Reply-To: References: Message-ID: On Mon, Feb 13, 2017 at 5:12 PM, Andrey Klimentev wrote: > Hello. > > I've got a question about encoding in sshd's log files. > > When I try to log in with a "?" username, which is a cyrillic "h" (U+0445), > I get this message in a logfile: input_userauth_request: invalid user > \\321\\205 [preauth]. I'ts run through strnvis[1] with some options with different options depending on whether it's going to syslog or stderr, but both include VIS_OCTAL so that should be what anything unusual ends up as. That said, assuming what you posted is exactly what it logged, it looks to me as if it was sent the literal string "\321\205" and sshd just escaped the backslashes. Are you sure the client is sending what you think it's sending? In log.c: #define LOG_SYSLOG_VIS (VIS_CSTYLE|VIS_NL|VIS_TAB|VIS_OCTAL) #define LOG_STDERR_VIS (VIS_SAFE|VIS_OCTAL) [...] strnvis(fmtbuf, msgbuf, sizeof(fmtbuf), log_on_stderr ? LOG_STDERR_VIS : LOG_SYSLOG_VIS); [1] http://man.openbsd.org/OpenBSD-current/man3/vis.3 -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Feb 13 19:02:12 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 13 Feb 2017 19:02:12 +1100 Subject: Logfile encoding question In-Reply-To: References: Message-ID: (re-adding openssh-unix-dev) On Mon, Feb 13, 2017 at 6:18 PM, Andrey Klimentev wrote: > Thank you for a quick response. > > Indeed, it looks like the OpenSSH client sends it as a string: debug1: > Authenticating to jump1-m.vt.ru:22 as '\321\205' Well that's also passed through the same escaping in log.c. > PAM module has no problem with interpreting that value, though. Here is a > full auth.log: > > Feb 13 09:01:02 jump1 sshd[31722]: Invalid user \321\205 from 192.168.54.109 This one is encoded as expected. > Feb 13 09:01:02 jump1 sshd[31722]: input_userauth_request: invalid user > \\321\\205 [preauth] This one is double encoded for some reason. What version of sshd are you using? > Feb 13 09:01:06 jump1 sshd[31722]: Failed password for invalid user \321\205 > from 192.168.54.109 port 43826 ssh2 This one is also as expected. Anyway, that value is $ perl -le 'printf "%x %x\n", 0321, 0205' d1 85 which seems to be the UTF8 encoding of U+0445: http://www.fileformat.info/info/unicode/char/0445/index.htm > Naturally, the question now arises: how does a client encode it and why does > PAM correctly decode it and write it to the syslog properly? With the exception of one instance of double-encoding in the logging, it seems to be doing what you'd expect. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From andrei650816 at gmail.com Mon Feb 13 19:24:04 2017 From: andrei650816 at gmail.com (Andrey Klimentev) Date: Mon, 13 Feb 2017 11:24:04 +0300 Subject: Logfile encoding question In-Reply-To: References: Message-ID: (re-added openssh-unix-dev) Oh god, I forgot that UTF-8 is encoded with multiple bytes. My sincerest apologies! I use OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013, if logfile double encoding is a real problem for OpenSSH developers. My question is fully answered. Thanks! 2017-02-13 11:02 GMT+03:00 Darren Tucker : > (re-adding openssh-unix-dev) > > On Mon, Feb 13, 2017 at 6:18 PM, Andrey Klimentev > wrote: > > Thank you for a quick response. > > > > Indeed, it looks like the OpenSSH client sends it as a string: debug1: > > Authenticating to jump1-m.vt.ru:22 as '\321\205' > > Well that's also passed through the same escaping in log.c. > > > PAM module has no problem with interpreting that value, though. Here is a > > full auth.log: > > > > Feb 13 09:01:02 jump1 sshd[31722]: Invalid user \321\205 from > 192.168.54.109 > > This one is encoded as expected. > > > Feb 13 09:01:02 jump1 sshd[31722]: input_userauth_request: invalid user > > \\321\\205 [preauth] > > This one is double encoded for some reason. What version of sshd are you > using? > > > Feb 13 09:01:06 jump1 sshd[31722]: Failed password for invalid user > \321\205 > > from 192.168.54.109 port 43826 ssh2 > > This one is also as expected. Anyway, that value is > > $ perl -le 'printf "%x %x\n", 0321, 0205' > d1 85 > > which seems to be the UTF8 encoding of U+0445: > http://www.fileformat.info/info/unicode/char/0445/index.htm > > > Naturally, the question now arises: how does a client encode it and why > does > > PAM correctly decode it and write it to the syslog properly? > > With the exception of one instance of double-encoding in the logging, > it seems to be doing what you'd expect. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > -- ? ?????????, ?????? ??????????. From ebarretto at linux.vnet.ibm.com Tue Feb 14 02:23:25 2017 From: ebarretto at linux.vnet.ibm.com (Eduardo Barretto) Date: Mon, 13 Feb 2017 13:23:25 -0200 Subject: [PATCH] Enable specific ioctl calls for ICA crypto card (s390) Message-ID: <1486999405-10055-1-git-send-email-ebarretto@linux.vnet.ibm.com> This patch enables specific ioctl calls for ICA crypto card on s390 platform. Without this patch, users using the IBMCA engine are not able to perform ssh login as the filter blocks the communication with the crypto card. Signed-off-by: Harald Freudenberger Signed-off-by: Eduardo Barretto --- sandbox-seccomp-filter.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c index 2e1ed2c..264e146 100644 --- a/sandbox-seccomp-filter.c +++ b/sandbox-seccomp-filter.c @@ -59,6 +59,11 @@ #include #include #include +#include + +#ifdef __s390__ +#include +#endif #include "log.h" #include "ssh-sandbox.h" @@ -74,6 +79,13 @@ #endif /* SANDBOX_SECCOMP_FILTER_DEBUG */ /* Simple helpers to avoid manual errors (but larger BPF programs). */ +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define LO_ARG(idx) offsetof(struct seccomp_data, args[(idx)]) +#elif __BYTE_ORDER == __BIG_ENDIAN +#define LO_ARG(idx) offsetof(struct seccomp_data, args[(idx)]) + sizeof(_u32) +#else +#error "Unknown endianness" +#endif #define SC_DENY(_nr, _errno) \ BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_ ## _nr, 0, 1), \ BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ERRNO|(_errno)) @@ -82,9 +94,8 @@ BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW) #define SC_ALLOW_ARG(_nr, _arg_nr, _arg_val) \ BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_ ## _nr, 0, 4), \ - /* load first syscall argument */ \ - BPF_STMT(BPF_LD+BPF_W+BPF_ABS, \ - offsetof(struct seccomp_data, args[(_arg_nr)])), \ + /* load the syscall argument to check into accumulator */ \ + BPF_STMT(BPF_LD+BPF_W+BPF_ABS, LO_ARG(_arg_nr)), \ BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, (_arg_val), 0, 1), \ BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW), \ /* reload syscall number; all rules expect it in accumulator */ \ @@ -207,6 +218,13 @@ static const struct sock_filter preauth_insns[] = { #ifdef __NR_socketcall SC_ALLOW_ARG(socketcall, 0, SYS_SHUTDOWN), #endif +#ifdef __NR_ioctl +#ifdef __s390__ + SC_ALLOW_ARG(ioctl, 1, Z90STAT_STATUS_MASK), + SC_ALLOW_ARG(ioctl, 1, ICARSAMODEXPO), + SC_ALLOW_ARG(ioctl, 1, ICARSACRT), +#endif +#endif /* Default deny */ BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL), -- 1.9.1 From djm at mindrot.org Tue Feb 14 19:03:55 2017 From: djm at mindrot.org (Damien Miller) Date: Tue, 14 Feb 2017 19:03:55 +1100 (AEDT) Subject: better seccomp sandbox syscall argument checking Message-ID: Hi, seccomp syscall args are always passed as 64 bit integers, regardless of architecture. At the moment, we only inspect the low word. It's conceivable that this could be used to evade sandbox restrictions on syscall argumements, but we only permit a single syscall (socketcall) with argument inspection. Anyway, we should fix it. Can someone run their eyes over my amateur bpf? This also fixes argument inspection on 64-bit BE architectures. -d diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c index 2e1ed2c5..c3f8daa3 100644 --- a/sandbox-seccomp-filter.c +++ b/sandbox-seccomp-filter.c @@ -73,6 +73,16 @@ # define SECCOMP_FILTER_FAIL SECCOMP_RET_TRAP #endif /* SANDBOX_SECCOMP_FILTER_DEBUG */ +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define ARG_LO_OFFSET 0 +#define ARG_HI_OFFSET sizeof(uint32_t) +#elif __BYTE_ORDER == __BIG_ENDIAN +#define ARG_LO_OFFSET sizeof(uint32_t) +#define ARG_HI_OFFSET 0 +#else +#error "Unknown endianness" +#endif + /* Simple helpers to avoid manual errors (but larger BPF programs). */ #define SC_DENY(_nr, _errno) \ BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_ ## _nr, 0, 1), \ @@ -81,10 +91,14 @@ BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_ ## _nr, 0, 1), \ BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW) #define SC_ALLOW_ARG(_nr, _arg_nr, _arg_val) \ - BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_ ## _nr, 0, 4), \ + BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_ ## _nr, 0, 6), \ + /* verify high word of syscall argument is zero */ \ + BPF_STMT(BPF_LD+BPF_W+BPF_ABS, \ + ARG_HI_OFFSET + offsetof(struct seccomp_data, args[(_arg_nr)])), \ + BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0, 0, 4), \ /* load first syscall argument */ \ BPF_STMT(BPF_LD+BPF_W+BPF_ABS, \ - offsetof(struct seccomp_data, args[(_arg_nr)])), \ + ARG_LO_OFFSET + offsetof(struct seccomp_data, args[(_arg_nr)])), \ BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, (_arg_val), 0, 1), \ BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW), \ /* reload syscall number; all rules expect it in accumulator */ \ From alexis.horgix.chotard at gmail.com Wed Feb 15 03:38:17 2017 From: alexis.horgix.chotard at gmail.com (Alexis Horgix Chotard) Date: Tue, 14 Feb 2017 17:38:17 +0100 Subject: [Doc] Extension of Included configuration files In-Reply-To: References: Message-ID: Hello, 2017-02-07 22:55 GMT+01:00 Alexis Horgix Chotard : > I would like to include a SHOULD part to the man section of the > Include directive in an effort to make those included files > recognizable. > I'm sure you'll have a better suggestion for the wording than me; > however you'll find a patch attached [...] > > Let me know what you think about it, Any opinion on that ? See my precedent email for details. Regards, -- Alexis 'Horgix' Chotard From jjelen at redhat.com Wed Feb 15 19:50:50 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Wed, 15 Feb 2017 09:50:50 +0100 Subject: [Doc] Extension of Included configuration files In-Reply-To: References: Message-ID: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> On 02/07/2017 10:55 PM, Alexis Horgix Chotard wrote: > Hello, > > I'm really happy that the 7.3 release of OpenSSH introduced the > Include directive. > > However, since there is absolutely no restriction or advice neither on > the name nor on the location of the included files, it makes it harder > for external tools to recognize them; I'm mainly thinking about text > editors that would like to enable syntax coloration for it ( > https://github.com/vim/vim/pull/1452 ). > Until now it wasn't a problem since the file was either `ssh_config` > or `~/.ssh/config` in most cases - maybe all ? no idea if this is > configurable. > > I would like to include a SHOULD part to the man section of the > Include directive in an effort to make those included files > recognizable. > I'm sure you'll have a better suggestion for the wording than me; > however you'll find a patch attached for the sentence "Configuration > file(s) referenced by this Include directive should use the .sshconfig > extension to be detected as such by external tools." but it could also > be something simpler like "If you want external tools to detect your > configuration files, they should use the .sshconfig extension". > > Let me know what you think about it, This is very strict condition. For the tools, I would rather have a look at the full path (if it is possible), because in most of the cases, the files should come under /etc/ssh/ssh_config.d/* Having this path automatically included by default in shipped configuration files from OpenSSH upstream would be nice. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From kdunlop at guralp.com Wed Feb 15 21:50:13 2017 From: kdunlop at guralp.com (Kelly Dunlop) Date: Wed, 15 Feb 2017 10:50:13 +0000 Subject: Issue with ssh-keygen Message-ID: <20170215105013.GA25523@guralp.com> Hi, I am running openssh7.3p1 on an embedded Linux system and discovered this problem. If I run: ssh-keygen -t rsa1 -f testfile it appears to generate the key and I get the output: Generating public/private rsa1 key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Saving key "testfile" failed: unknown or unsupported key type Should this option be returning with a deprecated key type message ? I can't find a bug already reported about this and I have downloaded openssh 7.4p1 and the problem exists on that too. I have checked the archives at http://marc.info/ and there didn't appear to be anything there. Apologies if this has apready been discussed as I am not on the mailing list. Thanks in advance for any pointers Kelly -- Kelly Dunlop kdunlop at guralp.com Guralp Systems Limited http://www.guralp.com From dtucker at zip.com.au Fri Feb 17 09:28:52 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 17 Feb 2017 09:28:52 +1100 Subject: Issue with ssh-keygen In-Reply-To: References: <20170215105013.GA25523@guralp.com> Message-ID: On Fri, Feb 17, 2017 at 9:25 AM, Darren Tucker wrote: > git bisect points at > > 2aa9da1a3b360cf7b13e96fe1521534b91501fb5 is the first bad commit ... and if I'd actually looked at the change itself: - [ --without-ssh1 Disable support for SSH protocol 1], + [ --with-ssh1 Enable support for SSH protocol 1], so yeah, ssh-keygen should have probably errored out "unsupported key type". -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Feb 17 09:25:45 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 17 Feb 2017 09:25:45 +1100 Subject: Issue with ssh-keygen In-Reply-To: <20170215105013.GA25523@guralp.com> References: <20170215105013.GA25523@guralp.com> Message-ID: On Wed, Feb 15, 2017 at 9:50 PM, Kelly Dunlop wrote: > > > Hi, > > I am running openssh7.3p1 on an embedded Linux system and discovered this problem. > > If I run: > > ssh-keygen -t rsa1 -f testfile > > it appears to generate the key and I get the output: > > Generating public/private rsa1 key pair. > Enter passphrase (empty for no passphrase): > Enter same passphrase again: > Saving key "testfile" failed: unknown or unsupported key type > > Should this option be returning with a deprecated key type message ? It looks like a bug. git bisect points at 2aa9da1a3b360cf7b13e96fe1521534b91501fb5 is the first bad commit commit 2aa9da1a3b360cf7b13e96fe1521534b91501fb5 Author: djm at openbsd.org Date: Tue Mar 24 01:29:19 2015 +0000 upstream commit Compile-time disable SSH protocol 1. You can turn it back on using the Makefile.inc knob if you need it to talk to ancient devices. That said, we're about to remove SSH1 support in the client (it's already gone from the server) so I'm not sure this is is ever going to be fixed... -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Feb 17 09:34:06 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 17 Feb 2017 09:34:06 +1100 Subject: Issue with ssh-keygen In-Reply-To: References: <20170215105013.GA25523@guralp.com> Message-ID: <20170216223406.GA18815@gate.dtucker.net> On Fri, Feb 17, 2017 at 09:28:52AM +1100, Darren Tucker wrote: [...] > so yeah, ssh-keygen should have probably errored out "unsupported key type". diff --git a/sshkey.c b/sshkey.c index 4768790..f45e239 100644 --- a/sshkey.c +++ b/sshkey.c @@ -89,7 +89,9 @@ static const struct keytype keytypes[] = { { "ssh-ed25519-cert-v01 at openssh.com", "ED25519-CERT", KEY_ED25519_CERT, 0, 1 }, #ifdef WITH_OPENSSL +# ifdef WITH_SSH1 { NULL, "RSA1", KEY_RSA1, 0, 0 }, +# endif { "ssh-rsa", "RSA", KEY_RSA, 0, 0 }, { "ssh-dss", "DSA", KEY_DSA, 0, 0 }, # ifdef OPENSSL_HAS_ECC -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Feb 17 13:39:06 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 17 Feb 2017 13:39:06 +1100 Subject: Issue with ssh-keygen In-Reply-To: <20170216223406.GA18815@gate.dtucker.net> References: <20170215105013.GA25523@guralp.com> <20170216223406.GA18815@gate.dtucker.net> Message-ID: On Fri, Feb 17, 2017 at 9:34 AM, Darren Tucker wrote: > On Fri, Feb 17, 2017 at 09:28:52AM +1100, Darren Tucker wrote: > [...] >> so yeah, ssh-keygen should have probably errored out "unsupported key type". I've just committed this patch and a similar one to fix the usage text in this case. It'll be in the next release (which according to the current plan will likely be the last one to have SSH1 client support. Thanks for the report. $ ssh-keygen -t rsa1 unknown key type rsa1 $ ssh-keygen -? usage: ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa] -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kdunlop at guralp.com Fri Feb 17 23:12:33 2017 From: kdunlop at guralp.com (Kelly Dunlop) Date: Fri, 17 Feb 2017 12:12:33 +0000 Subject: Issue with ssh-keygen In-Reply-To: References: <20170215105013.GA25523@guralp.com> <20170216223406.GA18815@gate.dtucker.net> Message-ID: <20170217121233.GA1352@guralp.com> On Fri, Feb 17, 2017 at 01:39:06PM +1100, Darren Tucker wrote: > On Fri, Feb 17, 2017 at 9:34 AM, Darren Tucker wrote: > > On Fri, Feb 17, 2017 at 09:28:52AM +1100, Darren Tucker wrote: > > [...] > >> so yeah, ssh-keygen should have probably errored out "unsupported key type". > > I've just committed this patch and a similar one to fix the usage text > in this case. It'll be in the next release (which according to the > current plan will likely be the last one to have SSH1 client support. > > Thanks for the report. Thanks for confirming that I hadn't misinterpreted something. Thanks for the fix too although as you say time is short for SSH1 support. Kelly > > $ ssh-keygen -t rsa1 > unknown key type rsa1 > > $ ssh-keygen -? > usage: ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa] > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. -- Kelly Dunlop kdunlop at guralp.com Guralp Systems Limited http://www.guralp.com From jjelen at redhat.com Sat Feb 18 03:18:55 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Fri, 17 Feb 2017 17:18:55 +0100 Subject: Fwd: Server accepts key: pkalg rsa-sha2-512 vs ssh-rsa In-Reply-To: References: <53cb818d-e72e-78fe-7216-c1a56ef73f6f@redhat.com> <09db41ea-636c-2ec5-93e6-fe72d75aa0c7@gmail.com> Message-ID: <41ff0db3-e41e-b6d8-6ec0-d332d15a60a6@redhat.com> On 02/12/2017 03:46 PM, Nuno Gon?alves wrote: > On 1/30/2017 3:58 AM, Jakub Jelen wrote: >> This is part of deprecation SHA1 for signatures, which were hardcoded into the core RFCs. The different hashes were introduced in OpenSSH 7.2 [1] and are negotiated using the protocol extension. I >> don't think there are configuration options to control this behavior, but the new algorithms have higher priority for new OpenSSH versions. >> >> [1] http://www.openssh.com/txt/release-7.2 >> >> Regards, > > In that case this is converted to a bug report: Deprecation of SHA1 is > not being enforced since 7.4p1. Hello. Thank you for wide investigation. I filled a bug #2680 [1] to get it more attention. This is something we would really like to see fixed and the patch passed probably unseen by the developers. Damien, Darren, can we get it fixed? Thanks, -- Jakub Jelen Software Engineer Security Technologies Red Hat [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2680 From sudarshan12s at gmail.com Tue Feb 21 04:19:04 2017 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Mon, 20 Feb 2017 22:49:04 +0530 Subject: second ssh connection for the first ssh request Message-ID: Hi I changed sshd_config to run script, .profile for user cliuser like this: Match user cliuser ForceCommand . /home/cliuser/.profile cat /home/cliuser/.profile #!/bin/sh if [[ "$1" == "-c" ]]; then exit 5 fi trap 'exit' 1 2 3 4 15 ssh -tt secadmin at 127.0.0.1 -p 2024 exit Now, with this, i wanted connections to sshd coming on 2025 to go to 2024 for user cliuser. it works but password is requested on sshd server terminal instead of client window where ssh is done(ssh -vvv cliuser at 172.18.137.11 -p 2025 ). please suggest, i am sharing complete logs, if you see obvious issue. /f0/base/ins_links/current/bin/sshd -ddd -f /home/cliuser/sshd_config -h /f0/etc/ssh/ssh_key -p 2025 debug2: load_server_config: filename /home/cliuser/sshd_config debug2: load_server_config: done config len = 782 debug2: parse_server_config: config /home/cliuser/sshd_config len 782 debug3: /home/cliuser/sshd_config:2 setting Port 22 debug3: /home/cliuser/sshd_config:3 setting Protocol 2 debug3: /home/cliuser/sshd_config:4 setting PubkeyAuthentication no debug3: /home/cliuser/sshd_config:5 setting RhostsRSAAuthentication no debug3: /home/cliuser/sshd_config:6 setting HostbasedAuthentication no debug3: /home/cliuser/sshd_config:7 setting PasswordAuthentication yes debug3: /home/cliuser/sshd_config:8 setting PermitEmptyPasswords yes debug3: /home/cliuser/sshd_config:9 setting ChallengeResponseAuthentication no debug3: /home/cliuser/sshd_config:10 setting AllowTcpForwarding yes debug3: /home/cliuser/sshd_config:11 setting UsePrivilegeSeparation no debug3: /home/cliuser/sshd_config:12 setting PidFile /tmp/sshd.pid debug3: /home/cliuser/sshd_config:13 setting TCPKeepAlive yes debug3: /home/cliuser/sshd_config:14 setting ClientAliveInterval 600 debug3: /home/cliuser/sshd_config:15 setting ClientAliveCountMax 3 debug3: /home/cliuser/sshd_config:16 setting MaxStartups 25 debug3: /home/cliuser/sshd_config:17 setting GatewayPorts no debug3: /home/cliuser/sshd_config:18 setting X11Forwarding no debug3: /home/cliuser/sshd_config:19 setting AllowAgentForwarding no debug3: /home/cliuser/sshd_config:20 setting PermitTunnel no debug3: /home/cliuser/sshd_config:21 setting AllowUsers root acli guest tl1telnet tl1tcp xml telnetrelay cliuser debug3: /home/cliuser/sshd_config:22 setting IgnoreRhosts yes debug3: checking syntax for 'Match user tl1telnet' debug3: checking syntax for 'Match user tl1tcp' debug3: checking syntax for 'Match user telnetrelay' debug3: checking syntax for 'Match user xml' debug3: checking syntax for 'Match user cliuser' debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1h 5 Jun 2014 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 "/f0/etc/ssh/ssh_key" as a RSA1 public key debug1: private host key: #0 type 1 RSA debug1: rexec_argv[0]='/f0/base/ins_links/current/bin/sshd' debug1: rexec_argv[1]='-ddd' debug1: rexec_argv[2]='-f' debug1: rexec_argv[3]='/home/cliuser/sshd_config' debug1: rexec_argv[4]='-h' debug1: rexec_argv[5]='/f0/etc/ssh/ssh_key' debug1: rexec_argv[6]='-p' debug1: rexec_argv[7]='2025' debug3: oom_adjust_setup Set /proc/self/oom_score_adj from 0 to -1000 debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2025 on 0.0.0.0. Server listening on 0.0.0.0 port 2025. debug2: fd 4 setting O_NONBLOCK debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Bind to port 2025 on ::. Server listening on :: port 2025. debug3: fd 5 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 782 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 10.220.82.17 port 36633 on 172.18.137.11 port 2025 debug1: Client protocol version 2.0; client software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6 debug2: fd 3 setting O_NONBLOCK debug1: list_hostkey_types: ssh-rsa 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-rsa 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 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-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,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-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: mac_setup: setup hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug2: mac_setup: setup hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received WARNING: /usr/local/etc/moduli does not exist, using fixed modulus debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: bits set: 1046/2048 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: bits set: 998/2048 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user cliuser service ssh-connection method none debug1: attempt 0 failures 0 debug3: Trying to reverse map address 10.220.82.17. debug2: parse_server_config: config reprocess config len 782 debug3: checking match for 'user tl1telnet' user cliuser host 10.220.82.17 addr 10.220.82.17 laddr 172.18.137.11 lport 2025 debug3: match not found debug3: checking match for 'user tl1tcp' user cliuser host 10.220.82.17 addr 10.220.82.17 laddr 172.18.137.11 lport 2025 debug3: match not found debug3: checking match for 'user telnetrelay' user cliuser host 10.220.82.17 addr 10.220.82.17 laddr 172.18.137.11 lport 2025 debug3: match not found debug3: checking match for 'user xml' user cliuser host 10.220.82.17 addr 10.220.82.17 laddr 172.18.137.11 lport 2025 debug3: match not found debug3: checking match for 'user cliuser' user cliuser host 10.220.82.17 addr 10.220.82.17 laddr 172.18.137.11 lport 2025 debug1: user cliuser matched 'User cliuser' at line 32 debug3: match found debug3: reprocess config:33 setting ForceCommand . /home/cliuser/.profile debug2: input_userauth_request: setting up authctxt for cliuser debug2: input_userauth_request: try method none Could not get shadow information for cliuser Accepted none for cliuser from 10.220.82.17 port 36633 ssh2 debug1: Entering interactive session for SSH2. debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/1 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 shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell Starting session: forced-command (config) '. /home/cliuser/.profile' on pts/1 for cliuser from 10.220.82.17 port 36633 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: channel 0: rfd 8 isatty debug2: fd 8 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK secadmin at 127.0.0.1's password: client logs: ssh -vvv cliuser at 172.18.137.11 -p 2025 OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 172.18.137.11 [172.18.137.11] port 2025. debug1: Connection established. debug1: identity file /home/ssoma/.ssh/identity type -1 debug1: identity file /home/ssoma/.ssh/identity-cert type -1 debug1: identity file /home/ssoma/.ssh/id_rsa type -1 debug1: identity file /home/ssoma/.ssh/id_rsa-cert type -1 debug1: identity file /home/ssoma/.ssh/id_dsa type -1 debug1: identity file /home/ssoma/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6 debug1: match: OpenSSH_6.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug3: Wrote 960 bytes for a total of 981 debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-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,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-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 ,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-rsa 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 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug3: Wrote 24 bytes for a total of 1005 debug2: dh_gen_key: priv key bits set: 133/256 debug2: bits set: 998/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: Wrote 272 bytes for a total of 1277 debug3: put_host_port: [172.18.137.11]:2025 debug3: put_host_port: [172.18.137.11]:2025 debug3: check_host_in_hostfile: host [172.18.137.11]:2025 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [172.18.137.11]:2025 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: match line 127 debug3: check_host_in_hostfile: host [172.18.137.11]:2025 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: host [172.18.137.11]:2025 filename /home/ssoma/.ssh/known_hosts debug3: check_host_in_hostfile: match line 127 debug1: Host '[172.18.137.11]:2025' is known and matches the RSA host key. debug1: Found key in /home/ssoma/.ssh/known_hosts:127 debug2: bits set: 1046/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: Wrote 16 bytes for a total of 1293 debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug3: Wrote 48 bytes for a total of 1341 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/ssoma/.ssh/identity ((nil)) debug2: key: /home/ssoma/.ssh/id_rsa ((nil)) debug2: key: /home/ssoma/.ssh/id_dsa ((nil)) debug3: Wrote 64 bytes for a total of 1405 debug1: Authentication succeeded (none). 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. debug3: Wrote 128 bytes for a total of 1533 debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug3: Ignored env CCACHE_NOSTATS debug3: Ignored env HOSTNAME debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env HISTSIZE debug3: Ignored env SSH_CLIENT debug3: Ignored env CCACHE_LOGFILE debug3: Ignored env QTDIR debug3: Ignored env QTINC debug3: Ignored env SSH_TTY debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env CSCOPE_EDITOR debug3: Ignored env COVLM debug3: Ignored env MAIL debug3: Ignored env PATH debug3: Ignored env PWD debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env MODULEPATH debug3: Ignored env LOADEDMODULES debug3: Ignored env P4CLIENT debug3: Ignored env SSH_ASKPASS debug3: Ignored env HISTCONTROL debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env QTLIB debug3: Ignored env CVS_RSH debug3: Ignored env SSH_CONNECTION debug3: Ignored env MODULESHOME debug3: Ignored env LESSOPEN debug3: Ignored env P4PORT debug3: Ignored env G_BROKEN_FILENAMES debug3: Ignored env BASH_FUNC_module() debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: Wrote 448 bytes for a total of 1981 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory debug1: permanently_set_uid: 1100/0 Environment: USER=cliuser LOGNAME=cliuser HOME=/home/cliuser PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin MAIL=/var/mail/cliuser SHELL=/bin/sh SSH_CLIENT=10.220.82.17 36633 2025 SSH_CONNECTION=10.220.82.17 36633 172.18.137.11 2025 SSH_TTY=/dev/pts/1 TERM=xterm From dtucker at zip.com.au Tue Feb 21 09:09:02 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 21 Feb 2017 09:09:02 +1100 Subject: second ssh connection for the first ssh request In-Reply-To: References: Message-ID: On Tue, Feb 21, 2017 at 4:19 AM, Sudarshan Soma wrote: > Hi I changed sshd_config to run script, .profile for user cliuser like What platform is this on? If it's Solaris, try commenting out SSHD_ACQUIRES_CTTY from config.h and recompiling. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From sudarshan12s at gmail.com Tue Feb 21 17:17:25 2017 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Tue, 21 Feb 2017 11:47:25 +0530 Subject: second ssh connection for the first ssh request In-Reply-To: References: Message-ID: sorry , It is linux OS. uname -a -> 3.10.40.cge-rt38 #1 SMP Fri Jul 22 12:59:33 PDT 2016 i686 GNU/Linux On Tue, Feb 21, 2017 at 11:46 AM, Sudarshan Soma wrote: > Hi Darren, It is linux > > > 3.10.40.cge-rt38 #1 SMP Fri Jul 22 12:59:33 PDT 2016 i686 GNU/Linux > > > On Tue, Feb 21, 2017 at 3:39 AM, Darren Tucker wrote: > >> On Tue, Feb 21, 2017 at 4:19 AM, Sudarshan Soma >> wrote: >> > Hi I changed sshd_config to run script, .profile for user cliuser like >> >> What platform is this on? If it's Solaris, try commenting out >> SSHD_ACQUIRES_CTTY from config.h and recompiling. >> >> -- >> Darren Tucker (dtucker at zip.com.au) >> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA >> (new) >> Good judgement comes with experience. Unfortunately, the experience >> usually comes from bad judgement. >> > > From sudarshan12s at gmail.com Tue Feb 21 17:16:47 2017 From: sudarshan12s at gmail.com (Sudarshan Soma) Date: Tue, 21 Feb 2017 11:46:47 +0530 Subject: second ssh connection for the first ssh request In-Reply-To: References: Message-ID: Hi Darren, It is linux 3.10.40.cge-rt38 #1 SMP Fri Jul 22 12:59:33 PDT 2016 i686 GNU/Linux On Tue, Feb 21, 2017 at 3:39 AM, Darren Tucker wrote: > On Tue, Feb 21, 2017 at 4:19 AM, Sudarshan Soma > wrote: > > Hi I changed sshd_config to run script, .profile for user cliuser like > > What platform is this on? If it's Solaris, try commenting out > SSHD_ACQUIRES_CTTY from config.h and recompiling. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From Vincent.LEFEVERE at hei.fr Thu Feb 23 00:32:03 2017 From: Vincent.LEFEVERE at hei.fr (Vincent LEFEVERE) Date: Wed, 22 Feb 2017 13:32:03 +0000 Subject: log port forwarding Message-ID: Hello No reply to my mail since two week ! Nobody read it ? I send you again the patch. If you do not fully understand my english You could read the patch to understand which fonctionnality I would like to be include in the ssh deamon. Best regards Vincent Lefevere De : Vincent LEFEVERE Envoy? : jeudi 9 f?vrier 2017 21:10 ? : 'openssh-unix-dev at mindrot.org' Objet : RE: log port forwarding Hello, Not receiving a reply to the previous mail about logging port forwarding in the ssh daemon, let me explain the reason for this need. It is a question of using a machine as a bastion to isolate two networks and at the same time allow connections between these two networks via ssh tunnels. For security reasons, it is necessary to keep track of each tunnel associated with the login used in a log. It is of course necessary to set the user's shell to / bin / cat or an equivalent command so that the user can not run another solution to create tunnels. The patch that I have previously suggested logs in syslog every outgoing or dynamic tunnel. But it does not log the incoming tunnels. What can be judged insufficient! Using the variables displayed in debug, I discovered another problem: the address and port of the origin of the tunnels are always 0.0.0.0:0 This does not make it easy to link information between a firewall that logged an attack and the tunnel used by the attack (and the associated login). So, I corrected this with a new patch attached. (I tested it with IPv4 and IPv6 tunnels on Linux.) Could you tell me if you agree to integrate the feature (using or not the patch I gave you)? Thank you Best regards Vincent Lefevere -------------- next part -------------- A non-text attachment was scrubbed... Name: log_port_forwarding3.patch.gz Type: application/x-gzip Size: 2236 bytes Desc: log_port_forwarding3.patch.gz URL: From guettliml at thomas-guettler.de Fri Feb 24 21:13:06 2017 From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=) Date: Fri, 24 Feb 2017 11:13:06 +0100 Subject: [SUSPECTED SPAM] Canonical Link to Reference of "ServerAliveInterval" Message-ID: <9f85e47a-e8db-8f09-edc6-152d4a45dfcc@thomas-guettler.de> What is the canonical link to Reference of "ServerAliveInterval"? Background: I want to write an answer at serverfault (Q-A Site). I want to avoid copy+pasting. I would like to lead the new comer to the canonical reference. Regards, Thomas G?ttler -- Thomas Guettler http://www.thomas-guettler.de/ From dtucker at zip.com.au Fri Feb 24 22:04:31 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 24 Feb 2017 22:04:31 +1100 Subject: [SUSPECTED SPAM] Canonical Link to Reference of "ServerAliveInterval" In-Reply-To: <9f85e47a-e8db-8f09-edc6-152d4a45dfcc@thomas-guettler.de> References: <9f85e47a-e8db-8f09-edc6-152d4a45dfcc@thomas-guettler.de> Message-ID: On Feb 24, 2017 9:18 PM, "Thomas G?ttler" wrote: What is the canonical link to Reference of "ServerAliveInterval"? http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5 From michaelkintzios at gmail.com Sat Feb 25 21:59:43 2017 From: michaelkintzios at gmail.com (Mick) Date: Sat, 25 Feb 2017 10:59:43 +0000 Subject: Server authentication none fails to connect Message-ID: <2023154.3cG9E48Y5K@dell_xps> Hi All, I am trying to understand why openssh client started failing to establish a connection. The client is running on Mint Linux and was able to connect to this server until recently without problems. Now when it tries to connect (using sftp), it fails like so: $ sftp -v user_name at host_name.netsolhost.com:/ OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016 [snip ...] debug1: Host 'account_name.netsolhost.com' is known and matches the RSA host key. debug1: Found key in /home/mick/.ssh/known_hosts:1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS received debug1: Authentication succeeded (none). Authenticated to account_name.netsolhost.com ([206.188.193.57]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: pledge: network debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK Connection to account_name.netsolhost.com closed by remote host. Transferred: sent 1560, received 1992 bytes, in 0.0 seconds Bytes per second: sent 18334897.2, received 23412253.3 debug1: Exit status -1 Couldn't read packet: Connection reset by peer What is the meaning of the message: "Authentication succeeded (none)."? Shouldn't the server respond with a list of authentication method names, and authentications that can continue, including as in the past "password"? -- Regards, Mick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: This is a digitally signed message part. URL: From michaelkintzios at gmail.com Sat Feb 25 22:33:18 2017 From: michaelkintzios at gmail.com (Mick) Date: Sat, 25 Feb 2017 11:33:18 +0000 Subject: Server authentication none fails to connect In-Reply-To: <2023154.3cG9E48Y5K@dell_xps> References: <2023154.3cG9E48Y5K@dell_xps> Message-ID: <27560101.VKHZSG5Dgb@dell_xps> On Saturday 25 Feb 2017 10:59:43 Mick wrote: > Hi All, > > I am trying to understand why openssh client started failing to establish a > connection. The client is running on Mint Linux and was able to connect to > this server until recently without problems. Now when it tries to connect > (using sftp), it fails like so: > > $ sftp -v user_name at host_name.netsolhost.com:/ > OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016 > [snip ...] > > debug1: Host 'account_name.netsolhost.com' is known and matches the RSA host > key. > debug1: Found key in /home/mick/.ssh/known_hosts:1 > debug1: rekey after 4294967296 blocks > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: rekey after 4294967296 blocks > debug1: SSH2_MSG_NEWKEYS received > debug1: Authentication succeeded (none). > Authenticated to account_name.netsolhost.com ([206.188.193.57]:22). > debug1: channel 0: new [client-session] > debug1: Entering interactive session. > debug1: pledge: network > debug1: channel 0: free: client-session, nchannels 1 > debug1: fd 0 clearing O_NONBLOCK > Connection to account_name.netsolhost.com closed by remote host. > Transferred: sent 1560, received 1992 bytes, in 0.0 seconds > Bytes per second: sent 18334897.2, received 23412253.3 > debug1: Exit status -1 > Couldn't read packet: Connection reset by peer > > > What is the meaning of the message: "Authentication succeeded (none)."? > > Shouldn't the server respond with a list of authentication method names, and > authentications that can continue, including as in the past "password"? Only to add: a connection from the same PC with Filezilla succeeds as it always has done, but I am guessing Filezilla perhaps ships with a different ssh client. -- Regards, Mick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: This is a digitally signed message part. URL: From guettliml at thomas-guettler.de Tue Feb 28 03:09:12 2017 From: guettliml at thomas-guettler.de (=?UTF-8?Q?Thomas_G=c3=bcttler?=) Date: Mon, 27 Feb 2017 17:09:12 +0100 Subject: Canonical Link to Reference of "ServerAliveInterval" In-Reply-To: References: <9f85e47a-e8db-8f09-edc6-152d4a45dfcc@thomas-guettler.de> <3b800282-b35c-bec7-1c49-0303e4927fec@thomas-guettler.de> Message-ID: Am 27.02.2017 um 06:41 schrieb Darren Tucker: > On Mon, Feb 27, 2017 at 8:32 AM, Thomas G?ttler > wrote: >> It would be very nice if you could create a link to the specific keyword. >> >> For example >> http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#ServerAliveInterval >> >> How does this page get created? > > It's generated on the fly from the mandoc source of the OpenBSD man > page by http://man.openbsd.org/cgi-bin/man.cgi (which is part of the > mandoc package: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/). > > It already uses HTML anchors for section links (eg > http://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#PATTERNS) > though, so I doubt anyone would be interested in special cases for ssh > pages. HTML anchors don't cost money. They don't disturb the human eye, since they are invisible. Yes, you are right. Hacking mandoc for ssh custom stuff is no good idea. The HTML looks roughly like this:
ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server.
AFAIK, this would be enough to make canonical and direct links work:
ServerAliveInterval
mandoc seems to understand that this is a glossary like listing. Maybe there is a generic solution possible... which means no dirty hacking in mandoc for ssh. What do you think? Regards, Thomas G?ttler -- Thomas Guettler http://www.thomas-guettler.de/ From Spike.White at dell.com Tue Feb 28 10:08:51 2017 From: Spike.White at dell.com (Spike.White at dell.com) Date: Mon, 27 Feb 2017 23:08:51 +0000 Subject: How to successfully run pam_limits with sshd privilege separation disabled? Message-ID: <94f9e77257134e8d85b5e4fd3e8a2bb1@AUSX13MPC108.AMER.DELL.COM> Dell - Internal Use - Confidential All, I see OpenSSH 7.4 was released in Dec, 2016. Reading the release notes, I see this comment: Future deprecation notice ========================= We plan on retiring more legacy cryptography in future releases, specifically: ... * The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled. ... This list reflects our current intentions, but please check the final release notes for future releases. Here's my question. How can you successfully run pam_limits.so with sshd privilege separation? It's very common for the administrative account on Linux-based apps to bump up limit settings. Such as "nofiles", for applications that get a lot of concurrent client connections. Here's an example /etc/pam.d/limits.conf file: oracle hard memlock unlimited oracle soft memlock unlimited # processoemagent setting for nofile hard and soft limit is 4096 processoemagent hard nofile 4096 processoemagent soft nofile 4096 As you know, only root can upsize the default limits. So without privilege separation, the child sshd process runs as root, upsizes the limits as specified in limits.conf file and then drops down to the specific user. Life is good. Without privilege separation, the child sshd seems to run as the regular user and so upsizing these limits settings seems to fail. Spike