New shell server transition

[Guest]

The RAR command is missing from the new shell. Can you please add RAR.

Also, can I go ahead and removed the link to the "media" directory. It doesn't work on Bolt and it doesn't work on SH. Is the target permanently gone?

[scott]

Can any of these...

• SHA1 (hmac-sha1)
  SHA1-96 (hmac-sha1-96)
  MD5 (hmac-md5)
  MD5-96 (hmac-md5-96)
  UMAC-64 (umac-64 @ openssh.com)

...get added to the MAC list?

We'd rather not, they are obsolete.

What client are you using? If you're using putty, make sure it is version 0.70.

-Scott

[Guest]

We'd rather not, they are obsolete.

That's unfortunate. As near as I can tell the Mac appears to be the only thing preventing my client from establishing a SSH2: AES256-CTR cipher. Is there any other way to privately authenticate? Certificate, prearrangement or something else?

What client are you using?

As mentioned, I'm using v7 of SecureCRT.

[gie]

I'll continue this tomorrow when I can get aid, but although this does allow me to configure a MYINBOX folder and see mail delivered, the next message that arrives flashes an "Unexpected change to folder..." message that goes away before I can read it and the new message is not delivered.

Alpine was compiled without debug?

I switched to trying yet again to get the password file to store.

It would be super helpful if alpine were compiled with debug please.

Then I could possibly figure out more about why it won't encrypt and store with the various ways I've tried to generate and store SSL certificate,

Right now when I try to start with debug I get "Argument Error: unknown flag "d", debugging not compiled in"

Thanks!

I'll get it recompiled. Currently we're using the package that came with CentOS 7, not sure why the package maintainer turned off debug in the compilation.

-Scott

I know you must be really swamped, but alpine still the version compiled w/o debug. I'd love to work on this before the transition! Thank you for everything you're doing.

[scott]

I switched to trying yet again to get the password file to store.

It would be super helpful if alpine were compiled with debug please.

Then I could possibly figure out more about why it won't encrypt and store with the various ways I've tried to generate and store SSL certificate,

Right now when I try to start with debug I get "Argument Error: unknown flag "d", debugging not compiled in"

Thanks!

I'll get it recompiled. Currently we're using the package that came with CentOS 7, not sure why the package maintainer turned off debug in the compilation.

-Scott

I know you must be really swamped, but alpine still the version compiled w/o debug. I'd love to work on this before the transition! Thank you for everything you're doing.

Installed!

-Scott

[scott]

We'd rather not, they are obsolete.

That's unfortunate. As near as I can tell the Mac appears to be the only thing preventing my client from establishing a SSH2: AES256-CTR cipher. Is there any other way to privately authenticate? Certificate, prearrangement or something else?

What client are you using?

As mentioned, I'm using v7 of SecureCRT.

I've enabled hmac-sha1-etm@openssh.com -- please let me know if that works...\

-Scott

[morley]

[quote="scott"]We're thinking of trying for March 15th as a time to start restricting access to the old shell server. However, that is somewhat flexible, as we don't want to leave anyone behind. :)

I still can't get cron to work on the new shell server.
The script I run from crontab on bolt will run from the cmd line, but not from crontab.
I can't even touch a file in $HOME from crontab. I've expermented with env. vars and abs. paths.

Sonic admins, please feel free to take a look at my crontabs on both servers, and try to spot the problem, and email me.

[scott]

We're thinking of trying for March 15th as a time to start restricting access to the old shell server. However, that is somewhat flexible, as we don't want to leave anyone behind.

I still can't get cron to work on the new shell server.
The script I run from crontab on bolt will run from the cmd line, but not from crontab.
I can't even touch a file in $HOME from crontab. I've expermented with env. vars and abs. paths.

Sonic admins, please feel free to take a look at my crontabs on both servers, and try to spot the problem, and email me.

I'll look into this.

We've been seeing some SELinux denies related to running things off of fuse-mounted filesystems. I think that may be related, looking into that too.

-Scott

[gie]

I'll get it recompiled. Currently we're using the package that came with CentOS 7, not sure why the package maintainer turned off debug in the compilation.

-Scott

I know you must be really swamped, but alpine still the version compiled w/o debug. I'd love to work on this before the transition! Thank you for everything you're doing.

Installed!

-Scott

Thank you so much! Unfortunately even at -d9 the highest debug output, nothing is logged about why the self-signed cert files I've put in place are not working. The log just says alpine starts write_passfile subroutine,



16:06:46.596673
q_status_message(Attempting to
encrypt password file)


Then straight to this with no more explanation


16:06:46.599358
q_status_message(Refusing
to write non-encrypted
password file)

I've tried a bunch of ways to generate and store self-signed cert, but nothing is working. I didn't have success with the local inbox workaround. Any suggestions for next steps on this?

[Guest]

I've enabled hmac-sha1-etm @ openssh.com -- please let me know if that works...

Thank you for enabling the "hmac-sha1" Mac algorithm. However, I'm at a complete lost to explain why the same client and Mac algorithm doesn't work with SH, but works flawlessly with Bolt. I can posts connection traces from Bolt and SH if you think that might help.