pgienger

I am connecting to a CentOS 7 system, pretty standard config. Here's the log from a failure:

[5/15/2019 9:57:03 AM] Setting up connection

[5/15/2019 9:57:03 AM] Connecting as paugie

[5/15/2019 9:57:03 AM] SSH banner: SSH-2.0-OpenSSH_7.4

[5/15/2019 9:57:03 AM] Sending kex init

[5/15/2019 9:57:03 AM] Received kex init

[5/15/2019 9:57:03 AM] Selected algorithms: curve25519-sha256, ssh-ed25519, chacha20-poly1305@openssh.com, chacha20-poly1305@openssh.com, implicit by cipher, implicit by cipher, none, none

[5/15/2019 9:57:03 AM] Sending Ed25519 kex init

[5/15/2019 9:57:03 AM] Received Ed25519 kex reply

[5/15/2019 9:57:03 AM] Successfully authentified server

[5/15/2019 9:57:03 AM] Sending new keys message

[5/15/2019 9:57:03 AM] Sending userauth service request

[5/15/2019 9:57:03 AM] Received new keys message

[5/15/2019 9:57:03 AM] Received service accepted message

[5/15/2019 9:57:03 AM] Sending userauth init request

[5/15/2019 9:57:03 AM] Received userauth failure: publickey,gssapi-keyex,gssapi-with-mic,password

[5/15/2019 9:57:03 AM] No authentication method available

[5/15/2019 9:57:03 AM] The server does not accept interactive authentication

[5/15/2019 9:57:03 AM] Disconnecting

And the 'pertinent' part of the logs from a successful login with the interactive option turned to default:

[5/15/2019 9:59:46 AM] Received userauth failure: publickey,gssapi-keyex,gssapi-with-mic,password

[5/15/2019 9:59:46 AM] Starting password authentication

[5/15/2019 9:59:46 AM] Sending userauth password request

[5/15/2019 9:59:46 AM] Received userauth success

[5/15/2019 9:59:46 AM] User authenticated successfuly by password

[5/15/2019 9:59:46 AM] Sending session channel open request: 0/-

[5/15/2019 9:59:46 AM] Received global request: hostkeys-00@openssh.com , no need to reply

[5/15/2019 9:59:47 AM] Received channel open confirmation: 0/0 WS 200000/0 MPS 32000/32768

[5/15/2019 9:59:47 AM] Sending pty request: 0/0 xterm

[5/15/2019 9:59:47 AM] Received channel success: 0/0

[5/15/2019 9:59:47 AM] Sending environment variable request: 0/0

[5/15/2019 9:59:47 AM] Received channel success: 0/0

[5/15/2019 9:59:47 AM] Empty X display name

[5/15/2019 9:59:47 AM] Cancelling X forwarding

[5/15/2019 9:59:47 AM] Sending shell request: 0/0

[5/15/2019 9:59:47 AM] Received channel success: 0/0

[5/15/2019 9:59:49 AM] Sending channel close request: 0/0

[5/15/2019 9:59:49 AM] Received channel exit signal: 0/0 HUP

[5/15/2019 9:59:49 AM] Received channel close request: 0/0

[5/15/2019 9:59:49 AM] Channel is closed: 0/0

[5/15/2019 9:59:49 AM] Disconnecting

Looks like RDM doesn't like it when SSH key auth fails and it doesn't revert to password auth.

I forgot to actually include the error, I suppose that would help.

The box says (because screenshots are hard):

An unknown SSH error was encountered.

Disconnecting

Today we upgraded our environment to 2019.1.20.0 with the requisite DB upgrades which make downgrade difficult. Now I am unable to launch an SSH session when interactive auth in terminal is set. Unfortunately, that's all of our configured SSH connections, so in order to fix it I would have to go around and reapply the template to a couple hundred connections, for my sub-team anyway.

Please advise if this is a new bug or perhaps an upgrade bug somewhere along the line.

Thanks

A feature we've had many of our pilot users request, and comment about how other programs do it better, is duplicating input to multiple connections. Generally this is related to SSH.

Two methods that are preferred come in other programs -

Method 1 - fully interactive mirroring. In this mode, a "master connection" is selected as well as the "mirrored connections." When a user types in the master, the keys are duplicated live to the other sessions. I don't know the program using this, but I have seen it and it works well.

Method 2 - batch send, with easy continuation. In this mode you start by selecting all of the sessions you are going to send a command to from a persistent command input bar. You type a command as you want it to be in the bar and when you hit enter the command is sent to all the sessions. This is much like the multiple session scripted input in RDM, except that the command bar is always visible so that you can keep entering commands as opposed to the RDM method where you dump in the script and have to go launch the dialog box again. This method can be viewed an a now defunct project called "PuTTY connection manager".

The easy fix would be to make the scripted input box something that can be toggled or docked so that it doesn't have to be sought out for subsequent commands.

Upgraded to 14.0.1

Previously, we had the integration set up as a test, and found it working, but flawed. We were constantly prompted for our 2-factor key while browsing the PleasantPassword folder structure, altering unrelated properties, eventually saving connections, and again on use of the configured connection. It worked, but was really brutal to use.

Now with 14.0.1.0 we are trying again as pleasant was listed as a fix. I can tell that the integration is working because if I create a new entry and uncheck the 'my settings' boxes I am prompted for my 2FA token and the folders work. If I check either or both of the boxes I do not get a folder tree with the ... button and the validate/refresh button prompt with "credentials required". Previously created entries do not work either, I presume because they have the 'my' checkboxes checked.

On second look, it seems that the font/size settings are mangled up any time you go into the connection settings as well, presumably you have to at least hit OK. I purposely stayed away from the terminal tab, only changing the display name, but on launch the font was all wrong.

Using the newest 14.0.0.0 version.

I start with a customized SSH session

-> General -> Terminal -> Display

Colors: Override

Font: Override (Consolas, 8pt)

When I duplicate that connection, oddly enough if I look at the tab, but don't touch anything, the connection is created properly. if I don't check the display tab, the results are not what was in the original connection. In this case, these were the settings:

Font: Override (Agency FB, 10pt)

I can't be sure that is what is in the actual connection, it looks like Times New Roman to me but it's definitely not Consolas. 10pt is probably accurate.

I'd like to throw a 'me too' on the 2FA request. I am running a trial with the newest beta for our team, and while setting up a credential entry and a subsequent connection item I was prompted for my code on select creds, save connection, edit connection, view props on connection, and at least a couple other actions. Once it was created I was prompted, as expected given all the other times, when I tried to use the connection.

Meanwhile I don't have to use the 2FA key on my web browser for another 35 days or so.