Export of Github issues for Russell91/sshrc. Generated on 2017.05.20 at 19:19:02.

#86 PR `open`: improve readme.md

Benedikt Heine opened issue at 2017-03-17 23:45:

Looking over your nice project.

But sorry, I couldn't resist correcting this ugly code.

#85 PR `open`: Use base64 from coreutils for encoding and decoding

Michał Leśniewski opened issue at 2017-03-10 14:07:

The data transferred to the remote servers is encoded using base64. This commit changes the tool used to encode and decode the data from openssl to the base64 utility.

The change was done because openssl may be missing on some systems while base64 should always be installed as it is part coreutils. Moreover, openssl needs to access openssl.cnf, which is usually located somewhere under /etc. This part of the file system may not be accessible to the user on some remote machines, so openssl could fail in these cases.

#84 PR `open`: Deduplicate bash config file setup

taylorskalyo opened issue at 2017-02-15 03:47:

Deduplicate bash config file setup and try to fix indentation

To see the changes with whitespace ignored, you can add ?w=1 to the URL: https://github.com/Russell91/sshrc/compare/master...taylorskalyo:deduplicate_bash_conf?w=1

#83 PR `open`: run `cat /etc/motd` or `run-parts /etc/motd.d`, not both

taylorskalyo opened issue at 2017-02-15 03:46:

Running both commands often results in the message of the day being shown twice.

#82 PR `open`: alpine mktemp compatible

陈杨文 opened issue at 2017-02-13 05:42:

mktemp in alpine require at least six X

bash-4.3$ mktemp -d -t .$(whoami).sshrc.XXXXXX
/tmp/.dev.sshrc.cbGnFl
bash-4.3$ mktemp -d -t .$(whoami).sshrc.XXXX
mktemp: Invalid argument

#79 Issue `open`: executing a script before .bash_profile ...

Victor Volle opened issue at 2016-12-20 13:03:

I love to switch on coloured prompts. Most default .bashrc contain a switch "force_color_prompt=yes", but this has to be set before the .bashrc is sourced. So I would like to have a script that is sourced before .bashrc is sourced.

I currently just added

export force_color_prompt=yes

before

if [ -r /etc/profile ]; then source /etc/profile; fi
...

but I would love a solution where I do not have to patch sshrc itself

#78 Issue `open`: Loading rc files was failed after ssh reconnected with tmux attach

aiya000 opened issue at 2016-12-11 00:52:

The shell cannot loads rc files in this case 😭

First

$ sshrc (foo_host)
$ tmux
(And resume tmux)
$ exit
(Leave remote host)

Second

$ sshrc (foo_host)
$ tmux attach
(And create new tab with starting bash)
--> !!! Bash was started without loading .bashrc and .bash_profile

I think it's better to be able to lock $SSHHOME 😄

#77 Issue `open`: sshrc doesn't work when remote user's default shell isn't `bash`

Kirill Rogovoy opened issue at 2016-11-20 19:29:

I'm trying to use sshrc logging in as a user with fish default shell instead of bash. The ssh -t commands are executed by fish instead of bash hence I have a syntax error and sshrc doesn't work.

To reproduce it:

Make a new user at the remote server (or at your local PC in case you have a SSH server installed)
Install fish
Run chsh -s $(which fish) by that user
Log in by another user
Run echo "exec \$SHELL" > ~/.sshrc
Run sshrc user@host

Can you fix it or is there a workaround for this issue? Perhaps, the best way might be to add bash -c at the beginning of the ssh -t script (https://github.com/Russell91/sshrc/blob/master/sshrc#L25).

#76 PR `open`: Avoid warnings caused by BSD tar vs. GNU tar

Daniel Serodio opened issue at 2016-10-27 16:53:

When using sshrc to ssh from Mac to Linux, I get:

tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'

This PR silences these warnings that are caused by creating the tar with BSD tar and extracting it with GNU tar.

Russell Stewart commented at 2016-11-20 00:54:

Are other people getting this issue? I was unable to accept because the --warning=no-unknown-keyword flag is not imlemented elsewhere. But we could try to get clever if necessary.

Georgy Krasulya commented at 2017-02-06 20:13:

Hello. You can try this:

brew install gnu-tar
sudo ln -s `which gtar` /usr/local/bin/tar

Make sure that which tar is "/usr/local/bin/tar" and try logging on remote server

#75 PR `open`: Use $0 to determine if the user want ssh or mosh

Hugues Morisset opened issue at 2016-10-06 21:51:

Remove moshrc script as it is out of sync Everything in one script to aid maintainability

ln -s sshrc moshrc
./moshrc

#74 Issue `open`: sshrc doesn't work due to missing mktemp and -z flag on tar

Δημήτρης Ραβιόλος opened issue at 2016-08-23 09:11:

ksh[10]: mktemp:  not found
Permission denied
ksh[13]: /sshrc: cannot create
chmod: /sshrc: No such file or directory
Permission denied
ksh[16]: /sshrc.bashrc: cannot create
Permission denied
ksh[18]: /bashsshrc: cannot create
chmod: /bashsshrc: No such file or directory
Usage: tar -{c|r|t|u|x} [ -BdDEFhilmopRsUvwZ ] [ -Number ] [ -f TarFile ]
           [ -b Blocks ] [ -S [ Feet ] | [ Feet@Density ] | [ Blocksb ] ]
           [ -L InputList ] [-X ExcludeFile] [ -N Blocks ] [ -C Directory ] File ...
Usage: tar {c|r|t|u|x} [ bBdDEfFhilLXmNopRsSUvwZ[0-9] ]
           [ Blocks ] [ TarFile ] [ InputList ] [ ExcludeFile ] 
           [ [ Feet ] | [ Feet@Density ] | [ Blocksb ] ] [-C Directory ] File ...
Permission denied
ksh[23]: /sshrc.bashrc: cannot create

Would it be possible to add a pure-bash implementation of mktemp to sshrc? Something like this implementation.

The -z tar could be solved by piping to gzip, but I didn't read thoroughly the code for all tar commands.

Russell Stewart commented at 2016-09-03 06:34:

Interesting. What are your system details?

Δημήτρης Ραβιόλος commented at 2016-09-03 08:14:

This occurs on an old AIX informix database machine that we use at work.

Apparently, it uses KSH as its login shell, but everyone just changes to BASH and sources a configuration file that sets up environment variables to access the database.

As one database machine can host multiple database servers, I was looking to use ssh_config to speed up things by having virtual hostnames pointing to the same server and then using sshrc to source the correct configs server-side.

#72 Issue `closed`: Execute command (or, generalizing: support profiles)

memeplex opened issue at 2016-08-01 17:29:

I use ssh to execute remote psql shells: ssh -t myserver psql .... I would like to configure readline using sshrc to upload my .inputrc. But sshrc expands $@ before doing its stuff, which is usually fine because $@ will consist of host information and ssh options, not remote commands. Do you think adding the possibility of executing a command after setting the remote environment will be worth the extra complexity in the cli?

A more general approach, akin to the way sshrc currently copes with per-server profiles, is to execute sshrc like SSHRCPROFILE=psql sshrc myserver where SSHRCPROFILE will be propagated to the remote environment thus allowing .sshrc to act according not only to a hostname or another bit of information characterizing the remote host but also to some state (the profile) established while launching it.

I think this second approach is simple to implement and very flexible.

Russell Stewart commented at 2016-08-03 20:55:

It seems like implementing the -t option would actually solve this issue, right? This is something I've been meaning to do, but haven't found a good way of doing simply yet.

memeplex commented at 2016-08-03 21:05:

I'm not sure I'm following you but the command argument doesn't sit next to -t. Finding the command implies a more complex parsing of the command line. I like the profile approach most, first because of its generality, second because of its consistency with what sshrc currently does in order to target different servers, third because the environment variable technique avoids having to parse the complex command line of ssh.

Russell Stewart commented at 2016-08-03 21:20:

Well, 1) having the -t would let you just do sshrc myserver -t "export MYENV='$MYENV'" for any variable, so it would solve that problem. But it is indeed way more complex. That being said, we were considering adding it anyway for consistence with ssh.

Edit: But I guess you're saying that the problem is you want to be able to set that SSHRCPROFILE in your e.g. bashrc and have it be read in every time that you run sshrc?

memeplex commented at 2016-08-03 21:27:

Regarding implementing -t, if that means supporting remote execution from the command line as in ssh, all I'm saying is that it's more difficult to implement because you have to deal with the ssh cli. That said, if you are implementing that anyway, it will surely solve the issue. I don't care about exporting some profile variable per se, it was just a way to simplify things.

Russell Stewart commented at 2016-08-07 23:33:

Okay, how does the version here work for you?

memeplex commented at 2016-08-08 18:38:

Seems to work fine!

#71 Issue `closed`: Turn off motd

Timmo Verlaan opened issue at 2016-07-26 06:48:

It would be nice to turn off the motd like .hushlogin usually does. However since this is focused on the client we should have a local .hushlogin or .remotehushlogin of some sorts. I'd be willing to implement this but there is no system in place that offers configuration and therefor I'm looking for feedback. I saw the -t in the dev branch, but I'm not sure if that's the way to go (why would you need sshrc anyway if just executing one command?). If -t is really coming we could add -q for 'quiet'.

Another possibility is to remove the motd and last login stuff and leave it up to the user (add example to readme). However this breaks backwards user experience :-).

I'd love some feedback on this.

Russell Stewart commented at 2016-08-07 23:50:

Okay, this capability is added in the latest command branch. I added support for the .hushlogin on the server as ssh does, and I also added your second suggestion such that you can type

touch ~/.sshrc.d/.hushlogin

on your local machine and this will apply across all of the servers you sshrc into! I am going to use this myself as I agree that the login messages are an annoyance. Sound good?

#69 Issue `closed`: sshrc fails to transfer all files on one particular remote machine

swiftster opened issue at 2016-06-29 18:41:

I'm having trouble getting sshrc to work on one remote machine. It works fine on my other servers running Debian GNU/Linux 8 (jessie).

It seems the transfer doesn't complete. I tried reading your script to see if I could isolate the transfer to see if I could understand why it was failing, but the code is over my head.

Local: Mac OS 10.10.5; sshrc installed with brew (version 0.6.1) Remote: Ubuntu 16.04 LTS (GNU/Linux 4.4.0-24-generic x86_64)

Error Message gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now

Other Info

echo $$SSHOME /tmp/.sswift.sshrc.ZJOw ls $$SSHOME bashsshrc sshrc sshrc.bashrc

These are all empty files.

Russell Stewart commented at 2016-07-09 17:18:

Can you confirm whether the error is on the local or the remote machine? I don't have a 16.04 machine to test on at the moment, but it would be great if someone with one could make sure this problem doesn't reoccur for any remote 16.04 machine.

swiftster commented at 2016-07-12 15:53:

Well, I feel a little silly. The problem was my shell was sh (someone else set up this computer and my account).

Changed my default shell to bash, and all is well.

Russell Stewart commented at 2016-07-12 20:04:

I see, glad you got it figured out!

#68 Issue `closed`: Support for GPG?

Zakatell KANDA opened issue at 2016-05-19 06:19:

Hello, Is there any way I can use sshrc to temporarily copy and use my gpg key to the server? My use case:

Sometimes I connect to a server a fix something there.
I want to commit this changes but sign it with my key.

Thank you.

Russell Stewart commented at 2016-05-19 22:15:

Yea, just put your gpg key into the ~/.sshrc.d folder and you can access it at $SSH_HOME/.sshrc.d/gpg.key on the remote machin.

Russell Stewart commented at 2016-05-24 06:34:

Did this answer your question?

Zakatell KANDA commented at 2016-05-24 07:34:

Yes it does, thanks for closing it. 👍

#66 Issue `closed`: Feedback / code review on new "-t" option

Labels: help wanted

Russell Stewart opened issue at 2016-05-04 02:39:

The sshrc in the dev branch (https://github.com/Russell91/sshrc/blob/dev/sshrc) has a new -t option, which will append the argument following -t as a new line to a copy of the .sshrc file, and exit after running command. Do people have any thoughts on this?

serverco commented at 2016-05-05 10:33:

I like the concept. Could it be done in the same way as ssh though ? where it doesn't need a "-t" flag, simply whatever is after the host name is passed to the server as a command. All the other commands commands / args are the same as the default ssh, so it makes sense to me to deal with the "comand" in the same way as ssh deals with it.

Russell Stewart commented at 2016-05-05 19:11:

Yea, that's a good point. It should be done that way. We'll need to emulate the sshrc argument parser though.

serverco commented at 2016-05-06 08:55:

How about something along the lines of ....

DOMAIN=""
SSHARGS=""
CMNDARG=""
while [[ -n $1 ]]; do
  case $1 in
    -h | --help)
      echo "some nice help message" ; exit ;;
    -b | -c | -D | -E | -e | -F | -I | -i | -L | -l | -m | -O | -o | -p | -Q | -R | -S | -W | -w )
      SSHARGS="$SSHARGS $1 $2"; shift ;;
    -t )
      echo "-t not allowed with sshrc"; exit ;;
    -* )
      SSHARGS="$SSHARGS $1" ;;
    *)
      if [ -z $DOMAIN ]; then
       DOMAIN="$1"
      else
        CMNDARG="$CMNDARG $1"
      fi
      ;;
  esac
  shift
done

Which would then provide you with

the ssh options (SSHARGS) that you could pass on to ssh,
the domain name (DOMAIN), and
the CMNDARG with any command to be passed ( ideally there should be only one, quoted, but this allows multiple)

It also enables;

the -h / --help flag for you to provide a default help message about sshrc usage and
blocks the -t flag from being passed to ssh separately to the -t flag that sshrc is using.

Russell Stewart commented at 2016-07-25 18:46:

I really don't like explicitly casing on all this stuff for backwards compat reasons. It also just complicates the entire script. Isn't there some way we could accomplish this with fewer lines of code?

serverco commented at 2016-07-26 19:24:

The explicit casing was purely because that's the explicit casing that SSH uses.

Yes, could be shorter, it's always a balance between compactness and readability I think. It depends which is more important.

Russell Stewart commented at 2016-08-07 23:33:

Okay, thoughts on the new version at https://github.com/Russell91/sshrc/blob/command/sshrc?

serverco commented at 2016-08-08 06:54:

works for me :)

Personally I like the -h option ( to provide a little help and guidance about the script)

If I was getting fussy, I'd say you might want to trap the "-W" and "-T" options, as they will cause it to hang / fail. I suspect the chances of anyone trying to use the options, with your script, are very remote though.

Russell Stewart commented at 2016-08-08 21:04:

Okay, I'll consider doing something for the -h in the future. Good points about -T and -W, but looking at the use cases it seems anyone trying them with sshrc would not expect them to work in the first place. So I don't think it's necessary to add the code.

#65 Issue `closed`: Please make latest tag and release

Ikuo Degawa opened issue at 2016-04-29 09:40:

Probably 0.6.1?

I think recent changes relating to xxd (The message: sshrc requires xxd to be installed on the server, but it's not. Aborting.) should be distributed by homebrew.

https://github.com/Russell91/sshrc/commits/master https://github.com/Homebrew/homebrew-core/blob/fb81645562f7e495a49561065912788af2d1f14f/Formula/sshrc.rb

Stephen Ball commented at 2016-05-01 20:57:

I was just about to ask exactly the same thing

Russell Stewart commented at 2016-05-01 21:14:

Okay, done! For the record, the delay between master and tagged releases for homebrew etc. is done to help reduce the effect of potential bugs.

Ikuo Degawa commented at 2016-05-04 03:23:

Thank you! I submitted pull request to homebrew-core: Homebrew/homebrew-core#828

#61 Issue `closed`: Is it possible to add a surc

陈杨文 opened issue at 2016-04-09 07:33:

surc is just su + sshrc's rc files.

Russell Stewart commented at 2016-04-09 20:48:

You would have to spend at least a little more effort explaining the virtues of adding this. But the answer is likely going to be no.

serverco commented at 2016-04-11 13:46:

The key virtue to me is when logging into a server as a non privileged user and then wanting to "sudo su" to change to the root user for admin tasks. I had a look into automating it, however there was usually some undesired feature that came with each method I tried. In the end I resulted to simply doing

. /tmp/.user.sshrc. (where "user" is your normal username, and pressing tab to auto-complete followed by .sshrc )

This then ran my usual sshrc files and gave me all my normal configuration / functions etc as su. Since there was no need to code / modify anything, just a simple command - I used that.

陈杨文 commented at 2016-04-11 16:17:

I can't access /tmp/.user.sshrc. due to permission denied. I sshrc root@host then su other.

serverco commented at 2016-04-11 16:55:

I'm not sure I see any advantages of adding all the sshrc functions that way round.

It would be relatively easy to create a surc script though that placed the relevant files in a location that the new user did have permission to read, then simply run the file in that location once you are set as the new user. The script should tidy up the file you created afterwards.

陈杨文 commented at 2016-04-11 16:59:

Thanks, I will use the source to load my sshrc from other user.

Russell Stewart commented at 2016-04-20 17:40:

Okay @wenerme, looks like you were able to figure this out?

Stephen Ball commented at 2016-04-21 12:43:

@wenerme Did you ever come up with an automated way of doing this? I am after something similar myself for vagrant machines where I need to su but I am not able to change the provisioning script to change the profile for other users. Currently I am just running chmod -r 777 /tmp/.stephen.XXX/ then changing the user and doing source /tmp/.stephen.XXXX/.sshrc but was looking to see if anyone had automated it

陈杨文 commented at 2016-04-21 13:13:

@REBELinBLUE Sorry I don't have a solution now. I think surc should chmod to target user.

serverco commented at 2016-04-21 13:20:

It depends if you just want root permissions ( su ) or if you want to completely represent a different user ( with some additional sshrc from your script)

If you want to just have the permissions of superuser ( or a different user) then you could simply do sudo -E su -p (user) which preserves your environment. However, as it preservers your environment it keeps environmental variables such as $HOME pointing you your 'real' home directory, not the user you are trying to become.

You could have a simple script that you could run which would update the relevant variables such as HOME though. (simply check if SUDO_COMMAND exists, if so then set the HOME variable from that).

#60 Issue `closed`: Alternatives to xxd

serverco opened issue at 2016-04-08 10:45:

I see from old closed issues that there has been some talk of providing alternatives to xxd. I found it wasn't on all the servers I connected to.

I tested by creating variables for the encode / decode

xxd works fine if xxd is on the remote server

encodefn="xxd -p" decodefn="xxd -p -r"

uuencode works fine if uudecode is on the remote server

encodefn="uuencode -m - " decodefn="uudecode"

openssl works fine (and was on all of my servers)

encodefn="openssl enc -base64" decodefn="openssl enc -d -base64"

Is there a desire to include alternatives ? if so I'm happy to produce a version that could either automatically fail over to using a different method, or could have a command line arg ( e.g. -x, -u or -o for xxd, uuencode, openssl)

Russell Stewart commented at 2016-04-08 19:00:

Indeed https://github.com/Russell91/sshrc/pull/56 and https://github.com/Russell91/sshrc/pull/14 showed a lot of interest in changing away from xxd. I spent several hours trying to hack base64 into working, but the issue with that tool in particular is that it cannot support OSX and Linux simultaneously due to API versioning. I was not aware of openssl or uuencode prior to this post, so these could be promising substitutes. The minimal constraint on a pull request is that the tool needs to be able to work on both OSX and Debian. Emphasis on client side being good for OSX and server side being good for Debian. For now, the PR could try to automatically use one of these tools, and fall back to the xxd error message if none of the options works.

serverco commented at 2016-04-08 19:21:

I also tested using "base64" to encode on my laptop ( ubuntu - debian based ) and "openssl enc -d -base64" to decode on the server - that worked perfectly as well.

I don't have easy access to OSX to test those - so can't verify those I'm afraid.

uuencode / uudecode worked fine - but tended to be on the older servers for me, rather than the newer ones. openssl was on all of the ones I tested though ( debian and redhat / centos ) and was consistent across all ( for me ).

Russell Stewart commented at 2016-04-08 19:33:

I see. The problem with OSX is that Steve Jobs stopped accepting new UNIX tools due to GPL concerns. But OSX Server is going to be incredibly uncommon, so if you want to do a server side only pull request adding support for these tools, that would be great. Maybe we could make it so that one would also transfer a few bytes of verification (e.g. 'sshrc') at the beginning of the command and read those off from the decoding tool to make sure there are no incompatibilities in the base64/base16 encodings. But yea, if there were a little module that would look for any one of these tools, guarantee compatibility by making sure encoding . decoding == identity, and never exit with an xxd OR base64 OR ... error otherwise, that would be a strict win. Client side modifications would just have to be done by someone with a macbook.

serverco commented at 2016-04-08 19:42:

Sounds a good plan.

I've just created a fork, and uploaded my test version at https://github.com/srvrco/sshrc/blob/test_alternates/sshrc if you have access to OSX and could test any ( would like to see if some do work, before setting up the failover etc. ) it's not ready for a formal PR yet, but at least you could do a test before I tidy things up ( I changed a few things as I was working out how it all works ;) )

Russell Stewart commented at 2016-04-09 20:49:

Okay, I have this on my list of things to look into.

serverco commented at 2016-04-11 12:22:

Having played with this, I haven't found a realistic way to get it to chose the optimal conversion package with a single connection (because you need to know the encode method to send the files at the beginning, before you have determined which is the best method.

The options that come to mind are;

Allow multiple connections - doing first a series of connections testing if the encoding / decoding method works. I don't really like multiple connections each time though.
Encode the data using all the available methods (from your PC) and then test to determine which decrypts best, and use that one. This has the advantage of only one connection, however has the disadvantage of sending the data 3 times ( if using base64/openssl, xxd and uuencode )
Allow a command line argument ( or config file ) for the user to specify which encoding method is used. It could be a mixture of the two - a config file that allows you to specify your preferred default, and a command line argument that enables you to overwrite the default for certain connections.

I'm open to other suggestions, I just wanted to put down my findings so far - and see if you had a preference for any of these options ( or an alternative solution )

Russell Stewart commented at 2016-04-26 00:09:

Addressed by https://github.com/Russell91/sshrc/pull/64

#59 Issue `closed`: Sourced resources are not being transferred

Elvis opened issue at 2016-04-06 06:41:

I want to have some file with common settings for both local and remote environments.

[[ -f ~/.shared_rc ]] && . ~/.shared_rc
# Remote specific settings
exec -l $(which zsh) # invoke remote zsh shell

I believe this done for security reasons but maybe I'm missing something 🤔

Russell Stewart commented at 2016-04-06 20:51:

It's not clear exactly what you're asking for. But any files you put into ~/.sshrc.d will be transferred to the remote environment, and they'll be accessible locally as well. Does that help?

So, for example, create ~/.sshrc.d/.shared_rc, and add

source ~/.sshrc.d/.shared_rc

to your local .bashrc, and add

source $SSHHOME/.sshrc.d/.shared_rc

to your .sshrc.

Russell Stewart commented at 2016-04-09 20:49:

Marking as resolved for now. Hope it helped!

#58 Issue `closed`: Homebrew install moshrc

陈杨文 opened issue at 2016-03-26 16:22:

Currently there is no moshrc in brew

$ brew info sshrc
sshrc: stable 0.5, HEAD
Bring your .bashrc, .vimrc, etc. with you when you SSH
https://github.com/Russell91/sshrc
/usr/local/Cellar/sshrc/0.5 (4 files, 7.1K) *
  Built from source
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/sshrc.rb

$ brew info moshrc
Error: No available formula with the name "moshrc"

$ tree `brew --prefix sshrc`
/usr/local/opt/sshrc
├── INSTALL_RECEIPT.json
├── LICENSE
├── README.md
└── bin
    └── sshrc

1 directory, 4 files

陈杨文 commented at 2016-03-26 16:28:

Just need a new release tag.

Russell Stewart commented at 2016-03-26 19:03:

Okay, new release at https://github.com/Russell91/sshrc/releases/tag/0.6. Is there anything else I need to do?

陈杨文 commented at 2016-03-27 06:06:

Thanks, that's enough, Homebrew/legacy-homebrew#50453

Russell Stewart commented at 2016-03-28 06:21:

Great! I don't use moshrc currently, but I know brew install sshrc is very convenient for me. Good work.

#57 PR `open`: Add screen config example to README.md

exAspArk opened issue at 2016-01-29 16:47:

To close #36. Based on the tmux configuration.

#54 Issue `closed`: Having to specify full path to /usr/local/bin/sshrc even though its in PATH, and +x

Predatorian opened issue at 2015-10-02 16:46:

For some reason, on CentOS 7, I'm having issues with this script running when its in /usr/local/bin/sshrc and set to 755. Then I changed the ownership from root to the user, and the user still cannot run it from the command line. However, specifying the full path allows it to run. Am I doing something wrong?

Russell Stewart commented at 2015-10-12 07:40:

Do you have a reason to believe that this issue would be caused by sshrc rather than you PATH and permission settings of the OS?

Predatorian commented at 2015-10-13 13:08:

Yes, I was mistaken. My apologies, this can be closed.

#53 Issue `closed`: Last login information

Russell Stewart opened issue at 2015-09-18 05:34:

Request for comment on how to emulate ssh's output when logging in e.g.

Last login: Thu Sep 17 22:32:11 2015 from 000.000.000.000

Jonathan Rehm commented at 2015-09-18 19:55:

I was looking into that a week or so ago and found a forum post that gave me this much:

lastlog -u $USER | sed -n "2{p;q}" | tr -s ' ' | cut -d' ' -f4-9

That outputs something like this: Fri Sep 18 12:52:33 -0700 2015

Try as I did, I could not prepend "Last login: " and append " from " to it and have it show on one line. My bash-fu is too weak. Hopefully someone else's is stronger and can take that to completion.

Russell Stewart commented at 2016-03-16 22:24:

I'm going to archive this issue for now.

#50 Issue `open`: Add homebrew bash completion

Labels: enhancement

Russell Stewart opened issue at 2015-08-26 19:59:

Continuation of https://github.com/Russell91/sshrc/issues/44#issuecomment-124967391. Request for comment on the best way to add bash completion on homebrew for OSX.

See http://www.harding.motd.ca/autossh/ for an example of another tool that has reasonable completion.

Evgeny Vereshchagin commented at 2015-08-26 22:52:

@Russell91 , what do you think about https://github.com/Homebrew/homebrew-completions ?

Evgeny Vereshchagin commented at 2015-08-26 23:18:

See https://github.com/Russell91/sshrc/issues/49#issuecomment-135203140

Russell Stewart commented at 2015-08-29 20:58:

@evverx seems reasonable. What are the alternatives?

Evgeny Vereshchagin commented at 2015-08-31 13:56:

@Russell91 , bash_completion.install in the sshrc formula. See git.rb.

#49 Issue `open`: Add apt-get bash completion

Labels: enhancement

Russell Stewart opened issue at 2015-08-26 19:57:

Continuation of https://github.com/Russell91/sshrc/issues/44#issuecomment-124967391. Request for comment on the best way to add bash completion on apt-get for Ubuntu 12.04+.

See http://www.harding.motd.ca/autossh/ for an example of another tool that has reasonable completion.

Evgeny Vereshchagin commented at 2015-08-26 22:48:

@Russell91 , you can:

Add Build-Depends: debhelper to debian/control (Source: sshrc section)
Add Build-Depends-Indep: bash-completion to debian/control (Source: sshrc section)
Add Recommends: bash-completion to debian/control (Package: sshrc section)
Add

override_dh_auto_install:
    dh_auto_install
    dh_bash-completion

to debian/rules

Create debian/sshrc.bash-completion

_completion_loader ssh 2>/dev/null # for bash-completion >= 1.90, bash >= 4.1
eval $(complete -p ssh | sed 's/ ssh$/ sshrc/')

Evgeny Vereshchagin commented at 2015-08-26 23:16:

Well, the simplest way: update bash-completion:) See:

add autossh to list of commands that perform _ssh() completion
Do rest of splits, add symlinking for files defining multiple completions.

Russell Stewart commented at 2015-08-26 23:50:

Is it safe to post my debian folder on the apt-get branch? That would probably make it much easier for people to suggest these sort of changes.

Evgeny Vereshchagin commented at 2015-08-27 00:18:

Is it safe to post my debian folder on the apt-get branch?

Yes, it's safe.

That would probably make it much easier for people to suggest these sort of changes.

Ok.

Russell Stewart commented at 2015-08-27 00:27:

I just pushed the debian folder to the apt-get.

Evgeny Vereshchagin commented at 2015-08-27 00:56:

@Russell91 , done

Evgeny Vereshchagin commented at 2015-08-27 01:33:

But dh_bash-completion still installs files in /etc/bash_completion Fixed in 2.1-4.2

Evgeny Vereshchagin commented at 2015-08-27 01:53:

I've removed dh_bash-completion. Used an install mechanism instead.

#48 Issue `open`: man page

Labels: enhancement

Pranav Kant opened issue at 2015-08-26 19:14:

would be great if we have a man page.

Russell Stewart commented at 2015-08-26 20:06:

Good idea. We're trying out a new strategy where features like this would be bundled into installations for either homebrew or apt-get (or something else?), although it seems like standardizing the man page across these installs would be a good idea. What's the best way to add a man page to an e.g. apt-get installed tool?

Russell Stewart commented at 2015-08-26 20:11:

@pranavk Also, it seems based on https://bugzilla.redhat.com/show_bug.cgi?id=1247328#c1 that you have some interest in setting up Fedora support. I've created a Fedora branch as well. I'd like to modify the master readme to suggest the simple install, or to link to the ubuntu, osx, fedora, and archlinux pages for installation. Those pages could then have 1-2 paragraph set of install instructions on their respective system.

Pranav Kant commented at 2015-09-27 07:57:

Sorry for such a late reply.

What's the best way to add a man page to an e.g. apt-get installed tool?

The best way would have been using autotools, and let it install the man pages for you[1]. But since this package is not very big, I don't using autotools is worth it. What we can do is simply write the man pages using manedit[2], or something similar and include those man pages in the source tree (preferably under a man subdirectory). The package maintainers from various distributions can then pick them up and install them appropriately.

[1] http://www.gnu.org/software/automake/manual/html_node/Man-Pages.html [2] http://freecode.com/projects/manedit

Pranav Kant commented at 2015-10-08 17:22:

jfyi, that we are on fedora now.

as of now, i didn't include any man pages in the release.

#47 Issue `closed`: proper quoting required

Pranav Kant opened issue at 2015-08-10 07:42:

Would be great if we fix it upstream here, rather than having a patch downstream[1].

 if [ $1 ]; then
      command -v xxd >/dev/null 2>&1 || { echo >&2 "sshrc requires xxd to be installed locally, but it's not. Aborting."; exit 1; }
      sshrc $@

This is an accident waiting to happen. Proper quoting is required around $@. [ $1 ] will go wrong if options are given on the command line."

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1247328#c1

Russell Stewart commented at 2015-08-26 19:42:

We'll get this fixed. Are there any other shell idioms that are being violated?

Russell Stewart commented at 2015-08-26 20:22:

fixed by https://github.com/Russell91/sshrc/commit/3d507b15026920eebd8388b4fd55a31a3135542e

#45 Issue `closed`: `deb`-package is outdated

Evgeny Vereshchagin opened issue at 2015-07-26 19:50:

Hi, @Russell91 ! Thanks for the useful tool!

There are two problems with deb-package:

0.4 is outdated:

apt-get download sshrc
# Get:1 http://ppa.launchpad.net/russell-s-stewart/ppa/ubuntu/ vivid/main sshrc all 0.4-trusty-1 [2,726 B]
dpkg-deb --raw-extract sshrc_0.4-trusty-1_all.deb SSHRC
cd SSHRC/usr/bin
wget https://raw.githubusercontent.com/Russell91/sshrc/master/sshrc -O last
diff -q sshrc last
# Files sshrc and last differ

Missing vim-common (for xxd) in the debian/control's Depends field.

Russell Stewart commented at 2015-07-26 23:01:

Good idea about adding vim-common to the dependency list. Just took care of that and updated the repository.

Evgeny Vereshchagin commented at 2015-07-27 09:31:

@Russell91 , thanks. Works fine 👍

#44 Issue `closed`: missing bash completion

Julian opened issue at 2015-07-19 16:09:

It would be very fine if we have the same bash completion features as in ssh (host completion based on ssh's config, known hosts, etc.). Otherwise it is hard to archive the same productivity as with native ssh.

There where two pull requests based on this feature request (#11 , #25). #11 is already closed, but #25 is still open and needs some help!

Russell Stewart commented at 2015-07-19 19:04:

Okay, I think it was mostly my fault that people stopped working on this. But I still want to ensure we hit a certain quality before we can merge. In particular, my two big requirements are that

a) It works on both Ubuntu and OS X (even if there is special casing) b) It requires the user to at most add a single line to their .bashrc

(b) is the tough one because many users install sshrc by simply downloading the file. Thus, it will require some creativity to avoid people downloading multiple files. The reason (b) is important though is because in my mind the cost of 5 minutes of up front configuration outweighs the value of the feature for most users.

Perhaps one could add the bash completion logic to the sshrc file and the user could add "source which sshrc" to their .bashrc? We'd need to make sure sshrc was designed be sourced in that case. If anyone has good ideas here that would be nice as well.

Evgeny Vereshchagin commented at 2015-07-26 10:26:

@jneureuther ,

install bash-completion
Add the following lines to your ~/.bashrc (~/.bash_profile on OSX)

_completion_loader ssh 2>/dev/null # for bash-completion >= 1.90, bash >= 4.1
eval $(complete -p ssh | sed 's/ ssh$/ sshrc/')

Russell Stewart commented at 2015-08-26 19:59:

This works great, and it is more robust than anything I've put together, but the install is way above the level of difficulty that would make sense to put on the readme. Instead, I'm opening up two new branches on sshrc, apt-get and homebrew, that will allow us to tailor features like this to specific installs. Both package managers will make it easy to hide this complexity in a more traditional install mechanism. This will create two types of sshrc - one that is fully featured and comes with package managers, and one that is a lightweight single bash file that can be installed anywhere. See either https://github.com/Russell91/sshrc/issues/49 or https://github.com/Russell91/sshrc/issues/50

disrupted commented at 2017-05-05 18:24:

is there any way to get completion with this method using ZSH instead of Bash?

#42 Issue `closed`: Wrong bash version on OS X server is being used

Matthew Chen opened issue at 2015-06-14 18:43:

When I use regular ssh:

[mchenja@mycomp ~]$ ssh remotecomp.mydomain.com
remotecomp:~ mchenja$ echo $BASH_VERSION
4.3.33(1)-release

When I use sshrc:

[mchenja@mycomp ~]$ sshrc remotecomp.mydomain.com
[mchenja@remotecomp ~]$ echo $BASH_VERSION
3.2.57(1)-release

I installed bash 4 on my remote computer using homebrew, if you think that might affect the issue.

Russell Stewart commented at 2015-06-14 21:27:

Yea, I don't know what your exact setup is, but it looks like your path may be favoring the older version of bash. Maybe you could try swapping out bash in line 33 of https://github.com/Russell91/sshrc/blob/master/sshrc: exec bash --rcfile <(echo '

for the full path to your preferred bash executable?

Matthew Chen commented at 2015-06-15 01:26:

I haven't tried that yet, but I made my (local) .sshrc file an empty file, and I also deleted my .bashrc and .bash_profile files on my remote computer to help debug the issue.

Here's what I see when I use regular ssh:

[mchenja@mycomp ~]$ ssh remotecomp.mydomain.com
remotecomp:~ mchenja$ echo $BASH_VERSION
4.3.33(1)-release
remotecomp:~ mchenja$ which bash
/usr/local/bin/bash
remotecomp:~ mchenja$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin

But when I use sshrc, here's what happens:

[mchenja@mycomp ~]$ sshrc remotecomp.mydomain.com
bash-3.2$ echo $BASH_VERSION
3.2.57(1)-release
bash-3.2$ which bash
/bin/bash
bash-3.2$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/var/folders/m7/2lsx99rn2x109gmchxn2sp_r0000gn/T/.mchenja.sshrc.XXXX.INeVA8xH

Clearly, some code in sshrc is changing my path, and perhaps not loading some (system-generated) .bashrc file somewhere which adds the /usr/local/bin path (for brew) as well as the Server.app paths.

For what it's worth, I don't think this is an idiosyncratic issue. I'd suspect that anyone who has homebrew installed on their remote computer should have a similar issue.

Russell Stewart commented at 2015-07-03 20:49:

Can you confirm whether you were able to get things working with the fix? At this point, the root cause is that sshrc does not fully support the remote server being OS X, simply because I don't have any OS X server's to ssh into and test on. If you have figured out a cleaner way to fix the problem than the hack I suggested, please consider submitting a pull request or just letting me know.

Matthew Chen commented at 2015-07-09 00:26:

Actually solving the problem has proven to be a bit trickier than I expected, since I'm not very familiar with some of the functions called in your code. But I have a good understanding of the issues, so I'll explain them here, and I submitted pull request #43 to fix the first one.

Issue 1: Incorrect Path on Mac OS X

Looking at the man page for bash on Mac OS X, it explains:

When bash is invoked as an interactive login shell, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

The man pages for bash on corn.stanford.edu and myth.stanford.edu, both of which are running Ubuntu, specify the same behavior.

Currently, sshrc doesn't read these files that are specified by the man page, so I wrote code to do so, tested on my Mac and two linux machines and submitted pull request #43.

Issue 2: Wrong Bash Version on Mac OS X

The issue is that the shell spawned by ssh <various commands> is the default version of bash, even after the user has changed shells with chsh -s. For example:

ssh without any commands

[mchenja@mycomp ~]$ ssh localhost
[mchenja@mycomp ~]$ echo $BASH
/usr/local/bin/bash

ssh with commands

[mchenja@mycomp ~]$ ssh localhost 'echo $BASH'
/bin/bash

Possible Fix

As long as the correct path is present, calling exec bash should load the desired bash. For example:

[mchenja@mycomp ~]$ ssh localhost 'source /etc/profile; exec bash'
echo $BASH
/usr/local/bin/bash

However, I've been unable to merge this fix into sshrc; I also tried your suggested fix, but it didn't work:

before the change

[mchenja@mycomp sshrc]$ sed -n '33p' sshrc
exec bash --rcfile <(echo '
[mchenja@mycomp sshrc]$ ./sshrc localhost
[mchenja@mycomp ~]$ echo $BASH
/bin/bash

after the change

[mchenja@mycomp sshrc]$ sed -n '33p' sshrc
exec /usr/local/bin/bash --rcfile <(echo '
[mchenja@mycomp sshrc]$ ./sshrc localhost
[mchenja@mycomp ~]$ echo $BASH
/bin/bash

Consequently, I think there must be some other aspect of your code that is affecting which bash is executed, but I'm unsure what that aspect is.

Russell Stewart commented at 2015-07-12 05:33:

Merged into master.

#41 Issue `closed`: SSHHOME is incorrect (deleted) when resuming Tmux sessions

Matthew O'Riordan opened issue at 2015-06-08 09:29:

I find that upon SSHRC'ing back into a box a second time with a Tmux session left running, the variable $SSHHOME is invalid because the folder has been deleted.

Probably easiest to explain with a log:

# first time to connect to the server
$ sshrc my-remote-server.com

remote $ tmux -S /tmp/matt.tmuxserver

remote $ echo $SSHHOME
/tmp/.mattheworiordan.sshrc.fZxN

# check to see if the folder & contents exist
remote $ ls $SSHHOME
bashsshrc  sshrc  sshrc.bashrc

# Detach from tmux
Ctrl-B, Ctrl-D

# second connect to the server
$ sshrc my-remote-server.com

# Checking SSHHOME confirms a new folder has been created
remote $ echo $SSHHOME
/tmp/.mattheworiordan.sshrc.GD0

# Attach to the Tmux session
remote $ tmux -S /tmp/matt.tmuxserver

# SSHHOME still points to the old folder
remote $ echo $SSHHOME
/tmp/.mattheworiordan.sshrc.fZxN

# Unfortunately SSHHOME does not exist
remote $ ls $SSHHOME
ls: cannot access /tmp/.mattheworiordan.sshrc.fZxN: No such file or directory

What do you recommend to get around this problem?

Russell Stewart commented at 2015-06-11 18:41:

Yea, this problem requires some clever tricks to avoid. But fortunately, they are already in the readme! If you consult the provided tmuxrc function:

tmuxrc ()
{
    local TMUXDIR=/tmp/russelltmuxserver;
    if ! [ -d $TMUXDIR ]; then
        rm -rf $TMUXDIR;
        mkdir -p $TMUXDIR;
    fi;
    rm -rf $TMUXDIR/.sshrc.d;
    cp -r $SSHHOME/.sshrc $SSHHOME/bashsshrc $SSHHOME/sshrc $SSHHOME/.sshrc.d $TMUXDIR;
    SSHHOME=$TMUXDIR SHELL=$TMUXDIR/bashsshrc /usr/bin/tmux -S $TMUXDIR/tmuxserver $@
}

You will notice that it takes a step to copy the contents of your old $SSHHOME into a special tmux directory that will not be deleted when your original shell exits. Of course, you'll have to modify the TMUXDIR to be your own /tmp/mattheworiordantmuxserver, but otherwise you should be good to go.

Matthew O'Riordan commented at 2015-06-12 17:45:

Thanks @Russell91, you're a legend. I had misinterpreted your example, but I understand it now and have it all working as expected.

Russell Stewart commented at 2015-06-14 21:20:

Okay, is there any way that the Readme example could have been more clear?

Matthew O'Riordan commented at 2015-06-17 10:23:

@Russell91 I think it was my fault because I tried to modify it for my needs. The only thing I did find odd is that in your example you execute Tmux as follows:

SSHHOME=$TMUXDIR SHELL=$TMUXDIR/bashsshrc /usr/bin/tmux -S $TMUXDIR/tmuxserver $@

However, the bashsshrc file, at least in my environment, simply loads .sshrc so it loads itself?

#40 Issue `closed`: Agent forwarding support?

Scott Rubin opened issue at 2015-04-05 22:12:

Let's say I use agent forwarding to SSH from machine A to machine B, then from machine B to machine C. I've only configured my vimrc and such on machine A, which is the machine I am physically sitting at. Will the vimrc end up all the way on machine B?

Russell Stewart commented at 2015-04-05 22:22:

I'm not sure how you are accomplishing "agent forwarding", but my suspicion is that it will not work. However, sshrc does copy it's own binary to machine B, so you can do sshrc B followed by sshrc C, and the vimrc will end up all the way on machine C. To make this more convenient, you can add to your sshrc a line that says:

if [ `hostname | grep B | wc -l` == 1 ]; then
    sshrc C
fi

That's how I've done it in this case at least.

#39 Issue `closed`: Homebrew support

Russell Stewart opened issue at 2015-04-05 21:27:

If someone could create a homebrew recipe, I can link to it on the readme. There was a problem early on with sshrc where the homebrew recipe fell out of date and was causing problems for users, but things are much more stable now and I think it would be nice for mac users to have this option.

#37 Issue `closed`: Freebsd support

Moddus opened issue at 2014-11-04 21:59:

Hi, thanks for your work. Are you planning to make sshrc available on freebsd ? I'm get following output but I'm not able to fix it :(

Ambiguous output redirect.
if: Expression Syntax.
then: Command not found.
fi: Command not found.
Illegal variable name.
SSHHOME: Undefined variable.
SSHRCCLEANUP: Undefined variable.
Illegal variable name.
SSHHOME: Undefined variable.
Illegal variable name.
Illegal variable name.
SSHHOME: Undefined variable.
Illegal variable name.
SSHHOME: Undefined variable.
SSHHOME: Undefined variable.
Connection to xxx.xxxx.xxxx.xxxx closed.

Regards, Moddus

Russell Stewart commented at 2015-03-21 08:51:

I don't have a freebsd system, so I can't offer much assistence. I'm still hoping another user would come along and be able to assist you.

Russell Stewart commented at 2015-04-16 01:04:

Can you tell me the output of bash --version? Mine is 3.2.51 and works.

nandeska commented at 2016-03-18 18:33:

I confirm that behavior with my FreeBSD servers. FreeBSD handles redirects and shells variables in a different way than Linux, I'm checking how sshrc could work with it

#36 Issue `open`: Screen support?

Labels: enhancement

Thomas Riccardi opened issue at 2014-10-15 09:52:

Has anyone made this work with screen? tmux may not be available on the target machine, screen is more often.

Russell Stewart commented at 2014-10-15 09:56:

You can certainly try. I'll give you a slot on the wiki if you design a screenrc function that works the same as tmuxrc. You'll need to look through different environment variables, and there are often lots of corner cases. Good luck if you look into it. I don't use screen so it's not at the top of my list.

On Wed, Oct 15, 2014 at 2:52 AM, Thomas Riccardi notifications@github.com wrote:

Has anyone made this work with screen? tmux may not be available on the target machine, screen is more often.

— Reply to this email directly or view it on GitHub https://github.com/Russell91/sshrc/issues/36.

Frank Hoffsümmer commented at 2015-11-05 09:50:

I had a first quick stab at doing this

screenrc() {
    local SCREENDIR=/tmp/russellscreenserver
    if ! [ -d $SCREENDIR ]; then
        rm -rf $SCREENDIR
        mkdir -p $SCREENDIR
    fi
    rm -rf $SCREENDIR/.sshrc.d
    cp -r $SSHHOME/.sshrc $SSHHOME/bashsshrc $SSHHOME/sshrc $SSHHOME/.sshrc.d $SCREENDIR
    SSHHOME=$SCREENDIR /usr/bin/screen -c $SCREENDIR/.sshrc.d/.screenrc -s $SCREENDIR/bashsshrc $@
}

not completely good yet, works only for all subsequently opened screens (C-a), not the first one

cryptid11 commented at 2017-02-08 01:26:

any news on this? do I have to start using tmux? XD

#35 Issue `closed`: Duplicate `rm -rf \$SSHRCCLEANUP`

Thomas Riccardi opened issue at 2014-09-30 18:04:

A trap is setup at exit to cleanup the temporary directory. But in case of non error exit, a second rm -rf \$SSHRCCLEANUP is also executed after \$SSHHOME/bashsshrc. It should probably be removed.

Russell Stewart commented at 2014-09-30 20:22:

yea, I'm not sure what the semantics of trap '...' 0 are. Does this get called in every case, or just when there is an error thrown? rm -rf needs to be called in every case.

Thomas Riccardi commented at 2014-09-30 20:36:

From the GNU bash manual:

trap [-lp] [arg] [sigspec …]
...
If a sigspec is 0 or EXIT, arg is executed when the shell exits.

I've never seen any trap duplicated like this, so it should work with just the trap. Plus it's easy to test.

Russell Stewart commented at 2014-09-30 20:47:

Perfect, that's exactly what I needed to know. I tested and it worked without the duplicated, but I put it in there just in case.

On Tue, Sep 30, 2014 at 1:36 PM, Thomas Riccardi notifications@github.com wrote:

From the GNU bash manual:

trap [-lp] [arg] [sigspec …] ... If a sigspec is 0 or EXIT, arg is executed when the shell exits.

I've never seen any trap duplicated like this, so it should work with just the trap. Plus it's easy to test.

— Reply to this email directly or view it on GitHub https://github.com/Russell91/sshrc/issues/35#issuecomment-57378527.

#34 Issue `closed`: sshrc example.com "ls" doesn't exit after executing "ls"

Thomas Riccardi opened issue at 2014-09-29 12:56:

With plain ssh ssh example.com "ls" executes the command then exits. With sshrc it doesn't exit: the interactive shell is kept open.

Russell Stewart commented at 2014-09-29 17:00:

To fix this we'd have to start parsing the sshrc arguments and act differently when extra arguments are supplied. Is there some reason why you can't just use regular ssh in these cases? I can imagine this would be frustrating if you had put alias ssh=sshrc somewhere.

Thomas Riccardi commented at 2014-09-29 20:02:

I don't have a real use-case that would justify this. However I would have expected sshrc could be a drop-in replacement as suggested by your alias ssh=sshrc.

In fact I do have a real use-case (but it does not necessarily justify the fix): I came across this issue while benchmarking the overhead with a time sshrc example.com l (where alias l='ls -latrh').

In any case, if we want to have the perfect drop-in replacement there is probably more work to do. For example pipe into sshrc seem to work but triggers a warning:

$ echo test | sshrc example.com cat
Pseudo-terminal will not be allocated because stdin is not a terminal.
test

Maybe it doesn't work with older ssh/bash though this should be in another issue...

Russell Stewart commented at 2015-03-21 08:52:

I'm closing this because it's not a bug. I'll keep in mind the fact that the current readme does not do a good job at highlighting some of the more subtle differences between sshrc and ssh though.

#32 Issue `closed`: Does sshrc work with mosh?

Labels: help wanted

Russell Stewart opened issue at 2014-09-26 05:07:

I don't use mosh. Can someone who does try to make sshrc work with it and add a wiki page. There seems to be a good deal of demand here.

#29 Issue `closed`: It doesn't let me change the prompt colours

Poyeyo opened issue at 2014-09-25 20:13:

I just tried adding this to the config file:

PS1='${debian_chroot:+($debian_chroot)}[\033[01;32m]\u@\h[\033[00m]:[\033[01;34m]\w[\033[00m]$ '

robled commented at 2014-09-25 20:24:

Strange. Works fine for me. Example here:

https://github.com/robled/dotfiles-core/blob/master/.sshrc

Russell Stewart commented at 2014-09-25 20:49:

Yep, works for me too. I use the following: export PS1='[\033[01;32m]\u@\h[\033[00m]:[\033[01;34m]\w[\033[00m]$ '

#27 Issue `closed`: example vim config not compatible with "syn on"

robled opened issue at 2014-09-25 18:43:

$ vim
Error detected while processing /tmp/.user.sshrc.OsBK/.sshrc.d/vimrc:
line    1:
E484: Can't open file /tmp/.user.sshrc.OsBK/.sshrc.d/syntax/syntax.vim
Press ENTER or type command to continue

A user on reddit posted a solution that works for me:

https://www.reddit.com/r/linux/comments/2h0wab/sshrc_make_your_ssh_sessions_feel_like_home/ckomxkk

I will update the docs and submit a pull request shortly.

robled commented at 2014-09-25 21:13:

Closing this out since the fix was merged:

https://github.com/Russell91/sshrc/pull/28

Russell Stewart commented at 2014-09-25 21:19:

Yea, thanks for submitting this. I was just about to start working on this after fixing the tmux issues last night, when I saw this solution sitting here ready for me to add.

#26 Issue `closed`: mktemp on Ubuntu 6.06 doesn't accept a parameter to -t

Evgeni Kolev opened issue at 2014-09-25 08:29:

Thanks for this amazing script!

Here's an issue I ran into: when connecting to a linux box from OSX, I get an error: mktemp: cannot make temp dir /tmp/.edkolev.sshrc.XXXX: Invalid argument

I believe this is caused by the fact the mktemp's command line API is different:

(man mktemp on linux; -t is a switch)
SYNOPSIS
       mktemp [-V] | [-dqtu] [-p directory] [template]

(man mktemp on osx; -t accepts a param)

SYNOPSIS
     mktemp [-d] [-q] [-t prefix] [-u] template ...
     mktemp [-d] [-q] [-u] -t prefix

Russell Stewart commented at 2014-09-25 08:45:

damn, I was under the impression that mktemp -d -t ... was consistent with every version of mktemp. Can you send me the man page for mktemp on your system?

Evgeni Kolev commented at 2014-09-25 09:12:

-p directory I think. Here's the whole man page. BTW this is a very old Ubuntu 6.06.1 LTS, I don't have a newer one to test right now

https://gist.github.com/edkolev/fb816c804d67d1c83b8e

Evgeni Kolev commented at 2014-09-25 09:14:

Actually, I do have a newer Ubuntu 14.04 LTS. Here's its man page:

https://gist.github.com/edkolev/6ff2263c25ee4e637e28

Edit: on this newer Ubuntu, sshrc is working perfectly fine. Maybe it's not really worth it to try to make sshrc work on the archaic Ubuntu

Russell Stewart commented at 2014-09-25 19:48:

Well thanks for letting me know. I really need a better way to predict when certain commands will fail. I'm going to mark this as closed for now.

#25 PR `open`: Add Bash completion script

Mario del Pozo opened issue at 2014-09-24 20:05:

Enables the same nice Bash completion features as in ssh (host completion based on ssh's config, known hosts, etc.).

Thomas Riccardi commented at 2014-09-29 12:54:

It doesn't work on ubuntu 12.04 with bash 4.2: _xfunc: command not found.

Mario del Pozo commented at 2014-09-29 17:47:

@Niluge-KiWi Yes, you're right. I tested with an old precise laptop and the Bash completion mechanism is different.

Mario del Pozo commented at 2014-09-29 20:58:

I don't think is a good idea.

If neither of both functions are available you just won't have completion for sshrc. But printing an error message each time the shell is executed... I'm pretty sure users will like it a lot ;-)

Thomas Riccardi commented at 2014-09-30 13:19:

I confirm this new version of the PR works for me now.

Russell Stewart commented at 2014-09-30 20:55:

so you guys have made some good progress. I've noticed that complete -p | grep ssh will return the current completion function for ssh as long as ssh has already been tab completed. What about writing a completion function that first calls tab completion on the standard ssh, then greps for the name of the completion function it is using (e.g. _ssh), and finally reassigns tab completion of sshrc to be that function. Something like

_sshrc() {
    "tab-complete call" ssh
    local command=`complete -p | sed -n '/ ssh$/p'
    $("$command"rc)
    COMP_RETURN=$(echo $command | sed -e 's/.*\(_[^ ]*\).*/\1/')
}

Mario del Pozo commented at 2014-10-03 15:25:

Well, I didn't found how to load the tab completion function for an specific command unless you search for the specific completion script for that command on the filesystem. I managed to identify two places for the completion scripts on Debian/Ubuntu (/etc/bash_completion.d and /usr/share/bash-completion/completions) but I don't know if other distributions use different locations.

It seems that _ssh() and _xfunc() are good candidates to be stable on different versions and distributions.

It could be very good if someone can light on this topic.

Evgeny Vereshchagin commented at 2015-07-26 14:42:

@mariodpros , see https://github.com/Russell91/sshrc/issues/44#issuecomment-124967391

#23 Issue `closed`: Brew problems

Santiago Blanco opened issue at 2014-09-24 13:05:

Error: No available formula for sshrc Searching taps...

Russell Stewart commented at 2014-09-24 17:06:

I've removed the brew install from the readme. I'll add it back in the future myself.

#22 Issue `closed`: ZSH Compatibility

Aaron Halford opened issue at 2014-09-23 20:18:

Bash is awesome, yet ZSH and other shell compatibility would be a great addition.

Thoughts?

BTW, thanks so much for this ssh tool.

Russell Stewart commented at 2014-09-23 20:42:

How much of this behavior could work by calling

 `$ exec /bin/zsh`

from your ~/.sshrc? I always assumed that approach would solve the problem.

Russell Stewart commented at 2014-09-25 09:08:

I'm going to mark this as closed. Still interested to hear your thoughts though.

Elvis commented at 2016-04-05 17:16:

Promt won't load up with exec zsh Here's a short screenscast http://take.ms/QTJ6W

Russell Stewart commented at 2016-04-05 20:15:

@mu3 I'm not sure what the content of the $SHELL variable is in that video. But if you add exec /bin/zsh, it works for me. e.g.

stewartr@Russells-MacBook-Air-2:~$ sshrc hr1c
homerussell%

Elvis commented at 2016-04-06 06:24:

You're right, there was a problem with $SHELL, also I use exec -l $(which zsh) now.

#19 Issue `closed`: bashsshrc as SHELL seems to cause problems with less and mc

Ross Brattain opened issue at 2014-09-23 02:45:

mc seems to hang when running with SHELL=/tmp/...bashsshrc

The subshell ends up a stopped 'T+' and there is a new pty.


 pts/7    S    |   \_ bash --rcfile /dev/fd/63
 pts/7    S+   |       \_ /usr/bin/mc -P /tmp/mc-mockbuild/mc.pwd.6023
 pts/1    Ss   |           \_ /bin/bash /tmp/.mockbuild.sshrc.bI7rM2/bashsshrc -rcfile .bashrc
 pts/1    T+   |               \_ /bin/bash --rcfile /dev/fd/62

I notice that bashsshrc doesn't work with the usually '-c' option. Maybe it needs to implement -c.

Russell Stewart commented at 2014-09-23 03:17:

hmm, there is no reason that bashsshrc can't take all the normal arguments that bash does. Can you try editing bashsshrc with vim $(which bashsshrc) and appending "$@" after the parenthesis on the final line? If this works I'll add it to master.

Ross Brattain commented at 2014-09-23 04:34:

I think it is the interactive stuff.

   An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option.  PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state.

Non-interactive shells shouldn't source a .bashrc.

bashsshrc -c echo foo should not source the .sshrc as it is non-interactive.

Russell Stewart commented at 2014-09-23 05:44:

Does the current master not work for you? Bash will not actually source the argument of --rcfile if -c is passed as well. Please let me know if master has fixed your problems.

On Mon, Sep 22, 2014 at 9:34 PM, Ross Brattain notifications@github.com wrote:

I think it is the interactive stuff.

An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state.

Non-interactive shells shouldn't source a .bashrc.

bashsshrc -c echo foo should not source the .sshrc as it is non-interactive.

— Reply to this email directly or view it on GitHub https://github.com/Russell91/sshrc/issues/19#issuecomment-56475466.

Ross Brattain commented at 2014-09-23 06:39:

once I export SHELL=$SSHHOME/bashsshrc
midnight commander hangs. Oh and I guess bash accepts -rcfile for some undocumented reason.

pts/42   S+     \_ mc
pts/45   Ss         \_ bash /tmp/.rbbratta.sshrc.Kfd2/bashsshrc -rcfile .bashrc
pts/45   T+             \_ bash --rcfile /dev/fd/62 -rcfile .bashrc

Russell Stewart commented at 2014-09-23 07:03:

okay, I've reproduced this and setting bashsshrc "$@" did not fix it. Looks like updating the shell variable is just bad news. I'll update the readme with an appropriate solution.

Russell Stewart commented at 2014-09-23 07:09:

okay, please let me know if the current readme suggestion fixes your problem

Ross Brattain commented at 2014-09-23 07:50:

ah, we are forking bash, when we need to exec. It looks like midnight commander setups up a fifo with the subshell which doesn't work if we fork a new bash in bashsshrc.

This should work

#!/usr/bin/env bash
exec bash --rcfile <(echo '
if [ -e /etc/bash.bashrc ]; then source /etc/bash.bashrc; fi
if [ -e ~/.bashrc ]; then source ~/.bashrc; fi
source '$SSHHOME'/.sshrc;
export PATH=$PATH:'$SSHHOME' 
') "$@"

I also though about removing the <(echo ...) and just writing the contents to .ssshrc.d and using a static --rcfile.

Russell Stewart commented at 2014-09-23 17:36:

Hmm, semantically exec makes more sense here. Are there other implications of forking rather than using exec?

Russell Stewart commented at 2014-09-23 20:55:

I'm going to mark this as solved.

#18 Issue `closed`: Argument list too long

Julien Lancien opened issue at 2014-09-22 15:01:

Whenever I try to use this script, I get the following error:

$ sshrc localhost
./sshrc: line 9: /usr/bin/ssh: Argument list too long

My ~/.sshrc.d is pretty small:

$ du -hs
 16K    .

Though I have a bunch of files (I modified the tar command to exclude .git):

$ find -L . | grep -v .git | wc
     568     568   27240

Not sure what is the best way to debug this. Any idea?

Thanks!

Ross Brattain commented at 2014-09-22 15:57:

Add a -v to ssh, and add 'set -x' in the bash to enable tracing.

You might be able to increase the shell argument list size RLIMIT_STACK with ulimit -s.

Julien Lancien commented at 2014-09-22 18:22:

With set -x in the script, I ran this:

sshrc HOST 2>&1 | tee LOG

And the resulting log file is 15M. So it seems that 16k of files may actually be too much to represent as hexadecimal. Only other way I can think of would be to use scp instead of xdd. Maybe I'll just trim down my profile.

Ross Brattain commented at 2014-09-22 18:44:

base64 instead of xdd should increase the efficiency of the encoding. base64 is available in gnu coreutils.

Julien Lancien commented at 2014-09-22 23:24:

That reduced it a bit, to 9M, but that's still too much. I just won't use that many files. I was trying to import my .vim directory with all my plugins, but I can live with just my vimrc.

Ross Brattain commented at 2014-09-22 23:33:

my testing shows a <128K limit. I am sending the payload via the $TERM variable. See http://superuser.com/questions/163167/when-sshing-how-can-i-set-an-environment-variable-on-the-server-that-changes-f

It looks like 128K (32 * 4K pages) per string. So if we can set multiple ENV variables you might be able to pass more data, unless SSH is limiting.

http://man7.org/linux/man-pages/man2/execve.2.html

  Limits on size of arguments and environment
       Most UNIX implementations impose some limit on the total size of the
       command-line argument (argv) and environment (envp) strings that may
       be passed to a new program.  POSIX.1 allows an implementation to
       advertise this limit using the ARG_MAX constant (either defined in
       <limits.h> or available at run time using the call
       sysconf(_SC_ARG_MAX)).

       On Linux prior to kernel 2.6.23, the memory used to store the
       environment and argument strings was limited to 32 pages (defined by
       the kernel constant MAX_ARG_PAGES).  On architectures with a 4-kB
       page size, this yields a maximum size of 128 kB.

       On kernel 2.6.23 and later, most architectures support a size limit
       derived from the soft RLIMIT_STACK resource limit (see getrlimit(2))
       that is in force at the time of the execve() call.  (Architectures
       with no memory management unit are excepted: they maintain the limit
       that was in effect before kernel 2.6.23.)  This change allows
       programs to have a much larger argument and/or environment list.  For
       these architectures, the total size is limited to 1/4 of the allowed
       stack size.  (Imposing the 1/4-limit ensures that the new program
       always has some stack space.)  Since Linux 2.6.25, the kernel places
       a floor of 32 pages on this size limit, so that, even when
       RLIMIT_STACK is set very low, applications are guaranteed to have at
       least as much argument and environment space as was provided by Linux
       2.6.23 and earlier.  (This guarantee was not provided in Linux 2.6.23
       and 2.6.24.)  Additionally, the limit per string is 32 pages (the
       kernel constant MAX_ARG_STRLEN), and the maximum number of strings is
       0x7FFFFFFF.

Julien Lancien commented at 2014-09-23 11:55:

It's ok. It's an acceptable limitation. When I'm sshing to a server I don't need all my config. The essentials is good enough.

Russell Stewart commented at 2014-09-23 21:25:

Hexadecimal has 16 symbols / byte => 4 bits/byte => 50% efficiency, so that's not responsible for your problem. I'm guessing that du is misleading you, perhaps due to symbolic links? sshrc will include symbolic link when tarring. Interesting article on 128kb limit though. I've changed the README to reflect the lower recommendation.

Julien Lancien commented at 2014-09-24 00:34:

So you were right: du was misleading me. My .vim is actually 15M. Symbolic links...

I'll work on triming it down.

#17 Issue `closed`: Can't get it working when ssh'ing to CentOS 5.5/Bash 3.2.25

r-nicol opened issue at 2014-09-22 11:32:

The bashsshrc does not seem to run correctly.

I tried running: bash --rcfile <(echo 'source '$SSHHOME'/.sshrc;') But no luck.

$SSHHOME does seem to resolve and the following works:

bash --rcfile $SSHHOME/.sshrc bash --init-file $SSHHOME/.sshrc

The bash on the server is ancient could that be the issue?

Russell Stewart commented at 2014-09-23 17:35:

Hmm, perhaps the <(...) syntax doesn't work for you. Can you try cat <(echo 3) ?

r-nicol commented at 2014-09-24 08:13:

That does work and outputs 3.

Interestingly cat <(echo 'source '$SSHHOME'/.sshrc;') outputs the correct expected value. However, it does not seem to like using source, when you do it manually. Dropping source works, as stated in my first comment but putting that in <(echo ...) fails.

I guess the solution is find a replacement for <(echo ...). Thoughts?

Russell Stewart commented at 2014-09-26 02:11:

I don't know what to say. If you figure it out let me know.

Thomas Riccardi commented at 2014-09-29 12:30:

Could you please reopen it?

I reproduce the issue with a ssh to a centos-5.10 host, with bash 3.2.

It seems bash 3.2 does not support process substitution for --rcfile:

$ bash --version
GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
$ bash --rcfile <(echo "echo test")
$

On ubuntu 12.04:

$ bash --version
GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ bash --rcfile <(echo "echo test")
test
$

So the generated file that is finally exec bash --rcfile should have an additional indirection using yet another file to support older bash version. (and supporting redhat 5 is really needed in real life environments).

Maybe just set the content of--rcfile <(...) directly into $SSHHOME/bashsshrc, and replace "$SSHHOME/bashsshrc" by "bash --rcfile $SSHHOME/bashsshrc" (I'm not sure about additional arguments with "$@" though).

r-nicol commented at 2014-09-29 13:05:

I can't reopen it, I guess only Russell can and I do feel this should be resolved.

Thomas Riccardi commented at 2014-09-29 13:24:

After my comment I wrote the patch and proposed it as PR #33, so this issue can now be kept closed.

Russell Stewart commented at 2014-09-29 16:55:

I'll reopen until I pull in the changes. The patch looks good though.

Russell Stewart commented at 2014-10-08 00:52:

Is this working for everyone now?

Thomas Riccardi commented at 2014-10-08 08:51:

It is for me.

r-nicol commented at 2014-10-08 08:52:

ye seems good.

shame you removed it from brew tho :(

#16 Issue `closed`: tmp files are left on server during timeout

Russell Stewart opened issue at 2014-09-22 04:58:

Perhaps there is a way to provide a tty script such that a timeout triggers the final rm command, rather than just dropping the shell and leaving the files on the server. In the meantime, I've ameliorated this problem by changing the default tmp-file to be hidden and moving it to /tmp/.$(whoami).sshrc.XXXX by default so that users can clean out all their tmp files without worrying about clearing another users active sshrc files.

Ross Brattain commented at 2014-09-22 16:17:

will a bash trap of SIGHUP cleanup the files?

Russell Stewart commented at 2014-09-22 16:22:

Potentially. I looked into this last night but didn't solve. On Sep 22, 2014 9:17 AM, "Ross Brattain" notifications@github.com wrote:

will a bash trap of SIGHUP cleanup the files?

— Reply to this email directly or view it on GitHub https://github.com/Russell91/sshrc/issues/16#issuecomment-56398428.

Russell Stewart commented at 2014-09-23 07:12:

I'm testing a fix that uses:

            trap \"rm -rf \$SSHHOME; exit\" 0

just before calling $SSHHOME/bashsshrc. I'm still testing but quite hopeful that this will clean up the temp files as soon as the server kills the ssh process.

Russell Stewart commented at 2014-09-23 17:32:

This should be fixed in master.

#14 Issue `closed`: Missing dependencies? "xxd: command not found"

m4l opened issue at 2014-09-22 00:50:

My local machine is Ubuntu 14.4 connecting to a server on Centos 6.5, this is what I see:

sshrc root@server
root@server's password: bash: line 2: xxd: command not found bash: line 10: xxd: command not found bash: line 13: xxd: command not found

gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now Connection to server closed.

cat ~/.sshrc echo hi

Russell Stewart commented at 2014-09-22 03:26:

Hmm, this is interesting. Can you verify if xxd is installed on the server by typing which xxd?

Russell Stewart commented at 2014-09-22 03:34:

I have a solution for this coded up that checks for missing xxd and exits gracefully with an appropriate warning, but I need to understand a little more about why your server wouldn't have xxd.

Tuomo Tanskanen commented at 2014-09-22 07:34:

xxd is coming from vim-common on Ubuntu, and vim-common is not a mandatory package for an Ubuntu installation. It is priority of important, which means it is not mandatory part of every Ubuntu system. Same likely applies to CentOS as well, as any editor (even vi(m)) isn't a core package.

Russell Stewart commented at 2014-09-22 07:36:

hmm, do you have any idea if there is a similar tool (for hex dumping files) that is more common?

Evgeni Kolev commented at 2014-09-22 09:00:

Maybe od or hexdump. Not sure which one is more common.

It may be most portable to use bash's printf to hex dump the files. Here's a quick prototype

input_file=/tmp/a

while IFS= read -r -n1 char; do
  printf "%02x" "'$char"
done < "$input_file"

Ross Brattain commented at 2014-09-22 15:58:

If you have gnu coreutils can you use base64 to encode with base64.

Russell Stewart commented at 2014-09-22 20:18:

anyone else have pros/cons for base64?

Ross Brattain commented at 2014-09-22 21:59:

base64 was added in gnu coreutils v6.0 circa 2006-02-27.

base64 also available via python 2.4+ stdlib oneliner, I haven't look into perl or ruby oneliners.

I don't have OS X to test against, so I don't know if it is present there.

Ross Brattain commented at 2014-09-22 22:01:

base64 is in openssl, http://superuser.com/questions/120796/os-x-base64-encode-via-command-line

Red5d commented at 2014-09-23 17:06:

+1 for base64 since it's in coreutils. RedHat server builds also don't include vim-common/xxd, FYI.

Russell Stewart commented at 2014-09-23 17:13:

Okay, I'm going to support both xxd OR base64, depending on their availability. It will take some time though.

On Tue, Sep 23, 2014 at 10:06 AM, Red5d notifications@github.com wrote:

+1 for base64 since it's in coreutils. RedHat server builds also don't include vim-common/xxd, FYI.

— Reply to this email directly or view it on GitHub https://github.com/Russell91/sshrc/issues/14#issuecomment-56554186.

adam mcgreggor commented at 2014-09-23 19:45:

base64 is installed on my 10.9.5 MacOS:

adam@aragog:~$ uname -a
Darwin aragog.int.abeyance.org.uk 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

I don't compile my own kernels on the mac, so assume this is fairly stock.

adam@aragog:~$ which base64
/usr/bin/base64

so it exists…

adam@aragog:~$ file /usr/bin/base64
/usr/bin/base64: Mach-O 64-bit executable x86_64

… and is an executable

adam@aragog:~$ base64 --help
Version DEBUG
Usage:  base64 [-dhvD] [-b num] [-i in_file] [-o out_file]
  -h, --help     display this message
  -v, --version  display version info
  -d, --debug    enables additional output to stderr
  -D, --decode   decodes input
  -b, --break    break encoded string into num character lines
  -i, --input    input file (default: "-" for stdin)
  -o, --output   output file (default: "-" for stdout)

so far, so good.

but now for the really useful part…

adam@aragog:~$ base64 --version
Version DEBUG

Ross Brattain commented at 2014-09-23 19:53:

Cool, looks like OS X has a different arg for decode, though. -D versus -d in coreutils.

Red5d commented at 2014-09-26 13:00:

My latest pull request switches it to using base64 and differentiates between "-D" and "-d".

Russell Stewart commented at 2014-10-23 20:37:

Unfortunately I just couldn't get base64 to work to my satisfaction. The fact that they changed their API between versions is only part of the problem. The version on mac seems to be a DEBUG version or something, and the whole thing seems like it would cause more problems than xxd. I've fixed this by testing for the presence of xxd locally and on the server and giving an explicit error message instead.

Red5d commented at 2014-10-23 22:06:

Did you look at my pull request here? https://github.com/Russell91/sshrc/pull/24 Base64 is working fine for me. I've accounted for the different command line options on the different versions.

Russell Stewart commented at 2014-10-23 22:20:

I don't think the -di option works on os x.

Version DEBUG Usage: base64 [-dhvD] [-b num] [-i in_file] [-o out_file] -h, --help display this message -v, --version display version info -d, --debug enables additional output to stderr -D, --decode decodes input -b, --break break encoded string into num character lines -i, --input input file (default: "-" for stdin) -o, --output output file (default: "-" for stdout)

On Thu, Oct 23, 2014 at 3:06 PM, Red5d notifications@github.com wrote:

Did you look at my pull request here? #24 https://github.com/Russell91/sshrc/pull/24 Base64 is working fine for me. I've accounted for the different command line options on the different versions.

— Reply to this email directly or view it on GitHub https://github.com/Russell91/sshrc/issues/14#issuecomment-60317028.

Red5d commented at 2014-10-24 02:56:

Yeah, my code checks for that and uses -D instead of -di when needed.

Russell Stewart commented at 2014-10-24 03:52:

Right, but have you tested sshing from a osx machine to a linux machine. It didn't work for me.

On Thu, Oct 23, 2014 at 7:56 PM, Red5d notifications@github.com wrote:

Yeah, my code checks for that and uses -D instead of -di when needed.

— Reply to this email directly or view it on GitHub https://github.com/Russell91/sshrc/issues/14#issuecomment-60338776.

Red5d commented at 2014-10-31 16:50:

Ah, I see. It's only checking for different base64 options on the remote machine, not local. Let me fix that...

Red5d commented at 2014-11-03 17:07:

Ok. Try it now. I've pulled in your latest changes and (I think) fixed the base64 options. The pull request has been updated.

#8 Issue `closed`: Homebrew support

Johannes Schickling opened issue at 2014-09-20 13:26:

Please register this package on homebrew to install it on OSX via $ brew install sshrc

Russell Stewart commented at 2014-09-20 23:04:

I haven't worked with homebrew before. Maybe you could submit a package and I'll link to it from the readme here?

Moshe Zada commented at 2014-09-21 17:20:

There is a PR in brew repository that installs sshrc Homebrew/legacy-homebrew#32341 @elmak

Russell Stewart commented at 2014-09-21 18:25:

@MosheZada nice, added support to the readme

Moshe Zada commented at 2014-09-21 18:42:

the PR (pull request) isnt merged with master yet - so OS X cannot install via brew. please change the readme

Russell Stewart commented at 2014-09-21 18:55:

I just successfully installed via homebrew 20 mins ago. On Sep 21, 2014 11:42 AM, "Moshe Zada" notifications@github.com wrote:

the PR (pull request) isnt merged with master yet - so OS X cannot install via brew. please change the readme

— Reply to this email directly or view it on GitHub https://github.com/Russell91/sshrc/issues/8#issuecomment-56308177.

Evgeni Kolev commented at 2014-09-23 18:25:

The brew version doesn't work for me (sshrc works like regular ssh) but the latest github version works just as expected.

#6 Issue `closed`: See shellcheck.net

Lukas opened issue at 2014-09-20 09:25:

It found 15 problems. http://www.shellcheck.net/

#4 Issue `closed`: This is different from ~/.ssh/rc in what way?

James Sumners opened issue at 2014-09-15 12:47:

SSH already parses an rc file if you create it in ~/.ssh/rc. So I'm just curious: what problem does this project solve? It should be noted in the README.

http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch08_04.htm

Russell Stewart commented at 2014-09-15 18:16:

The tool sources the ~/.sshrc on your local computer, not your remote computer. This means you can configure a server shared with coworkers when you otherwise couldn't. Also, there is no configuration on the server, which makes keeping track of configurations on multiple servers easier.

I've changed the first sentence in Usage to reflect this.

James Sumners commented at 2014-09-15 22:07:

I see. Thank you for the clarification.

Russell Stewart commented at 2014-09-23 21:26:

Change the readme to more directly state the differences.

#2 Issue `closed`: aws login messages not displayed with sshrc

Russell Stewart opened issue at 2014-09-12 18:13:

If anyone has any insight into the protocol that is printing this, I'd be interested. I'll look into it myself in the meantime.

Russell Stewart commented at 2014-09-12 18:15:

Ah, grepping for the welcome message in /etc produced the /etc/motd file.

Russell Stewart commented at 2014-09-21 19:35:

Can someone more knowledgable explain to me how the /etc/motd system works on ubuntu? I'd like to add support for it so that people feel more comfortable about the similarity between ssh and sshrc. A check for the file followed by a cat of it would be fine, but I'd like to know if non-ubuntu systems have similar systems that would need support as well. Also, is /etc/motd always catted if it exists, etc.?

Moshe Zada commented at 2014-09-21 20:38:

it occurs because you passing the -t flag that forces tty allocation. i will check it tomorrow.

Russell Stewart commented at 2014-09-22 03:35:

yea this makes sense, I think I will just add a special flag to cat the /etc/motd, but if you can figure out a more general way of doing this that would be great.

Russell Stewart commented at 2014-09-22 03:40:

Looks like these are configured in /etc/ssh/ssdh_config under PrintMotd and PrintLastLog. It'd be good to parse some sshd_config files and react appropriately where this behavior is nullified by the -t flag.

Jan Larres commented at 2014-09-22 07:48:

I think the -t option is a red herring, the real issue is that bash is not started as a login shell. Depending on the exact system configuration this will have various consequences, including not printing the motd. If I remember correctly I had a system (I think an old RHEL) which actually checked the executable name of bash and only displayed the motd if it had a - in front, which signifies a login shell. So in my own wrapper I had to use this horrible construct in order to make it work properly:

exec bash -c "exec -a -bash bash --login -i"

Russell Stewart commented at 2014-09-23 21:19:

I've always hated the /etc/motd system in the first place - just a bunch of junk text. But I've added a special case to print it when its available by default for compatibility. It'd be good to automatically read this from the sshd_config settings at some point.

Jan Larres commented at 2014-09-23 22:56:

I don't think this is really enough, the shell initialization can do anything it wants differently between login and non-login shells. For example, setting the PATH differently is a common occurrence. So instead of special-casing the motd it would be better to make sure that bash is started as a login shell as I mentioned above.

Russell Stewart commented at 2014-09-23 23:02:

The best thing to do is to find a simple variation of ssh me@myserver -t bash that actually prints the /etc/motd. Let me know if you find something.

prilka commented at 2016-03-10 12:33:

majutsushi is absolutely right. This issue is only one result of the non-login shell problem. On my system i don't have bash-completion with sshrc, because the /etc/profile.d/bash_completion.sh is not executed for a non-login shell.

#1 Issue `closed`: Tar timestamps warning

Russell Stewart opened issue at 2014-09-12 18:09:

It seems that if the local and remote server's clocks are too far apart, tar can throw a warning about future timestamps.

Russell Stewart commented at 2014-09-12 18:10:

This is harmless, but the warning has been fixed in master by untarring with the -m command: -m (x mode only) Do not extract modification time. By default, the modification time is set to the time stored in the archive.

Files

sshrc.md

Latest commit

History

sshrc.md

File metadata and controls

#86 PR open: improve readme.md

Benedikt Heine opened issue at 2017-03-17 23:45:

#85 PR open: Use base64 from coreutils for encoding and decoding

Michał Leśniewski opened issue at 2017-03-10 14:07:

#84 PR open: Deduplicate bash config file setup

taylorskalyo opened issue at 2017-02-15 03:47:

#83 PR open: run cat /etc/motd or run-parts /etc/motd.d, not both

taylorskalyo opened issue at 2017-02-15 03:46:

#82 PR open: alpine mktemp compatible

陈杨文 opened issue at 2017-02-13 05:42:

#79 Issue open: executing a script before .bash_profile ...

Victor Volle opened issue at 2016-12-20 13:03:

#78 Issue open: Loading rc files was failed after ssh reconnected with tmux attach

aiya000 opened issue at 2016-12-11 00:52:

#77 Issue open: sshrc doesn't work when remote user's default shell isn't bash

Kirill Rogovoy opened issue at 2016-11-20 19:29:

#76 PR open: Avoid warnings caused by BSD tar vs. GNU tar

Daniel Serodio opened issue at 2016-10-27 16:53:

Russell Stewart commented at 2016-11-20 00:54:

Georgy Krasulya commented at 2017-02-06 20:13:

#75 PR open: Use $0 to determine if the user want ssh or mosh

Hugues Morisset opened issue at 2016-10-06 21:51:

#74 Issue open: sshrc doesn't work due to missing mktemp and -z flag on tar

Δημήτρης Ραβιόλος opened issue at 2016-08-23 09:11:

Russell Stewart commented at 2016-09-03 06:34:

Δημήτρης Ραβιόλος commented at 2016-09-03 08:14:

#72 Issue closed: Execute command (or, generalizing: support profiles)

memeplex opened issue at 2016-08-01 17:29:

Russell Stewart commented at 2016-08-03 20:55:

memeplex commented at 2016-08-03 21:05:

Russell Stewart commented at 2016-08-03 21:20:

memeplex commented at 2016-08-03 21:27:

Russell Stewart commented at 2016-08-07 23:33:

memeplex commented at 2016-08-08 18:38:

#71 Issue closed: Turn off motd

Timmo Verlaan opened issue at 2016-07-26 06:48:

Russell Stewart commented at 2016-08-07 23:50:

#69 Issue closed: sshrc fails to transfer all files on one particular remote machine

swiftster opened issue at 2016-06-29 18:41:

Russell Stewart commented at 2016-07-09 17:18:

swiftster commented at 2016-07-12 15:53:

Russell Stewart commented at 2016-07-12 20:04:

#68 Issue closed: Support for GPG?

Zakatell KANDA opened issue at 2016-05-19 06:19:

Russell Stewart commented at 2016-05-19 22:15:

Russell Stewart commented at 2016-05-24 06:34:

Zakatell KANDA commented at 2016-05-24 07:34:

#66 Issue closed: Feedback / code review on new "-t" option

Russell Stewart opened issue at 2016-05-04 02:39:

serverco commented at 2016-05-05 10:33:

Russell Stewart commented at 2016-05-05 19:11:

serverco commented at 2016-05-06 08:55:

Russell Stewart commented at 2016-07-25 18:46:

serverco commented at 2016-07-26 19:24:

Russell Stewart commented at 2016-08-07 23:33:

serverco commented at 2016-08-08 06:54:

Russell Stewart commented at 2016-08-08 21:04:

#65 Issue closed: Please make latest tag and release

Ikuo Degawa opened issue at 2016-04-29 09:40:

Stephen Ball commented at 2016-05-01 20:57:

Russell Stewart commented at 2016-05-01 21:14:

Ikuo Degawa commented at 2016-05-04 03:23:

#61 Issue closed: Is it possible to add a surc

陈杨文 opened issue at 2016-04-09 07:33:

Russell Stewart commented at 2016-04-09 20:48:

serverco commented at 2016-04-11 13:46:

陈杨文 commented at 2016-04-11 16:17:

serverco commented at 2016-04-11 16:55:

陈杨文 commented at 2016-04-11 16:59:

Russell Stewart commented at 2016-04-20 17:40:

Stephen Ball commented at 2016-04-21 12:43:

陈杨文 commented at 2016-04-21 13:13:

serverco commented at 2016-04-21 13:20:

#60 Issue closed: Alternatives to xxd

#86 PR `open`: improve readme.md

#85 PR `open`: Use base64 from coreutils for encoding and decoding

#84 PR `open`: Deduplicate bash config file setup

#83 PR `open`: run `cat /etc/motd` or `run-parts /etc/motd.d`, not both

#82 PR `open`: alpine mktemp compatible

#79 Issue `open`: executing a script before .bash_profile ...

#78 Issue `open`: Loading rc files was failed after ssh reconnected with tmux attach

#77 Issue `open`: sshrc doesn't work when remote user's default shell isn't `bash`

#76 PR `open`: Avoid warnings caused by BSD tar vs. GNU tar

#75 PR `open`: Use $0 to determine if the user want ssh or mosh

#74 Issue `open`: sshrc doesn't work due to missing mktemp and -z flag on tar

#72 Issue `closed`: Execute command (or, generalizing: support profiles)

#71 Issue `closed`: Turn off motd

#69 Issue `closed`: sshrc fails to transfer all files on one particular remote machine

#68 Issue `closed`: Support for GPG?

#66 Issue `closed`: Feedback / code review on new "-t" option

#65 Issue `closed`: Please make latest tag and release

#61 Issue `closed`: Is it possible to add a surc

#60 Issue `closed`: Alternatives to xxd

#59 Issue `closed`: Sourced resources are not being transferred

#58 Issue `closed`: Homebrew install moshrc

#57 PR `open`: Add screen config example to README.md

#54 Issue `closed`: Having to specify full path to /usr/local/bin/sshrc even though its in PATH, and +x

#53 Issue `closed`: Last login information

#50 Issue `open`: Add homebrew bash completion

#49 Issue `open`: Add apt-get bash completion

#48 Issue `open`: man page

#47 Issue `closed`: proper quoting required

#45 Issue `closed`: `deb`-package is outdated

#44 Issue `closed`: missing bash completion