Re: A probable useful feature

On Sat, Dec 31, 2011 at 01:40, Vahab Shalchian <v.shalchian <at> gmail.com>wrote:

> Hi,
>
> As I mentioned in the following post :
>
>
> http://www.linuxquestions.org/questions/linux-security-4/exclude-a-from-being-logged-in-var-log-wtmp-920865/
>
> Some monitoring softwares like Manage Engine Application Manager use a
> monitoring user which logins to a servers every 5 minutes via SSH so
> sometimes we need to be able to exclude this user from being recorded to
> wtmp,utmp files.
>
> Is it possible to include this feature in the next releases of SSH.
>
> Many thanks.
> Vahab Shalchian
>

Consider opening an initial connection to each server monitored at the
start of the day/monitoring-cycle using connection mastering - run all your
subsequent connections against the connection master and ?tmp files will
only log the initial connection.  Of course this means the monitoring
system will have a proportional number of open connections/sockets
constantly - so in Very Large Enterprise settings - this 'might not scale
well'.  In smaller deployments the overhead is negligible.  YMMV.

--

-- 
# include <stddisclaimer.h>

ECDSA, SSHFP, and "Error calculating host key fingerprint."

When connecting to a host that provides an ECDSA host key and the
client has "VerifyHostKeyDNS" set to 'yes' or 'ask' SSH outputs a
mysterious and undocumented message "Error calculating host key
fingerprint." This error actually seems to be generated by
verify_host_key_dns(const char *hostname, struct sockaddr *address,
Key *hostkey, int *flags) in dns.c, but neither that fact nor the
reason for the error is mentioned in the manual. Is it possible to
refine the error message so it is more clear what's going on or to
punt and note it in the man pages?

This may become a moot issue when the currently proposed update to RFC
4255[1] gets approved and ECDSA SSHFP records are supported, but for
now it seems like something should provide the user a better
explanation of what's going on and assurance that all is in fact well.

Matthew Roy

[1] https://datatracker.ietf.org/doc/draft-os-ietf-sshfp-ecdsa-sha2/

Interop problem with IPSSH-6.6.0, CR/NL?

I have a curious problem connecting with OpenSSH (5.1p1 on FreeBSD,
6.0-beta on OpenBSD) to some managed switches running "IPSSH-6.6.0".

When I connect to the switch with the SSH2 protocol, I can't use
the switch's CLI, because I can't terminate a command line.  I press
<Enter> and nothing happens.  Same for ^M (CR) and ^J (NL).

When I connect to the switch with SSH1 (or by Telnet or the serial
console port), this doesn't happen.  <Enter> aka ^M successfully
terminates a line.  Interestingly, ^J is ignored.

I *suspect* that for a SSH2 connection, CR is somewhere mapped to
NL, along the lines of the ICRNL termios setting, and NL is then
ignored by the switch.  I don't know if the problem lies with OpenSSH
or the switch--you wouldn't notice this when connecting to a Unix
host.

--

-- 
Christian "naddy" Weisgerber                          naddy <at> mips.inka.de

Re: Interop problem with IPSSH-6.6.0, CR/NL?

Christian Weisgerber wrote:
> I have a curious problem connecting with OpenSSH (5.1p1 on FreeBSD,
> 6.0-beta on OpenBSD) to some managed switches running "IPSSH-6.6.0".

Are you working on the console of FreeBSD and OpenBSD machines?

> I *suspect* that for a SSH2 connection, CR is somewhere mapped to
> NL, along the lines of the ICRNL termios setting, and NL is then
> ignored by the switch.  I don't know if the problem lies with OpenSSH
> or the switch--you wouldn't notice this when connecting to a Unix
> host.

Neither client nor server should be doing any translation. Maybe it's
a terminal problem. Suggest trying with various different client
terminals, on more operating systems.

//Peter

Re: Interop problem with IPSSH-6.6.0, CR/NL?

On Wed, 4 Jan 2012, Christian Weisgerber wrote:

> I have a curious problem connecting with OpenSSH (5.1p1 on FreeBSD,
> 6.0-beta on OpenBSD) to some managed switches running "IPSSH-6.6.0".
> 
> When I connect to the switch with the SSH2 protocol, I can't use
> the switch's CLI, because I can't terminate a command line.  I press
> <Enter> and nothing happens.  Same for ^M (CR) and ^J (NL).
> 
> When I connect to the switch with SSH1 (or by Telnet or the serial
> console port), this doesn't happen.  <Enter> aka ^M successfully
> terminates a line.  Interestingly, ^J is ignored.
> 
> I *suspect* that for a SSH2 connection, CR is somewhere mapped to
> NL, along the lines of the ICRNL termios setting, and NL is then
> ignored by the switch.  I don't know if the problem lies with OpenSSH
> or the switch--you wouldn't notice this when connecting to a Unix
> host.

Could you send a "ssh -vvv" output?

-d

Re: Interop problem with IPSSH-6.6.0, CR/NL?

Damien Miller:

> Could you send a "ssh -vvv" output?

$ ssh -vvv admin <at> sw2
OpenSSH_6.0-beta, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /home/naddy/.ssh/config
debug1: /home/naddy/.ssh/config line 28: Applying options for *
debug2: mac_setup: found umac-64 <at> openssh.com
debug3: mac ok: umac-64 <at> openssh.com [umac-64 <at> openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-md5
debug3: mac ok: hmac-md5 [umac-64 <at> openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-sha1
debug3: mac ok: hmac-sha1 [umac-64 <at> openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-sha2-256
debug3: mac ok: hmac-sha2-256 [umac-64 <at> openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-sha2-512
debug3: mac ok: hmac-sha2-512 [umac-64 <at> openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug2: mac_setup: found hmac-ripemd160
debug3: mac ok: hmac-ripemd160 [umac-64 <at> openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug3: macs ok: [umac-64 <at> openssh.com,hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160]
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to sw2 [172.16.0.252] port 22.
debug1: Connection established.
debug1: identity file /home/naddy/.ssh/id_rsa type -1
debug1: identity file /home/naddy/.ssh/id_rsa-cert type -1
debug1: identity file /home/naddy/.ssh/id_dsa type -1
debug1: identity file /home/naddy/.ssh/id_dsa-cert type -1
debug1: identity file /home/naddy/.ssh/id_ecdsa type -1

Re: Interop problem with IPSSH-6.6.0, CR/NL?

On Thu, 5 Jan 2012, Christian Weisgerber wrote:

> Damien Miller:
> 
> > Could you send a "ssh -vvv" output?
> 
> $ ssh -vvv admin <at> sw2
...
> debug2: channel 0: request pty-req confirm 1
...
> debug2: PTY allocation request accepted on channel 0

So, this isn't like the Netscreen PTY bugs that we discussed here a couple
of months ago. My guess is that your switch is choking on something, but
it is impossible to tell what.

I'd suggest that you try fiddling with ttymodes.h and prune it to the
minimum set of modes that you can. If that works, then you can binary
search to see what is causing the far end to choke.

Do you have any idea what the last version of OpenSSH to interop correctly
with these devices was? Or has it always been broken? :)

-d

Re: Interop problem with IPSSH-6.6.0, CR/NL?

Damien Miller:

> I'd suggest that you try fiddling with ttymodes.h and prune it to the
> minimum set of modes that you can.

It turns out to be... *drum roll*... ICRNL.

Unix TTYs default to ICRNL on, ssh correctly forwards this, and the
PTY code in the switch apparently honors it, mapping CR to NL.  Too
bad the CLI code then just ignores NL.  Why this only happens with
SSH2 but not the SSH1 protocol is a mystery.

A simple "stty -icrnl" before ssh'ing to the switch works around
the problem.

> Do you have any idea what the last version of OpenSSH to interop correctly
> with these devices was? Or has it always been broken? :)

These are TP-Link JetStream switches.  They've only been available
for half a year, and I've had them only for a week. 

--

-- 
Christian "naddy" Weisgerber                          naddy <at> mips.inka.de

Configuration file TCPKeepAlive option does not work reliably

Hi!

There are configuration knobs (TCPKeepAlive) to enable/disable the use of TCP keepalives both in the ssh
client and server. Unfortunately some UNIX systems default to SO_KEEPALIVE=on and some to =off. This may
even be settable on a per host basis (OpenBSD default net.inet.tcp.always_keepalive=1 ???).

For the TCPKeepAlive configuration knob I would like to propose changes along the lines showed in the
attached patch (there is perhaps more elegant ways to do this). The patch will always set SO_KEEPALIVE
according to the ssh configuration files regardless of the local UNIX TCP defaults.

If there are questions or comments I'm available on this email address bg <at> sics.se (I'm not on any ssh email list).

Cheers,
/b

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev <at> mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: Configuration file TCPKeepAlive option does not work reliably

On request from John Hawkinson I'm reposting this with additional information and not relying on attachments.

Hi!

There are configuration knobs (TCPKeepAlive) to enable/disable the use of TCP keepalives both in the ssh
client and server. Unfortunately some UNIX systems default to SO_KEEPALIVE=on and some to =off. This may
even be settable on a per host basis (OpenBSD default net.inet.tcp.always_keepalive=1 ???).

For the TCPKeepAlive configuration knob I would like to propose changes along the lines showed in the
attached patch (there is perhaps more elegant ways to do this). The patch will always set SO_KEEPALIVE
according to the ssh configuration files regardless of the local UNIX TCP defaults.

If there are questions or comments I'm available on this email address bg <at> sics.se (I'm not on any ssh email list).

Additional information comes here:

> You don't explain *why* you propose this change.

I am a mobile user and at all times have a ssh login on a particular machine, TCP keepalives drops the TCP
connection if my laptop is not connected for some 2h.

Therefore, in the server /etc/ssh/sshd_config I have (amongst other things):

TCPKeepAlive no
ClientAliveInterval 90000

This turns off TCP keepalives and enables a ClientAlive probe after 25h of inactivity.

Unfortunately the code implicitly ASSUMES that all systems default to SO_KEEPALIVE=off which is not
true. E.g Free and OpenBSD has sysctls net.inet.tcp.always_keepalive that defaults to