New shell server transition

Advanced feature discussion, beta programs and unsupported "Labs" features.
316 posts Page 4 of 32
by kgc » Wed Feb 28, 2018 11:21 am
casner wrote: - I use procmail to filter and dispatch incoming mail. I have maintained the .procmailrc file on bolt; Is there anything I need to do to have procmail to continue to work during and after this transition?

- I do have one cron script on bolt. Should I move it to sh now?
Procmail will continue to work as expected and I'd go ahead a migrate your cron jobs over to the new server now.
Kelsey Cummings
System Architect, Sonic.net, Inc.
by scott » Wed Feb 28, 2018 11:37 am
mikefr wrote:
scott wrote:
mikefr wrote:
Does this mean if I keep using shell.sonic.net I won't have to make any changes to my SSH configuration? I just tried connecting to sh.sonic.net using the same SSH config except for changing the host name from shell.sonic.net to sh.sonic.net and the connection failed with the following message:

Client to Server cipher algorithm could not be negotiated
Unable to locate IP Host/Gateway


(I'm using Open Text Secure Shell).
Hi,

I'll have to try that client to see why it wouldn't work with sh.sonic.net.

It might use an old cipher, in which case, please make sure your client is the latest version.

-Scott
Is there any way to tell what cipher is being attempted when I get the failure? The list of ciphers that shows in my SSH Session Properties seems to consist of current ciphers (e.g., Blowfish, AES256, etc), but this may not be what's at issue. [As I said, if I take the same config (which, BTW, is just using Username/Password for authentication) it works with shell.sonic.net but not with sh.sonic.net]. Does this mean that even once the former points to latter host I'll still get failure?
Hi Mike,

All this depends on the client, which I was about to take a look at. But it appears you've been able to log in to sh.sonic.net -- are you up and running now?

-Scott
by mikefr » Wed Feb 28, 2018 11:56 am
mikefr wrote:
scott wrote:
mikefr wrote:
Does this mean if I keep using shell.sonic.net I won't have to make any changes to my SSH configuration? I just tried connecting to sh.sonic.net using the same SSH config except for changing the host name from shell.sonic.net to sh.sonic.net and the connection failed with the following message:

Client to Server cipher algorithm could not be negotiated
Unable to locate IP Host/Gateway


(I'm using Open Text Secure Shell).
Hi,

I'll have to try that client to see why it wouldn't work with sh.sonic.net.

It might use an old cipher, in which case, please make sure your client is the latest version.

-Scott
Is there any way to tell what cipher is being attempted when I get the failure? The list of ciphers that shows in my SSH Session Properties seems to consist of current ciphers (e.g., Blowfish, AES256, etc), but this may not be what's at issue. [As I said, if I take the same config (which, BTW, is just using Username/Password for authentication) it works with shell.sonic.net but not with sh.sonic.net]. Does this mean that even once the former points to latter host I'll still get failure?
On the assumption that I won't be able to get my Open Text SSH client to work in the new environment, I've resolved this by switching to puTTY, which does allow me to connect to sh.sonic.net.

But now I have another question:

One of the things I've been using my shell access for is to retrieve the access logs for my web site. Now it appears that in the new restricted sh.sonic.net environment, those logs are not accessible. Currently (at shell.sonic.net) I use a perl script I wrote that peels off the access.log entries for my own userid (from /var/log/custweb) and creates a file which I then download to my own system via SFTP, after the script has sent me email that the log extract has been created (each night, via crontab). I'd like to keep doing this, but it seems this isn't possible using sh.sonic.net.

Are there any plans to make personal web site access logs accessible in the new environment?
by scott » Wed Feb 28, 2018 1:24 pm
mikefr wrote: One of the things I've been using my shell access for is to retrieve the access logs for my web site. Now it appears that in the new restricted sh.sonic.net environment, those logs are not accessible. Currently (at shell.sonic.net) I use a perl script I wrote that peels off the access.log entries for my own userid (from /var/log/custweb) and creates a file which I then download to my own system via SFTP, after the script has sent me email that the log extract has been created (each night, via crontab). I'd like to keep doing this, but it seems this isn't possible using sh.sonic.net.

Are there any plans to make personal web site access logs accessible in the new environment?
That's a good point. I will make them accessible.

BTW, for those who were waiting for it: trn is installed now. :)

-Scott
by casner » Wed Feb 28, 2018 1:29 pm
mikefr,

I logged into sh.sonic.net using the pre-installed ssh client on my MacBook running the somewhat old release El Capitan without any changes. This is OpenSSH 6.9p1 which was willing to authenticate using the DSA public key that I had installed long ago on bolt. A log of that session with a -v option to display debug info shows the cipher to be aes128-ctr umac-128-etm:

Code: Select all

auge3> ssh -v sh.sonic.net
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /Users/casner/.ssh/config
debug1: /Users/casner/.ssh/config line 613: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: /etc/ssh/ssh_config line 53: Applying options for *
debug1: Connecting to sh.sonic.net [208.201.242.22] port 22.
debug1: Connection established.
debug1: identity file /Users/casner/.ssh/pd type 2
debug1: key_load_public: No such file or directory
debug1: identity file /Users/casner/.ssh/pd-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to sh.sonic.net:22 as 'casner'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-128-etm@openssh.com none
debug1: kex: client->server aes128-ctr umac-128-etm@openssh.com none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:3Shjz0z7pf5EhaJuPaq4Dij92qFd34dRl9pbeNZAtWk
debug1: Host 'sh.sonic.net' is known and matches the ECDSA host key.
debug1: Found key in /Users/casner/.ssh/known_hosts:280
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /Users/casner/.ssh/pd
debug1: Server accepts key: pkalg ssh-dss blen 434
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to sh.sonic.net ([208.201.242.22]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Wed Feb 28 12:21:41 2018 from 75-25-121-24.lightspeed.snvaca.sbcglobal.net
__[ /etc/motd ]__( Sonic System News )_________
Then I tried a more recent OpenSSH 7.6p1 client that I had built from the sources distribution. It resorted to password authentication because the client no longer includes DSA keys as an accepted type by default:

Code: Select all

auge6> ./ssh -v -i ~/.ssh/id_dsa sh.sonic.net
OpenSSH_7.6p1, OpenSSL 1.0.2m  2 Nov 2017
debug1: Reading configuration data /Users/casner/.ssh/config
debug1: /Users/casner/.ssh/config line 613: Applying options for *
debug1: Reading configuration data /opt/etc/ssh_config
debug1: Connecting to sh.sonic.net [208.201.242.22] port 22.
debug1: Connection established.
debug1: identity file /Users/casner/.ssh/id_dsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/casner/.ssh/id_dsa-cert type -1
debug1: identity file /Users/casner/.ssh/pd type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/casner/.ssh/pd-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to sh.sonic.net:22 as 'casner'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: umac-128-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-128-etm@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:3Shjz0z7pf5EhaJuPaq4Dij92qFd34dRl9pbeNZAtWk
debug1: Host 'sh.sonic.net' is known and matches the ECDSA host key.
debug1: Found key in /Users/casner/.ssh/known_hosts:280
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: Skipping ssh-dss key /Users/casner/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: Skipping ssh-dss key /Users/casner/.ssh/pd - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:teZNmifgAcNSUmt72srBjUrtdPlr0zrU6Uby/3YxGxM 
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password: 

I then transferred a newer RSA key (using scp to bolt) and added it to the authorized_keys file and that made the new OpenSSH 7.6p1 client happy.

-- Steve
by patty1 » Wed Feb 28, 2018 1:52 pm
scott wrote:
BTW, for those who were waiting for it: trn is installed now. :)
Thank you, Scott! I just tried it and all seems to be well. It had the correct article count from my .newsrc, and it properly ran my killfile entries.
by scott » Wed Feb 28, 2018 2:19 pm
scott wrote:
mikefr wrote: One of the things I've been using my shell access for is to retrieve the access logs for my web site. Now it appears that in the new restricted sh.sonic.net environment, those logs are not accessible. Currently (at shell.sonic.net) I use a perl script I wrote that peels off the access.log entries for my own userid (from /var/log/custweb) and creates a file which I then download to my own system via SFTP, after the script has sent me email that the log extract has been created (each night, via crontab). I'd like to keep doing this, but it seems this isn't possible using sh.sonic.net.

Are there any plans to make personal web site access logs accessible in the new environment?
That's a good point. I will make them accessible.
Okay, these now live in /logs/custweb, and I've created a symlink that will make the directory appear at /var/log/custweb .

Give it a try!

-Scott
by kyezbick » Wed Feb 28, 2018 2:37 pm
ncurses seems to be unavailable, though we had it on bolt. Can it be added?
by kyezbick » Wed Feb 28, 2018 2:46 pm
If you want to use mutt, you will need a .muttrc that connects to IMAP:

Code: Select all

set folder    = imaps://imap.sonic.net/
set imap_user = [username]@sonic.net
set imap_pass = [enter here, or be prompted each time you check mail]
set spoolfile = +INBOX
mailboxes     = +INBOX

# The rest isn't strictly necessary, but may speed things up...

# Store message headers locally to speed things up.
# If hcache is a folder, Mutt will create sub cache folders for each
# account which may speeds things up even more.
set header_cache = ~/.cache/mutt

# Store messages locally to speed things up, like searching message bodies.
# Can be the same folder as header_cache.
# This will cost important disk usage according to your e-mail amount.
set message_cachedir = "~/.cache/mutt"

# Specify where to save and/or look for postponed messages.
set postponed = +Drafts

# Allow Mutt to open a new IMAP connection automatically.
unset imap_passive

# Keep the IMAP connection alive by polling intermittently (time in seconds).
set imap_keepalive = 300

# How often to check for new mail (time in seconds).
set mail_check = 120
by scott » Wed Feb 28, 2018 3:22 pm
scott wrote:
scott wrote:
mikefr wrote: One of the things I've been using my shell access for is to retrieve the access logs for my web site. Now it appears that in the new restricted sh.sonic.net environment, those logs are not accessible. Currently (at shell.sonic.net) I use a perl script I wrote that peels off the access.log entries for my own userid (from /var/log/custweb) and creates a file which I then download to my own system via SFTP, after the script has sent me email that the log extract has been created (each night, via crontab). I'd like to keep doing this, but it seems this isn't possible using sh.sonic.net.

Are there any plans to make personal web site access logs accessible in the new environment?
That's a good point. I will make them accessible.
Okay, these now live in /logs/custweb, and I've created a symlink that will make the directory appear at /var/log/custweb .
Um, about that...

On further review, the custweb directory hasn't kept up with the times. Back in the day, it wasn't as big a deal to have real-time web logs for the entire web cluster available to everybody -- but that isn't in the cards for a modern environment.

So please use the /logs/by_user/ directory/directories to get the split-out web logs, and we'll see what we can do to get realtime logs to people _securely_.

Sorry if this is an inconvenience. Feedback appreciated.

-Scott
316 posts Page 4 of 32

Who is online

In total there are 35 users online :: 0 registered, 0 hidden and 35 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: No registered users and 35 guests