IMC + TAM, not being able to SFTP into switches anymore

[ChrisVanMeer]

Hi,

We've implemented the TAM module for IMC and use a hwtacacs scheme to login to our switches.

Before that, I used to grab the configs of every switch with a bash script on a linux server with pscp (with sftp).

After the implementation of TAM, I am not able to SFTP into the switches anymore. I can SSH into the switches without any problems, but somehow it seems like the user is not allowed to start a SFTP shell.

In TAM I have given the user the highest privilege level, etc. No command restrictions.

Can anyone help me?

Kind regards,

Chris van Meer

[Neelixx]

That is certainly possible, if you did not assign the correct "command sets" to the "authorization policy".  Best way to check is to look at your audit logs and see if TAM is denying any access.

You can also check the TAM logs in $IMC_INSTALL_DIR\tam\log

[ChrisVanMeer]

The command set is Unlimited. The audit logs don't show anything about all of this. The log file on the server isn't modified whenever I try to SFTP into the server. I just tried to login (which failed) but the last TAM log file is from yesterday.

Any other suggestions maybe?

[ChrisVanMeer]

I issued the sftp command with -vvv, this is the debug logging that I get:

debug1: Authentications that can continue: password
debug3: start over, passed a different list password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
<user> password:
debug3: packet_send2: adding 48 (len 62 padlen 18 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to <device>:22).
debug2: fd 4 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug1: Sending environment.
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SSH_TTY
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
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 SHLVL
debug3: Ignored env HOME
debug3: Ignored env LANGUAGE
debug3: Ignored env LOGNAME
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env LESSOPEN
debug3: Ignored env LESSCLOSE
debug3: Ignored env OLDPWD
debug3: Ignored env _
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 131072 rmax 32496
debug2: channel_input_status_confirm: type 100 id 0
subsystem request failed on channel 0
Connection closed

[Neelixx]

If you can't find any logs on TAM, then that is probably not your issue.  Specifically the entry:

"subsystem request failed on channel 0" is probably what you need to focus on.  An initial search found this.  I hope it helps.

http://h30499.www3.hp.com/t5/System-Administration/Request-for-subsystem-sftp-failed-on-channel-0/td-p/5865941#.UuprLutVBhA

[ChrisVanMeer]

Thank you for your reply, the strange thing is...on the same linux server, I can connect to other switches, that aren't registered with TAM, even the same switch models / software versions, without any problems. I also tried to sftp from a windows client, same result.

So ergo, I would think this would have to do something with TAM, but maybe I'm tunnel visioned :)

[Neelixx]

You are right.  The circumstances need to be taken into account.  However, could it be possible that the configuration of the device (when changing to TAM) could have affected the operation?  I'm a bit out of my league, since I'm not familiar enough with HP network gear.

[LindsayHill]

Those logs imply that SFTP is not enabled on that switch. Can you double-check that SFTP is still enabled on that switch?

Also, if you've got IMC, why not use that to do the backups, rather than your own script?

[ChrisVanMeer]

SFTP is still enabled on the switch (HP A5500).
The IMC backups for that switch fails as well.
My script backups a lot more than is present in IMC, that's why :)

[LindsayHill]

Hmm. Must be something to do with the service-type. I'd need to set up some a lab to dig deeper though.

If the file transfer mode in IMC is set to something OTHER than SFTP, it should work, as it will fall back to using SSH + display commands. But that doesn't help with making it work with sftp.

Wonder if there's some debugs you can run on the switch itself?

[ChrisVanMeer]

Hmm, I have to be careful with that, because it is a production switch.

What kind of debugging do you have in mind?

[ChrisVanMeer · Accepted solution]

Problem solved.

It was nessecary to provide the following custom attribute in the shell profile:

ftp-directory=flash:/

[LindsayHill]

Ah, I thought that was just for regular FTP.

Did you find that documented somewhere?

[Neelixx]

What should be concerning is that the audit log didn't show that access being denied.  At least, to me it should.  I'd want to know if someone is doing something they shouldn't be doing.

[ChrisVanMeer]

@Lindsay, I got that information from an HP engineer. Not sure if there are other custom attributes that would come in handy...
@Aaron, that is strange indeed.